The latest version of Microsoft Office uses property sheets that have the context help [?] button next to the close button:
When the context button is clicked it invokes the application's help rather than switching to 'context mode', by which I mean the arrow cursor with a question mark, i.e. there is no context help despite this being the context help button (or appears to be).
I'm trying to recreate this behaviour in an property sheet derived from the MFC CPropertySheet. So far I've had no luck. Ideally I'd like a click on this button to act in the same way as pressing F1, e.g. call directly on to the OnHelpInfo function.
Can anyone tell me how this might be achieved?
As per my comment, adding ON_WM_SYSCOMMAND to the message map and then processing SC_CONTEXTHELP in OnSysCommand did the trick.
Related
I was originally thinking this would be extremely easy to do. Google searches returned results for everything but this.
I am trying to have a normal button that I can click, and it stays down, click again, and it rises back up.
I found one function that did what I wanted, but only worked if the button retained focus, click anywhere else and it rises again.
Button_SetState(GetDlgItem(hwnd, IDC_BTN_SLEEPCLICK), TRUE);
Is there any real way to do this? Or am I gonna need to do this kind of thing by hand?
Thanks.
Create a check box, then set the "push like" property for that check box to true.
You want a checkbox with BS_PUSHLIKE style. To toggle it programmatically, use Button_SetCheck
The "staying down" and "rising back up" are a matter of how you draw the button.
You could create your own button class by using the Paint and Redraw methods.
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.
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.
I am creating an MFC SDI explorer style application (it has a splitter bar and the right-hand pane is the text-edit area, left-hand pane is the tree-view)
My right-hand pane is a CRichEditView.
I want to be able to detect when a user has edited the text so that a flag is set to show that a change has been made but has not been saved. I have tried several ways of doing this e.g. catching WM_KEYDOWN in PreTranslateMessage, but this catches everything and prevents the keypresses from editing the view. I have also tried adding ON_WM_KEYDOWN() to the message map in the MyView.cpp. Again, this seems to prevent the keystrokes from having any affect on the text in the view. I want to allow the user to edit the text in the view, but the application to know that this has been done.
Please help - I have looked for hours for ways to do this.
Many thanks
Adding ON_WM_KEYDOWN() to the message map is probably the correct approach. You must make sure that your implementation of the OnKeyDown() method calls the base class method so that the message gets passed on as appropriate.
How would one prevent the little dotted square that appears on a button when it has the keyboard focus in a dialog. (w/ apologies for the technical jargon). At one point I hacked together a solution by subclassing a button WindowProc and subverting some windows messages, but wanted to know the correct way.
There's actually a problem with another control in the dialog also involving the keyboard. This other control is actually also a button, but being used as a group box or panel, not as a functioning button. But when I hit the tab key in the dialog, this group box "button" comes to the foreground obscuring the static controls on top of it, so I wanted to prevent that.
For both of the above, I tried turning off WS_TABSTOP - didn't help.)
Both of my problems mentioned above were solved by subclassing the WndProcs and returning 0 in response to message 0x128 and discarding it. Even Spy++ could not identify this message 0x128, and I don't have it in any header. But its sent to every control in the dialog the first time tab is hit in the dialog.
(I did try BN_SETFOCUS as described above and also WM_SETFOCUS but it didn't help.)
So if anyone knows where to find what windows message 0x128 is...
The correct way is to write your own button control instead of using the default Windows one.
Alternatively, you can prevent if from ever getting keyboard focus.