Prerequisites:
I have a custom QItemDelegate which creates custom editor for treeview items.
The editor consists of a QLineEdit and QToolButton. The button is used to open the file dialog for selecting the file and placing it's path into line edit.
I use a call to QFileDialog::getOpenFileName to open the file dialog. The dialog is native Windows file dialog (this is important).
When the editor is created the first time, everything works ok no matter how often I press that button. But after the editor is closed and reopened again the first press on the button results in a crash. The reason of the crash is that my custom editor eventually gets deleted.
Here is some code:
void CCustomEditor::on_RunSetupBtn_clicked()
{
auto qFilename = QFileDialog::getOpenFileName(this,
"Select application to run",
QString(),
"Executable files (*.exe)");
if (qFilename.isEmpty())
return;
SetCommandLine(QDir::toNativeSeparators(qFilename), m_qParameters);
}
I have made some digging and found out that calling WinAPI function GetOpenFileName results in the very same way: my editor gets deleted (although crash doesn't happen). It seems that Qt calls it also internally.
I have tracked down the reason of why my editor gets deleted and found out that when getOpenFileName is called, active window changes and focus changes with it.
In the first case the focus is moved from TreeView item, but in the second case it is moved from the editor itself!
This results in the deletion of editor because of 'focus out' event.
It is important to say that this situation doesn't happen if 'DontUseNativeDialog' flag is set when file dialog is created. Therefore this should be a bug in Qt's window management between native windows and Qt widgets.
As a workaround of this bug I suggest the following solution: before making a call to getOpenFileName set the focus to the button itself.
m_pUI->RunSetupBtn->setFocus();
auto qFilename = QFileDialog::getOpenFileName(this,
"Select application to run",
QString(),
"Executable files (*.exe)");
The other workaround is to use 'DontUseNativeDialog' flag, but the resulting file dialog doesn't look native, in fact it is quite ugly.
If someone has a better solution, feel free to share.
I have a similar problem with getOpenFileName and getSaveFileName. My solution is, after getOpenFileName, getSaveFileName or at the end of the function set the windows as active with activateWindow().
Related
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...
Using Visual Studio 2010 and working with an MFC SDI Application.
I have a CMFCToolbar object owned by the Main Frame.
When the document in this application is created, the MainFrame calls a function to replace one of the buttons in the CMFCToolbar object with a CMFCToolbarMenuButton. The contents of the menu button are populated with information from the document. The menu creation always works. The call to ReplaceButton always succeeds. But there's a visual symptom of the call that I haven't yet figured out.
Any time ReplaceButton is called, the button disappears. Not only is it not drawn, it's not clickable. It's temporarily gone. I assume this is because there's a dangling reference to the old button, which I have just destroyed with the call to ReplaceButton.
I've tried calling Invalidate(), RecalcLayout() to trigger a re-draw, but neither has worked yet. The only reliable method I have for getting the button to show up is re-sizing the application window manually or by un-docking/re-docking the toolbar. I assume there's some kind of lower-level refresh that occurs in these situations, but I don't know how to trigger it manually.
Is there a way to make sure my button is drawn immediately?
Edit: code sample
Count = m_Doc->...->GetCount();
for (Index = 0; Index < Count; ++Index)
{
Caption.Format(L"%s", m_Doc->...->GetName());
m_pLayerMenu->AppendMenu(MF_ENABLED | MF_STRING, LAYER_DROP_SEED+Index, Caption.GetData());
}
m_wndBrushBar.ReplaceButton(ID_BRUSH_TERRAIN,
CMFCToolBarMenuButton(ID_BRUSH_TERRAIN, *m_pLayerMenu, GetCmdMgr()->GetCmdImage(ID_BRUSH_TERRAIN)));
Update:
Calling m_wndBrushBar.AdjustLayout() seems to stabilize the visual behavior of these CMFCToolbar buttons. So that's a partial solution.
Partial because of the following:
It's hard to tell what the real visual behavior is. It turns out that all visual settings/states are stored in the Registry with these MFC objects, and it can hold onto states of dynamically created objects that really alter the startup behavior of the app.
I've gone in to delete the registry values under
Current User -> "Local App-Wizard Generated Applications" -> [My App Name].
Done this a number of times, just to find out what the real behavior of my app is. Feel like I'm missing some fundamental knowledge with the current version of MFC. Lots of bugs arising from the registry deal.
Is there a way to prevent registry settings for certain objects, or to shut off this behavior altogether? Otherwise, I guess my shutdown process will have to be a LOT more thorough with resetting all the visual elements. Registry values seem to ignore, override, or bypass my startup code. I can code how I want an object to look at startup, but if there are values in the registry, it does no good.
You've discovered a sometimes annoying aspect for the CMFC code. That is, the concept of a Workspace. The Workspace manages the concept of the application state. I, too, have had problems like the one you describe. But, you have the flexibility to manage how those objects are recreated by overriding the LoadState () and SaveState () methods.
I'm trying to get a DialogBox with a check box to appear. I added it to the resource file, created the dialog template, and added the class and event handler for the dialog. As I understand it, now I just need to create an instance of the class and call DoModal().
So, I've gone back and done some investigating and played with the code some and this is what I have now
UsingMSPSK PSKDialog;
if( PSKDialog.DoModal() == IDOK)
{
}
else {
AfxMessageBox("Not IDOK");
}
CTempoDialog TempoDialog;
if(TempoDialog.DoModal() == IDOK)
{
}
When I run this, I get no dialog from the PSLDialog.DoModal() call, but I get the AfxMessageBox, then The TempoDialog appears. I stepped through the DoModal() call in the debugger and it seemed to run and return properly, so I can't figure out where my Dialog Box is going.
I just looked at the return value of the DoModal() call again, and it seems that it is exiting immediately, how can I fix that?
It should work to make the dialog visible - assuming the dialog template has the WS_VISIBLE style and so on. Maybe the dialog initialisation is failing? Does the "DoModal" dialog call exit immediately? This would indicate a failure to create the window.
What version of Visual Studio are you using? Version 6 used to not let you set breakpoints on code that was not yet loaded. Alternatively, make sure that the symbols are loaded. In the Modules window, right click the dll containing your code and choose "Load symbols". Are you making a debug build with symbolic information, or a release build? Make sure it is a debug build for the easiest debugging experience.
I'm not sure why this happened, but the check box I added was an ActiveX control, and it broke my dialog box. When I discovered the toolbox pane, and dragged a check box from there, it worked fine.
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!