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
Related
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.
I am trying to install three application by creating custom dialog .Within Custom dialog there are checkbox and Onclicking checkbox and thereafter doing next I want my application to do file transfer ,install the prerequiste based on which checkbox is checked .I want this to happen for all the three application.Please suggest how to do it and how can we give the condition to do so.
Assuming you're talking about a custom dialog for a Basic MSI, I would suggest the following:
Ensure each application in question is part of a separate feature. If you go with the original dialog set, this would potentially let the user select them by feature name, or you could hide them. These features should have meaningful names, along the lines of App1, App2, App3.
Ensure your three check boxes are associated with different properties, such as INSTALL_APP_1, INSTALL_APP_2, INSTALL_APP_3. I show public properties here out of habit, but since they will be used in the same sequence (on the same dialog box, even), it's okay to use private properties. And use suffixes more meaningful than 1, 2, 3.
Adding multiple control events to the Next or Install button on the dialog box you described. For each feature you want to control this way:
Add an AddLocal control event, with an argument of the feature name (e.g. App1), conditioned to execute when the check box is checked (i.e. with a condition like INSTALL_APP_1
Add a Remove control event, with an argument of the feature name (e.g. App1), conditioned to execute when the check box is not checked (i.e. with a condition like NOT INSTALL_APP_1.
If you are going to show this dialog box during maintenance, you should also initialize the values of the check box properties (INSTALL_APP_1, etc.) so that merely going past this dialog box doesn't change their installation state. You can use feature-state condition syntax (!App1, etc.) to do so in SetProperty custom actions scheduled just before showing the maintenance dialog (e.g. set property INSTALL_APP_1 to the value 1 with condition !App1=3).
If these features are shown in a feature selection control, be sure to update the properties accordingly. Do so on the Next button of that dialog using a combination of the feature state and feature action syntaxes. The property should be 1 if the feature is currently installed and not being removed, or is being installed; it should be set to empty ({}) otherwise.
This is a lot of steps, but together they help ensure the features will act as a user expects. If he does nothing to change their state, they should persist as previously set. If visible in both the feature selection control and via check boxes, they should act in sync.
As far as prerequisites, if you mean the InstallShield concept of prerequisites, this you can associate prerequisites with the features for those apps. If you just mean other components inside your MSI, those work perfectly well with the features defined in step 1 as well.
I am facing a strange issue with my test automation scripts when executed through HP UFT 12.01
Our AUT is a web based application developed in actimize. During my test flow, lets say at 5th step i need to invoke a popup browser (child) from my main page. The new popup browser will not have any menus or back/fwd buttons.
3 out of 10 executions, during 5th step my main browser gets refreshed to invoke the popup and when popup rendered fully, contents and views got switched now. i.e., main browser has the contents which are supposed to display in popup window (with menu bar and back/fwd buttons) and pop-up window has main page contents (without menu bar, back/fwd buttons) & state when i performed click operation.
This is strange and i could not really conclude if its browser issue or UFT issue. I have also checked with functional team and they never faced, so this is happening only through UFT execution and speculating it could be UFT issue.. any help pls?
This sounds like it could be either:
1) an actual bug in your UAT
2) a problem with QTP object identification.
If it's #2, here's some things to check. First, make sure that QTP can correctly and reliably identify the two different "browsers". (i.e. while both are on the screen, use the "Highlight in Application" button found the Object Repository window while each of the objects is selected. I would try this for both a normal run and immediately after the browsers get switched (use a break point if necessary)
If there is a problem with QTP identifying the windows incorrectly, then you might want to add additional Description properties to the test object in the OR so that it can lock onto the right one more reliably. I usually use GUISpy to spy on something on the page, then in Object hierarchy I click on the top object (the browser), then click "Copy identification properties to the Clipboard" button, then paste the results into a notepad. Find one of those properties that uniquely identifies the browser objects from anything else. Sometimes I have to use the URL property (with some REGEX magic to isolate the specific page without making it TOO specific)
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'm currently developing a wp7 app (don't want to tell too much ;), but I'm struggling a little with the user interaction.
The main question, I'm not sure about is: Should I offer an explicit save button in dialogs and use the phone back button as cancel, or should I save implicit the time the user taps the phone back button ...
The more I think about, the more I'm unsure about the best user experience.
I already read the user experience and interaction guide from Microsoft, but there isn't any advice in there about that issue ...
Thx alot for your suggestions.
On page 68 of the Windows Phone 7 UI Design and Interaction Guide it states:
Changes to Application Settings should be immediately implemented. This means that a "Done", "OK", or other confirming dialog is not neededd. In some cases, even though the change has happened immediately, the user may not have feedback that the change has occurred until an ongoing event is completed or a future event occurs. Examples would be joining a secure Wi-Fi network or changing the frequency of alarms.
Keeping Application Settings brief and clear should be a design goal. Complex, multi-page, multi-level Application Settings can frustrate or confuse users into thinking that they have entered another application entirely.
Although the same page also goes on to say:
Immediately implement user-selected Application Settings without a confirming dialog box and provide a feedback method to indicate that the change has occurred.
Avoid creating Application Settings that have more than 2 pages (screens). Settings that require more than a single screen should use overlying half screens to avoid losing context when
the SIP Keyboard is displayed.
If a task cannot be undone, always provide the user with an option to cancel. Text entry is an example. Actions that overwrite or delete data, or are irreversable must have a “Cancel” button.
When using additional screens with commit and cancel buttons, clicking those buttons should perform the associated action and return the user to the main settings screen.
To keep the heading of settings control panels consistent, the heading for the settings page should look as follows:
SETTINGS
<CPL Name/ Application Name>
Applications that fetch data over the network must have an option to disable data usage.
So, I think you only get in to questions over explicit vs. implicit if you have multiple pages for settings, and if you do it sounds like the explicit would be the way to go with sub-pages, but implicit for the initial page.
You should use explicit saving of settings.
However, for data entered it will depend on the application and the data being entered.
It's typcial to include a save button (or equivalent) otherwise there's (probably) no way for the user to cancel out of a partially entered form. This can also cause issues if there are validation issues which would prevent the saving of the partially entered data.
It depends on the app though. There is no universal rule for this.