Hi everone!
I need to implement a custom confirmation dialog with three options — YES, NO, and CANCEL. I created a block like this:
It works fine, but I would like to use it in a way similar to JavaScript’s confirm:
1. Open the dialog from a Client Action
2. Wait for the user’s choice
3. Get the selected option (yes, no, cancel)
4. Continue the flow
Is it possible to implement this?
Hello,
Along with Mihai’s answer, I’m just adding another approach in case you need a reference for it.
Here, I created a block with one input parameter that controls the visibility of the popup, along with three events: Yes, No, and Cancel. Then, I created a local variable named Decision. In the three events, I added two input parameters respectively, called Decision and HidePopUp, which is used to close the popup. I also created three client actions to trigger these events, assigning the Decision variable with the values 1, 2, and 3, each representing a specific action, for example 1 for Yes, 2 for No, and 3 for Cancel. After that, the event is triggered by passing the two input parameters, the decision itself and HidePopUp with a value of false to hide the popup, and then the Decision value is reset back to 0 for the next action.
On the parent side, only one client action handles the three events. Inside it, there is a switch case that checks which decision was made and, based on that, applies the required logic and determines which path to take. Finally, it assigns the local variable ShowPopup with the passed input parameter from the event, HidePopUp, which will be false.
Hi Lukasz,Could you please share your sample OML file ?Thanks,Ajit Kurane.
Hi Lukasz,
Check this forge component: Client Awaitable Popups . It might help you with your use case.
As an alternative you could split the flow: the first Client Action sets any needed context (local variables like a pending action + inputs) and opens the confirmation popup. Then, the popup’s OnYes / OnNo / OnCancel events resume the process by calling separate Client Actions (or a single “resume” action) using that stored context.
Hello [name],On the same thread as the previous replies you can find a simplified implementation. If this approach works for you, please don’t forget to mark it as the solution so others can find it more easily.
Hi @Łukasz Kaproń ,
Your approach is very good!
One small point I'd like to add is that you should use a structure to store all the block's configuration. Reducing the number of input parameters is part of what's discussed in best practices.
Hope this helps!