I would like to prevent the context menu from being closed in my win32 c++ application. I want to prevent closing the submenu when user clicks on a submenu item. Which message do i have to implement/override?
Haven't done win32 dev in a while, however just random thoughts that come to my mind - maybe will be helpful:
1) maybe you could try to show the context menu again right after the item was clicked
2) or do it the complex way - find, then subclass the context menu window, then intercept WM_CLOSE/WM_DESTROY messages
Overall this seems to be a weird thing to want to implement. Maybe the menu is not the right UI element if you want to keep it on the screen after the selection was made. Maybe you need a modeless dialog instead?
Please see the following article.
Related
Fig1:
Fig2:
As in Fig1, after I clicked radio button, the radio button seems not get correctly painted, seems 50% transparent.
As in Fig2, after I move my mouse to hover the radio button again, it got correctly painted.
I have no idea about what is going on behind.
What are the possible reasons?
By the way, after I pressed a shortcut key PrtSc to get a screenshot(a freeware: Greeshot), this problem disappeared.
One hint I just found is: the dialog holding the radios were in modeless mode. The problem disappeared after I showed it as a modal dialog.
Actually, to achieve below goals, I am implementing the message pump for this dialog. Perhaps I am doing something wrong in the message pump logic. Continue to check the pump.
My Goal: user can interact with other windows while showing this dialog, one exception is: user should not be able to interact with the parent dialog of this dialog in question, so that database transaction may be issued prematurally.
I used to have a similar problem within wxWidgets. Turns out it's a long lasting bug that really never had been fixed. I now use a workaround with a simple wrapper function that 'enables' the element (places focus on it) and then 'unfocuses' it. Not sure in your current setup.
As a result, it seems I did something wrong in the message pump for the dialog in question.
I am implementing the message pump for this dialog.
To avoid user interact with the parent dialog of the dialog in question, I was ignoring message for the parent dialog and to children of parent dialog.
After I changed the above logic to below, the problem got solved.
EnableWindow(hParent, FALSE);
EnableWindow(hParent, TRUE);
So, I think I was doing something wrong in ignoring message, not sure exactly where.
I have a set of instances of plotting view that's added/removed dynamically according to incoming signals from tcp port from another process.
In each instance, the user can right click to open a popup menu, invoked via wxWindow::PopupMenu.
If the plotting view instance is to got shutted-down dynamically while the popup menu is visible, the view instance window is closed while the popup menu is still floating. Then any GUI action crashes the application.
I've been going through the APIs for wxWidgets to find a way to programmatically close the popup menu in the plotting view destructor, but with no-luck.
I found this forum post suggesting it's an impossible thing to close the popup menu programmatically. But it's too old, so not sure if it's still valid assumption.
Here are the trials that failed till now :
Trying to call SetFocus and SetFocusFromKbd on the plotting view as a way to move focus.
Generating mouse left click event and send it to the popup menu.
Generating a keyboard event and send it to the popup menu.
PlottingView::~PlottingView()
{
cout << "Sending wxMouseEvent to the popup menu" << endl;
wxMouseEvent e(wxEVT_LEFT_UP);
this->GetPopupMenu()->ProcessEvent(e);
wxKeyEvent ke(wxEVT_CHAR);
ke.m_keyCode = WXK_DOWN;
this->GetPopupMenu()->ProcessEvent(ke);
ke.m_keyCode = WXK_RETURN;
this->GetPopupMenu()->ProcessEvent(ke);
// the rest of the destruction
}
So I will appreciate any idea to programmatically close this popup menu.
Platform:
CentOS: 6.7
wxWidgets 2.8.12
G++: 4.3.3
Edit #1
Note: For commenters and answers suggesting upgrading the wxWidgets version, it's a debate in my team for everyday. But the answer is still no.
Most of the trials has failed. But I found a workaround to stop crashing but the popup menu don't close.
The solution was to nullify the following members using their setters, so the menu callback won't access them.
this->GetPopupMenu()->SetInvokingWindow(NULL);
this->GetPopupMenu()->SetEventHandler(NULL);
The best is probably to delay destroying the underlying window until PopupMenu() returns. As it is, your program logic is very convoluted because you're dispatching the event which results in closing of the window from inside PopupMenu() function and this just can't end well, even if you could use wxUIActionSimulator to close the menu (but you definitely should consider upgrading your 15 year old wxWidgets version in any case).
After performing some Google-fu and searching Stack Overflow I've been unable to find a way to access the right click menu of an item and read data or select an item from it. I've looked up methods for SendMessage and PostMessage
What I've done so far:
This is an example of post here that would have been exactly what I want if it didn't use Qt and would work on an external application. Everything I've been able to find is about creating a right click menu when I just want to view an external application's right click menu.
I've tried getting the handle of the context menu using Spy++ but the menu just disappears as soon as I select the "Find Window" option in Spy++ (which is to be expected).
The only way I could think of doing this is using mouse_event to display the box but then I don't know where to go from there. I feel like this would also be very inefficient.
I'm working on some legacy code so I don't have a lot of choice in what I can use, if it's possible I'd like to not use libraries that aren't included in Visual Studio 2008.
What I'm trying to do:
I'm looking for a way to access the right click context menu in an external application and read the data in it and then select an item. I feel like this should be really simple but my research skills are subpar. If anyone can point me in the right direction I would really appreciate it.
Thank you for reading!
The only way you can get hold of a context menu is to make the application display it. It doesn't exist otherwise. (The other question you give as an example is regarding the Windows Shell menu which is designed to be useable)
A window gets sent WM_CONTEXTMENU when the user right clicks, so you could use SendMessage() to invoke the menu, or failing that just send a right click.
After a bit of googling, I think context menus have a classname of #32768, so you could use FindWindowEx to find a child window handle with the matching classname.
Once you have the window handle, you can use the MN_GETHMENU message to get hold of the menu handle.
How do I disable all the controls in a dialog window ? I know I could use
EnableWindow(FALSE);
but this doesnt seem like a good idea because now there is no way for the user to click "Ok" or "Cancel" button or press the "X" icon to exit. The dialog is like frozen.
What I am looking for is a way to disable all the controls in a dialog while providing some way for a user to exit.
Another solution is to do it manually by going through all the dialog controls and disabling them but this gets tedious. Any easy way ?
Thanks.
Sorry, but going through all of the controls and disabling each of them is the easy way.
You can write a general function to do this using EnumChildWindows or using a loop calling GetWindow(... GW_HWNDNEXT) until it returns NULL for the next window.
Just remember to skip disabling the window that has the IDCANCEL as the id.
I currently have some toolbar buttons with a small arrow on the side (TBSTYLE_EX_DRAWDDARROWS) that, when clicked, result in a popup context menu being displayed under the button. This is done by constructing a custom popup menu and calling TrackPopupMenu.
The client now wants to be able to select multiple options from the menu before it closes, so that multiple options can be be modified without the need to re-open the menu and wait for an intermediate redraw between each change.
For example:
User clicks dropdown button
Dropdown menu appears (modal, waits indefinitely for user action)
User clicks some item (e.g., toggle a checkmark)
Timer (e.g., 500ms) starts
If timer expires, the menu is closed and all selected actions are executed.
User clicks another item before the timer expires, go back to 4.
The best I can come up with is to redisplay the menu by calling TrackPopupMenu multiple times. This makes the menu "flicker" when you select an item, and will probably require me to start a thread in order to do the timeouts, which I would rather avoid.
Rather than a menu, put up a dialog box with the options on it. A dialog can easily do all that is required.
A menu that doesn't close when you click it will just seem wrong. A dialog that closes by itself will seem wrong too, but it's probably the least of two evils.
Edit: If there's anything I've learned with Microsoft, it's don't try to fight the default behavior. You're asking for trouble if you do.
If you're building your menu dynamically I can see how automatic sizing can be handy, but it's not hard to do in a dialog either - make the dialog really big and before it becomes visible, enumerate the children and take a union of all their rectangles, then resize to that. Checking the boundaries to make sure they're on-screen is just a few if statements with OffsetRect. Checkboxes are trivial; icons less so, but still not bad.
One additional enhancement that would be easy to add is to dismiss the dialog immediately on a double-click.
Following #Mark Ransom's answer, you should put up a dialog box. But you can make the dialog modeless and make it close itself when you click outside of it (i.e., the dialog loses focus). That way it could behave more like a menu.
Notice that normal menus never go away by themselves, you always have to click somewhere outside the menu (or one of its options) to make it disappear.