In Microsoft Bot Composer, can intents be added to child dialogs, or only to main dialog?
I see an option to add intents in child dialogs, but when I test (LUIS or regex) they do not get recognized. However when I add them to main dialog they do.
Does this mean that all intents have to be loaded to main dialog only? Then what is the point of intent recognized trigger?
Sample Case:
I created 2 intents. test2 and custom. I put test2 in main dialog. And for custom I tested exact same intent (with same phrases) in main vs child dialog.
In first case, I got correct recognition. In the other it either goes to wrong intent (test2) or gives 'not understood' response.
UPDATE:
Based on answers and further testing, it appears that intents to child dialog can only be recognized IF THE DIALOG IS ALREADY OPEN. I.e., the intents are invisible at the start of conversation, and only visible if something opens the child dialog, and if the dialog continues to be open.
Yes , you can add intent for child dialog also.
In Child dialog you have to set "Auto end dialog" property as false ( default is true) until end dialog is called , all intent(child dialog Intent) handle by the child dialog.
Two steps:
Go to the setting of your "Begin a new dialog" activity that triggers the child dialog, set "Activity processed" to false.
In the child dialog, delete the "BeginDialog" trigger that was created by default.
This will forward original user input to the child dialog and its Luis without asking the user again. No need to set false "Auto end dialog" as in the other answer.
Related
In the unified interface, when I click on the standard button "Reactivate" in the Lead form in order to reopen a qualified Lead, I have a confirmation window that asks what must be the statuscode of the lead, once reopened. In other organizations, I don't have this window, and this difference does not depend on the presence or not of custom statuscodes.
I want to define the statuscode of the reopened lead within a plugin: Is it possible to prevent the display of the confirmation window?
Gotcha! You have to check in your Lead entity Status Reason transitions. If more than one Status Reason defined under Active state, this window will popup.
if this xxxx needs to be activated again, then on Activation, it will ask for the status reason you want that to be on as we have mentioned many status reasons
Read more
You can simply uncheck the Enable Status Reason Transitions so this popup will not appear and you can do this your plugin. But required validations may fail.
When you edit a status reason field the Edit Status Reason Transitions button is in the menu. When you click this button the Status Reason Transitions dialog provides the option to choose Enable Status Reason Transitions. When this option is selected you must define which status reason values are allowed for each status reason. To remove the filtering applied, remove the Enable Status Reason Transitions selection. The transitions you have defined will be kept but not applied.
Reference
I used CheckTargetPath = 0 to validate the entered path in the textbox events. It doesn't let past to the next dialog if the path entered is not valid. But I want to display either an error message in another textbox in the same dialog or in another dialog box. Please advice.
Make a clone of the SetupError Dialog, and make it look nice.
on the behavior section of your button "Next":
add the condition CheckTargetPath=0 to the NewDialog actions
add a SpawnDialog (your New dialog) with a condition CheckTargetPath<>0
That way the user will be trapped on that dialog until you action return 0.
Don't forget to cover the unattended mode.
I'm trying to run some automation tests in my application but the UFT Hidden-mode notification tooltip is coming in front of the objects in the screen, preventing my tests to run.
I know I can un-check the option "Display hidden-mode notification tooltip" in Remote Agent Settings to fix this issue and it works fine on my machine after I do this, but these tests are executed in other machines, by other users in my company, and it would be a real effort to tell each and everyone of them to change this setting on their machine.
Is it a way to disable this checkbox programmaticaly instead?
EDIT:
Here is a little more detail on where this is affecting me:
I'm testing a Web application and in some of my test cases I need to download a file from this application. I do that by clicking on "Save As" in the context menu which is displayed on a notification bar at the bottom of the browser.
Following is the portion of code to perform such operation:
Dim brwBottom
Set brwBottom = Browser("brw_Bottom_Save_As")
If brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Exist Then
brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Click
brwBottom.WinMenu("wm_Selector").Select "Save As"
End If
This works fine on my machine because UFT notification is not being displayed, but in other machines where the UFT Notification is displayed, it overlaps the menu and my script is unable to select the "Save As" option. So, in case it is not possible to programmatically close this notification at runtime, is there any alternative solution to click on the "Save As" button, even with this notification overlapping it?
I managed to identify the UFT Notification tooltip and close it. With this, there is no more objects in front of the button I need to click and my script can be executed successfully.
Following is the code used. I'm not marking this as the acceptable answer yet because I am still waiting for my team to accept the solution, but this works.
Dim brwBottom
Set brwBottom = Browser("brw_Bottom_Save_As")
' To close UFT Notification Tooltip, if exists
If Window("regexpwndtitle:=NotificationWindow").Exist(2) Then
If InStr(Window("regexpwndtitle:=NotificationWindow").GetROProperty("nativeclass"),"UFTRemoteAgent") > 0 Then
Window("regexpwndtitle:=NotificationWindow").Close
End If
End If
If brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Exist Then
brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Click
brwBottom.WinMenu("wm_Selector").Select "Save As"
End If
Create UFT GUI test and include these three lines:
extern.Declare micLong, "WritePrivateProfileString", "kernel32.dll", "WritePrivateProfileString", micString, micString, micString, micString
extern.WritePrivateProfileString "RemoteAgent", "ShowBallon", "0", Environment("ProductDir") + "\bin\mic.ini"
systemutil.CloseProcessByName "UFTRemoteAgent.exe"
From ALM, run it on all your UFT machines.
Notes:
This will switch the flag that controls such tooltip to be off, so next time Remote Agent launches will read it and won't display the tooltip anymore.
The third line will kill UFT's remote agent for GUI testing which is in charge of the communication between UFT and ALM Client and this will cause an error in ALM's Automatic Runner (The RPC server is unavailable)... just ignore it. We need to kill it so it is re-launched next time we try to run a test from ALM (as mentioned above, new value for tooltip will be read)
EDIT:
I just found something interesting: this flag is actually saved in two locations:
mic.ini
RemoteAgentGUISettings.xml
but the one that actually makes the change effective is RemoteAgentGUISettings.xml (it seems they're switching from .ini files to .xml... which makes sense). In this case, the code will change a little, but the idea is the same:
filePath = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%appdata%") + "\Hewlett-Packard\UFT\Persistence\Dialogs\RemoteAgentGUISettings.xml"
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.load filePath
Set nNode = xmlDoc.selectsinglenode ("//SettingsViewModel/IsShowBalloon")
nNode.text = "false"
strResult = xmldoc.save(filePath)
systemutil.CloseProcessByName "UFTRemoteAgent.exe"
This time I made sure it works ;)
I totally understand your pain because my projects also need to interact with IE download bar. Usually, I use SendKeys to handle download activity in different projects.
When download bar comes out, you can send ALT+N first to set focus on download bar, then send some tab keys to select on Save, and some Down Arrow key to select SaveAs.
In this way, you don't need to bother handle UFT notifications...
Sample SendKeys codes can be easily Googled.
Can you activate the desired browser with the following, and then try to do Save as
hwnd = Browser("title:=.*").GetROProperty("hwnd")
Window("hwnd:=" & hwnd).Activate
How can I disable those 3 standard cut/copy/paste commands in the context menu of the native Windows OS edit control?
I also need to disable the equivalent clipboard-related commands like CTRL+C/CTRL+V.
Is there a special edit control style or anything else we can use to disable all copy/paste operations with one easy setting?
Typically, when a control displays a popup menu, a WM_INITPOPUPMENU message is generated which "allows an application to modify the menu before it is displayed, without changing the entire menu."
Unfortunately, a standard Win32 Edit control does not generate that message for its default popup menu, as confirmed in a November 2000 article of MSDN Magazine (the link on MSDN itself is dead, but this link is from the Internet Archive):
MSDN Magazine, November 2000, C++ Q&A:
Q: Why isn't a WM_INITMENUPOPUP message generated when you right-click an edit control?
A: I can't tell you why there isn't one, but I can confirm it's true ... edit controls don't send WM_INITMENUPOPUP. The edit control must be calling TrackPopupMenu with a null HWND handle and/or TPM_NONOTIFY, which tells the menu not to send notifications. It's possible (and again I'm only guessing) that the authors were trying to improve performance by reducing message traffic ... In any case, suppose you want to add your own menu items to the edit control context menu. How do you do it? Alas, you have no choice but to reinvent the wheel
So the only option available is to subclass the edit control and handle the WM_CONTEXTMENU message instead, creating and displaying your own custom popup menu as needed. Which means you have to manually duplicate the functionality of any standard menu items that you want to appear in your custom menu.
Update: there is a way to access and modify the edit control's standard popup menu after all (I just tested it and it worked). TecMan provided a link to a VBForums discussion that talks about it, however it gets a few details wrong. I got the correct details from a PureBasic forum discussion.
The correct approach is as follows:
subclass the edit control to intercept the WM_CONTEXTMENU message. Either SetWindowSubClass() or SetWindowLongPtr(GWL_WNDPROC) can be used, though the first is preferred.
when the WM_CONTEXTMENU message is received, call SetWindowsHookEx() to install a thread-local hook (use 0 for the hMod parameter and GetCurrentThreadId() for the dwThreadId parameter). Either a WH_CBT or WH_CALLWNDPROC hook can be used. Then dispatch WM_CONTENTMENU to the default message handler via DefSubclassProc() or CallWindowProc() to invoke the standard popup menu.
inside the hook procedure, when a HCBT_CREATEWND (WH_CBT hook) or WM_CREATE (WH_CALLWNDPROC hook) notification is received, pass the provided HWND to GetClassName(). If the class name is #32768 (the standard window class name for menus, as documented on MSDN), post (very important!) a custom window message using PostMessage(), specifying the menu window's HWND in the message's WPARAM or LPARAM parameter, to any HWND that you control, such as your main window, or even the edit control itself (since it is already subclassed). You will need the menu's HWND in the next step. You can optionally now uninstall the hook at this time, or wait for DefSubclassProc()/CallWindowProc() to exit (it will exit after the menu has been dismissed). You need to use PostMessage() because the menu window has not created its HMENU yet at this time. PostMessage() delays the next step until after the HMENU is ready.
when the custom window message is received, send a MN_GETMENU message via SendMessage() to the menu's HWND that you obtained from the hook. You now have the menu's HMENU and can do whatever you want with it.
to disable the Cut, Copy, and Paste menu items, call EnableMenuItem(). Their menu item identifiers are the same values as the WM_CUT, WM_COPY and WM_PASTE messages, respectively (this is not documented by Microsoft, but is consistent across Windows versions).
Update: I just found a much simpler solution (which also worked when I tested it).
subclass the edit control to intercept WM_CONTEXTMENU, as described above.
when the message is received, call SetWinEventHook() to install a thread-local event hook (set the hmodWinEventProc parameter to 0, the idProcess parameter to GetCurrentProcessId(), the idThread parameter to GetCurrentThreadId(), and the dwFlags parameter to 0 - not WINEVENT_INCONTEXT!). Set the eventMin and eventMax parameters both to EVENT_SYSTEM_MENUPOPUPSTART so that it is the only event you receive. Then dispatch the message to the default handler to invoke the popup menu.
when your event callback is called, the menu has already been fully initialized, so you can send the MN_GETMENU message to the provided HWND, which will be the menu's window (the callback's idObject parameter will be OBJID_CLIENT and the idChild parameter will be 0).
manipulate the HMENU as needed.
unhook the event hook when done using it, as described above.
As you can see here, this does work.
Before modifying the menu:
After disabling the menu items:
Even deleting the menu items:
You could leave the options visible but lock the clipboard from usage.
If this solution suits you all you need to do is make a program that opens the clipboard by calling OpenClipboard(NULL). In order to release the clipboard call CloseClipboard().
One approach (similar to hypmir's idea but not quite as intrusive) is to simply overwrite the clipboard with "DATA REMOVED BY TecMan" whenever it is updated. You could do this as a registered clipboard viewer.
Open the clipboard, clear all formats, add CF_TEXT with the notice, close it.
I would use a short delay (maybe a timer callback) so that you make your update AFTER the first update has been processed by any other registered clipboard viewers on the system.
Your mileage may vary.
Abusing the clipboard like this is never a good idea.
I found one interesting idea of how to get the handle of the edit control's context menu on vbforums.com:
http://www.vbforums.com/showthread.php?776385-RESOLVED-Modify-right-click-context-menu-in-standard-controls
It demonstrates how to add custom context menu items to the standard OS context menu. I think, this idea can be used to modify the menu too. Theoretically I need to enumerate the menu items and disable the items related to the copy/paste commands. The question is how to know whether a menu item is related to copy/paste? Getting the menu item text is a bad idea ;)
Another problem of that code is that it is based on some Windows features that are not documented. I've checked the solution, it still works in Windows 10, but who knows how the edit control context menu may be changed in the future updates of the OS...
I have developed a COM component (dll) that implements an Edit() method displaying a WTL modal dialog.
The complete interface to this COM component corresponds to a software standard used in the chemical process industry (CAPE-OPEN) and as a result this COM component is supposed to be usable by a range of 3rd party executables that are out of my control.
My component works as expected in many of these EXEs, but for one in particular the Edit() method just hangs without the dialog appearing.
However, if I make a call to ::MessageBox() immediately before DoModal() the dialog displays and behaves correctly after first showing the MessageBox.
I have a suspicion that the problem may be something to do with this particular EXE running as a 'hidden window application'.
I have tried using both NULL and the return value from ::GetConsoleWindow() as the dialog's parent, neither have worked.
The dialog itself is an ATL/WTL CPropertySheetImpl.
The parent application (EXE) in question is out of my control as it is developed by a (mildly hostile) 3rd party.
I do know that I can successfully call ::MessageBox() or display the standard Windows File Dialog from my COM component, and that after doing so I am then able to display my custom dialog. I'm just unable to display my custom dialog without first displaying a 'standard' dialog.
Can anyone suggest how I might get it to display the dialog without first showing an unnecessary MessageBox? I know it is possible because I've seen this EXE display the dialogs from other COM components corresponding to the same interface.
Are you using a parent for the Dialog? e.g.
MyDialog dialog(pParent);
dialog.DoModal();
If you are, try removing the parent. Especially if the parent is the desktop window.
Depending on how the "hidden window" application works, it might not be able to display a window. For example, services don't have a "main message loop", and thus are not able to process messages sent to windows in the process. i.e, the application displaying the window should have something like this:
while(GetMessage(&msg, NULL, 0, 0))
{
if(!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
in WinMain.
This isn't supposed to be reliable - but try ::GetDesktopWindow() as the parent (it returns a HWND).
Be warned - if your app crashes, it will bring down the desktop with it. But i'd be interested to see if it works.
It turns out I was mistaken:
If I create my dialog with a NULL parent then it is not displayed, and hangs the parent application
However if I create my dialog with ::GetConsoleWindow() as the parent then the dialog is displayed; it just fooled me because it was displayed behind the window of the application that launched the parent application
So now I just have to find out how to bring my dialog to the front.
Thanks for the answers ;-)
Whatever you do, do not use the desktop window as the parent for your modal dialog box.
See here for explanation: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/24/79212.aspx
To quote the rationale:
Put this together: If the owner of a
modal dialog is the desktop, then the
desktop becomes disabled, which
disables all of its descendants. In
other words, it disables every window
in the system. Even the one you're
trying to display!