I'm in an adaptive dialog in bot framework.
The "conversational architecture" looks like this:
[ROOT DIALOG] -> [CHILD1 DIALOG]
[ROOT DIALOG] -> [CHILD2 DIALOG] ... [further dialogs]
I'm finished with the data capture I was doing in [CHILD1 DIALOG] and I would like the user to "jump" straight into [CHILD2 DIALOG] without having to manually do so via [ROOT DIALOG].
How would one do that in bot framework?
I think you're looking for replaceDialog. I use it in my non-adaptive dialogs to transition from the end of dialog 1 to dialog 2 without going back to the root (I call it in the last step instead of endDialog). There is a sample for using ReplaceDialog within adaptive dialogs.
That sample includes a prompt to confirm if the user wants to replace the dialog (it's in the context of an interrupt, not redirecting from dialog 1 to dialog 2 as you mentioned), but I think you can leave that part out and just use the new ReplaceDialog(YOUR_DIALOG_NAME) line as your step action to accomplish this.
Related
I'm using the Bot Framework .Net SDK4.
I start my Dialog at MainDialog.
I'm trying to restart my dialog when the watterfall dialog conversation ends. I have multiple watterfall that redirect to other watterfall dialogs, unti they reach the final one.
When I'm using stepContext.EndDialogAsync(null, cancellationToken) or stepContext.CancellAllDialogsAsync(cancellationToken), the dialog just returns to the previous parent dialog.
I also can't just use BeginDialogAsync(nameof(MainDialog), null, cancellationToke) because of circular dependency issues.
Is there anything I can do to restart my dialog at MainDialog, where it reruns tehe dialog again.
use
return await sc.ReplaceDialogAsync(nameof(NoUnderstandDialog), cancellationToken);
To restart the waterfall dialog you are currently in.
ReplaceDialogAsync :
Starts a new dialog and replaces on the stack the currently active dialog with
the new one. This is particularly useful for creating loops or redirecting to
another dialog.
You can use this for multiple reasons, validation for example if the user inputs a wrong value, you can restart the dialog to prompt again. Be careful though your waterfall dialog should always "ends" meaning it should have a EndDialogAsync so you don't get stuck in an endless loop
Is there any workaround to execute an automation script over dialog in Maximo and next close it with dialogok event using the same push button?
It's probably not the answer you want to hear, but as of Maximo 7.6.0.8 (the latest version currently available), the only "workaround" would be a custom Java Bean class.
It's is possible to trigger two actions with one button. I've not tested it with automationscripts though....
For example use this in de button xml:
mxevent="dialogok" value="ROUTEWF"
You can add a sigoption with the same name as the action and make sure that you expand the 'Advanced Signature Options' section and set 'This is an action that must be invoked by user in the UI'.
You could create and object launch point automation script therefore when you click OK in the menu the object will be saved and the automation script triggered.
If you already know that some field is going to be update, you could do it with an attribute launch point for that object.
I have created a basic MSI project using InstallShield, I want to run a custom action script between two dialogs.
This shows my execute sequence, I want to move the custom action MyCustomActionScript to between the two dialogs indicated by the arrow.
How can I do this? Do I need to change things around somehow so that the dialogs are not nested (this is the way they are created naturally)? Or do I have to do something else, like run a DoAction on the target dialog? If so, will the execute sequence automatically move to the next dialog upon completion of the script, or do I have to script something to move the execution?
(Note that the script is a simple manipulation of the INSTALLDIR property, nothing complicated.)
Only the first dialog of the wizard loop is in the UI sequence. The rest are invoked by NewDialog control events. You want to look into the DoAction control event to invoke your custom action.
Custom actions scheduled in this fashion should only perform data acquisition / validation. Changes to the machine state should only occur in the execute sequence.
To run an action between LicenseAgreement and InstallSettings, you must indeed set up a control event DoAction. In this case you would add the DoAction on the behavior of LicenseAgreement's Next button so that it is invoked in the same scenarios that the Next button's NewDialog takes you to InstallSettings.
I have a bunch of control objects (TextBoxes, to be precise) that get injected into my code using the #FXML annotation during the FXML load.
I would like to save the states of these controls, specifically the text values, when the user closes the Scene by clicking the close box on the title bar.
However, when I trap the CloseRequest event in an OnCloseRequest handler I find that the values of the control variables are null (the original injection works, so this is something that happens in between the loading of the FXML and the calling of OnCloseRequest).
Can anyone explain this behavior and/or suggest how I can get the functionality that I want?
TIA
onCloseRequest is
Called when there is an external request to close this Window. ...
(from Javadoc). One of the meanings of "external request" is when you close the window through OS native window close button. The closeRequest event is not triggered through the programmatic stage.close() or stage.hide() calls. So consider to handle onHiding or onHidden events.
Otherwise post your OnCloseRequest handler code.
In my custom actions, I've used MessageBox.Show() to show a dialog whether needed. For ex: during database installation, I'd like to show a message to user if any error. But the message box is not set as a child of Wix window by default, thus the end-user can leave the message box and touch the Back, Next button ...
Is there any way to set the message box as a child of the main Wix installer window?
Thanks in advance,
There are bad ways and good ways. The bad ways involve FindWindow calls so you can parent appropriately. The good ways involve calls to MsiProcessMessage, Session.Message, or whatever wrapper is available. However if this custom action is being invoked from a DoAction ControlEvent, the latter will not work.