I have CMenu instance on which I add multiple items. For one of the items I added in it, I set the MF_HILITE flag.
When I show the menu, the appropriate item get hi-lighted correctly, as requested. The problem is that it stays hi-lighted until I move the mouse over it and leave. I only want one item to be hi-lighted at the time. It seems that Windows does not un-light it when another item is hi-lighed.
How could I force it to be un-lighted as soon as another item get the hi-light? I could not find any mouse-over callback or message for the menu, and I could not find a invalidate either.
You're using MF_HILITE in a weird way. The item isn't actually highlighted, it's just drawn like it is. If the user presss enter, the "highlighted" item won't be selected.
You're probably looking for MF_DEFAULT.
It does not appear to be possible.
The internal state for the currently selected item in the menu can't be set. Using the MF_HILITE or HiliteMenuItem does not set the currently selected item, it only sets the visual style.
As a work-around, I have used a popup ListBox instead, which has all the features I need.
Related
I'm working on adding support in my app for full-height sidebars, as introduced in macOS 11.
The trick is, when the window tab bar is visible, I want to turn the full-height sidebar off. The two don't mix well when the sidebar content is different in each window, as it is in my app. See Xcode for an example of what I want to do (View > Show Window Tab Bar). See Preview for an example of what I want to avoid (open two multi-page PDFs and put them in a single tabbed window).
What's working:
I observe the window's tabbedWindows property, and toggle the fullSizeContentView flag in its styleMask accordingly. Thus the window's style updates as needed when I hide and show the tab bar.
What's not working: I need to have a sidebarTrackingSeparator item in my toolbar in order to have some items above the sidebar. But when fullSizeContentView is off, that item appears as a plain separator. I don't want it to be visible at all in that state.
There isn't a straightforward way to hide a toolbar item, especially if it doesn't have a view, which it turns out this one doesn't.
I tried removing the separator item and re-adding it when the window state toggles, but that leads to Cocoa throwing exceptions, complaining that only one tracking item can be registered at a time. This would seem to be a bug, but Xcode manages it somehow.
So how can I properly toggle my window and toolbar state without having that visible separator?
It looks like I've solved the problem by saving the separator item when I see it in toolbarWillAddItem, and then returning it from toolbar(_:itemForItemIdentifier:willBeInsertedIntoToolbar:) to avoid having a new instance created. That way, removing and re-adding the item works without having exceptions thrown.
The last little snag was to not remove and re-add the separator blindly. The window state may have been preserved across app launches, so I needed to not make assumptions about how the window would initially appear.
I've got some code that grabs the TaskBar buttons and their text from the windows TaskBar using User32.SendMessage with the TB_GETBUTTON message to retrieve a TBBUTTON structure (Win32 API via C# P/Invokes). But I'm trying to figure out how to then, once I have the handle to the button, grab the associated context menu text. There is some status information on there for a specific application that I would like to retrieve. The button text gets me some of it, but I need to the context menu text to complete it.
Any ideas?
This is not completely clear... Context menus don't have text, as such - they have menu items, each one of which will have text. By "context menu text", do you mean the text of the menu items in the taskbar button's popup/context menu? For example, "Restore", "Minimize" etc in the screenshot below?
If so, I suspect you're going about this the wrong way:
This menu doesn't belong to the button, but is the system menu of the window represented by the taskbar button. If the button has a context menu, this is probably for a grouped collection of windows, not one specific window (or even windows for one process.)
Making judgements based on the context menu of a window sounds like a dodgy approach to me, especially based on text since that will change depending on where in the world your user is located. Applications can also change the contents of this menu so there's no guarantee it will contain something you expect to be there. It would be better to check the window style, if it's minimized, etc, to find out the information that also affects the contents of the menu.
I'm going to answer this based on what your needs seem to be from the question, not what you've directly asked, since (a) it's not possible as asked and (b) I think you're trying to do something else. (As a general guideline, in a question it's good to state why you're trying to do something - and even maybe ask about that, ie 'how do I achieve X' - in case there's a better method than the one you're using. Here, X is probably 'find out information about this window' not 'get the text of the context menu', because that's probably only one possible method to get to X.) Also I think extracting data from the internals of a third-party application like Explorer (the taskbar is an Explorer window) is fragile and prone to break in future versions of Windows.
The system menu or window information (whichever one) belongs to application windows. Unless taskbar buttons are grouped (and then it's the subitems) one taskbar button corresponds to one specific window in the system. So what you want to do is find these windows. You do this by:
Using the EnumWindows function
Then for each window that is passed to the callback, checking the extended window style using GetWindowLong with GWL_EXSTYLE to see if the WS_EX_APPWINDOW bit is set
In addition, sometimes other windows are shown: these heuristics should help.
Each one of these windows is a window that should appear on the taskbar, Alt-Tab dialog, etc.
You say you're getting the text of the taskbar button - this is probably the window caption of the window, and GetWindowText is the canonical (read: probably a lot more reliable) way to get the caption of a window belonging to another process.
If you really want the popup menu, then:
Use GetSystemMenu to retrieve the handle for the system menu for the window. Applications can customise this, so if your app is doing this (and that's why you want the popup menu) ensure you pass false to the bRevert parameter
You can then get the number of menu items using GetMenuItemCount and for each one call GetMenuItemInfo to get info about each menu item. Pass true to the fByPosition parameter to indicate you're accessing the menus by position (since you know the count, you're getting item 0, 1, 2... count-1).
This fills a MENUITEMINFO structure, which (I think, I haven't ever had to code this so I haven't tested) will tell you the text associated with an item via the dwTypeData field "if the MIIM_STRING flag is set in the fMask member".
If you really want information about the window status, you can get this information using methods like IsIconic to see if it's minimized, GetWindowLong again to get other information, etc. I'd suggest you ask another SO question about how to get whatever specific information about a window for details.
Hope that helps!
My test needs to click a link from a rad tools menu that it can only find some of the time. Even when it finds the link ByText it cannot double click it. If I hover the menu item it will always find it. Cannot find a hover in Watin, otherwise I've tried refresh, sleeps, focus, keypress, WaitUntilExists, double clicks, etc. Its using a class rmText from rad tools.
The only thing I've found to work is hovering that drop down while the tests are running...
Wish I could just do that for a few seconds...
//process would be a menu item below the radtool menu item that only shows up when certain conditions exist (but always does with the hover)
if (ie.Link(Find.ByText("process")).Exists) //sometimes I get through here
ie.Link(Find.ByText("process")).Click(); // this works only if I hover
Might be that creating the menu item is taking some time. Calling Exists does check if it exists now, maybe if you wait a few (milli)seconds it will be there. Try calling
ie.Link(Find.ByText("process")).WaitUntilExists()
This will time out if the element never appears, otherwise you can savely call the click.
BTW maybe you can get rid of the exists check, WatiN does call WaitUntilExists by itself too before calling Click().
HTH,
Jeroen
Simple version
Is there any way to maintain focus on menu after clicking a menu command?
Detailed version
Specifically, I've made a menu with some menu item with checked property. The problem is that each time I click checked menu item the menu lose its focus. It can be pretty annoying when there is a number of menu item with checked property and I want to manipulate them at once.
The most elegant solution for the problem would be maintaining focus on menu, but I can't find a way to apply it. Is it possible? And if so, what's the way to do that?
Even if there would a solution for it, sooner or later you will enter a situation in which a numerical or string property is changed via the menu, and then it becomes even impossible to keep the focus on the menu (while the dialog requesting the number or string is on the screen).
The first, simple alternative would be to put the checkable menu items on a toolbar or ribbon (just like Word does with Bold, Italic, Underline, ...). Numerical/string properties can then also be added on the toolbar or ribbon.
A second alternative could be to have a more complete configuration dialog in which the user can change all the configuration items. The configuration dialog can co-exist with the current checkable items, so users simply changing one check and users changing many properties all get a quick way of doing what they want.
You might also pose this question on https://ux.stackexchange.com/ (this sibling site is more oriented towards good user interface practices).
I'm implementing a custom status bar menu, which has a custom view with NSSearchField. I'm updating number of menu items according to search results. The number of menu items is changed as user types in the NSSearchField. I've noticed, that if number of results stays the same, items titles are not updated (redrawn). How do I force them to redraw?
In the function, that rebuilds the menu I remove first all items and then create new items according to the search results.
Thanks,
Nava
I could achieve it by following approach: When the number of search results is the same, i don't recreate them, just change the title and call itemChanged:. When the count is different I recreate menu items. This works anyway. But I was advised anyway to get back from using menu for this purposes.
on the menu set menuChangedMessagesEnabled to YES when you want to update the menu:
[menu setMenuChangedMessagesEnabled:NO];
// change the menu
[menu setMenuChangedMessagesEnabled:YES];
The second invocation causes the menu to apply changes. The first one is so that you can batch a group of changes together.
That said, Apple guidelines discourages changing menus while they're open as users are not used to this and can be confusing. If it's feasible try to redesign your app so you can use something else, say a table or matrix, instead of a menu.