For some fun and self-education, I'm tinkering with writing my own X11 toolkit. Here's something that's stumping me.
I have a traditional combo box display element, a typical combo box with a dropdown popup list, like all popular toolkits have.
For the dropdown popup list, I'm creating a new window, a child of the root window, appropriately positioned below the main combo-box display element.
The dropdown popup list is a window in its own full right, that implements keyboard-based navigation, to select the individual entries in the dropdown list.
So, I'm using SetInputFocus to set the input focus to the popup after it opens.
What I find is that when I do that, the window manager then redraws the frame of the main window to indicate that it no longer has input focus. Which is technically true, but I don't see the same results with the more mainstream toolkits, where, in the comparable situation, the main window's frame shows that it still has input focus.
For the pop-up window, in addition to setting override-redirect, I'm also doing everything I can think of, to tell the window manager what's going on: setting the window group leader ID in the popup window's WM_HINTS, setting WM_TRANSIENT_FOR, and setting _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_COMBO; none of that seems to work (I verified that the properties are approriately set, via xprop).
It seems like I have to keep the input focus in the combo box window, and forward keypress and keyrelease events to the display elements in the dropdown popup, which feels clunky. Am I overlooking some property that would tell the window manager that the popup's input focus is linked to the main window's (besides the ones that I've mentioned), that would keep the main window's frame drawn to show that it has input focus, when the input focus is actually in the popup?
Most X11 override-redirect exclusive popup windows (menus, combo boxes, ...) grab the keyboard and/or pointer with either passive or active grab.
See XGrabKey, XGrabKeyboard, XGrabButton, XGrabPointer in the X11 programming manual.
Or maybe don't, because the manual is totally unclear about what the heck these functions are and how they can be used. Search the interwebs for usage examples, probably in other widget libraries. Unfortunately I don't know of a simple informative example offhand.
It is not necessary to call XSetInputFocus at all because all keyboard and/or pointer events are reported to the grabbing clients.
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
I have a semi-transparent form (using AlphaBlend) that acts as an overlay. For the user to still be able to interact with the window below I have set WS_EX_NOACTIVATE on my form so all right and left clicks go through to the other window.
However I have a few clickable labels on my form. Clicking those and performing the appropriate action works fine since despite the WS_EX_NOACTIVATE flag the OnClick methods are called, but the click will (obviousely) also propagate to the other window, which I do not want in this case.
So, does anyone know how to "stop" the click being sent through to the window below in case I already handled it in my form ? Basically I would like being able to chose whether the click "belongs to me" and does not get propagated or whether the window below mine receives it.
As Rob explained, WS_EX_NOACTIVATE is not relevant here. Most likely you used WS_EX_TRANSPARENT and that made your window transparent to mouse clicks.
To get finer grained control of mouse click transparency, handle the WM_NCHITTEST message in your top level window. Return HTTRANSPARENT for regions that you want to be "click through". Otherwise return, for example, HTCLIENT.
Wm_ex_NoActivate should be irrelevant here. That just controls whether your window receives the input focus. Indeed, if you start with a scratch program and do nothing but change the extended window style, you'll see that when you click within the bounds of that program's window, the clicks are handled in the usual way, except that the window is never activated; programs behind that window do not receive any click events.
Therefore, to make your label controls eat click events instead of forwarding them to the windows behind them, you need to find out what you did to make them start forwarding those messages and simply stop doing that, whatever that is.
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!
I am trying to insert a custom widget into the Internet Explorer 8 url bar, next to the stop and reload buttons. This is just a personal productivity enhancer for myself.
The "window model" for this part of the IE frame is an "address bar root" window that owns the windows which comprise the IE8 url bar: an edit box, a combo control, and the stop and reload buttons.
From another process, I create a new WS_CHILD window (with a custom class name) that is parented by IE's address bar root window, thus making it a sibling of the edit box and stop/reload. I call SetWindowPos with an hwndInsertAfter of HWND_TOP to make sure it appears "above" (i.e. "in") the urlbar. This works nicely, and I see my window painted initially inside the IE urlbar.
However, when I activate the IE window, the urlbar edit control jumps back in front of my window. I know this is happening because I still see my window painted behind the urlbar, and because when I print ->GetTopWindow() to the debug console on a timer, it becomes the HWND of the urlbar edit control.
If I update my message loop to call SetWindowPos with HWND_TOP on WM_PAINT, things are better -- now when I activate the IE window and move it around, my control properly stays planted above the edit control in the urlbar. However, as soon as I switch between IE tabs, which updates the text of IE's urlbar Edit control, my control shift backs behind the Edit control. (Note: This also happens when I maximize or restore the window.)
So my questions are:
1) Is it likely that IE is intentionally putting its urlbar edit control back on top of the z-order every time you click on a tab in IE, or is there a gap in my understanding of how Windows painting and z-ordering works? My understanding is that once you specify z-ordering of child windows (which are not manipulable by the end-user), that ordering should remain until programmatically changed. So even though IE is repainting its Edit control upon tab selection whereas I am not repainting or otherwise acting upon my window, my window should stil remain firmly on top.
2) Given that the z-order of my window is apparently changing, shouldn't it receive a WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED? If it did, I could at least respond to that event and keep myself on top of the Edit control. But even though I can see my window painting behind the urlbar Edit control when I click on a tab, and even though my debug window output confirms that the address bar root's GetTopWindow() becomes the HWND of the Edit control when I click on a tab, and even though I see WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED being sent to the Edit control with an hwndInsertAfter of HWND_TOP when I click on a tab, my own window receives no messages whatsoever that would allow me to keep the z-order constant. This seems wrong to me, and addressing it would force me to run in IE's process and hook all messages sent to its Edit control just to have an event to respond to :(
Thank you for your help!
It's quite likely that IE is juggling the Z-order of the controls when you change tabs. In IE9, the URL bar and the tabs have a common parent. When you select a new tab, it activates the URL bar (and activation usually brings the window to the top of its local Z order).
No. You get WM_WINDOWPOSCHANGED when a SetWindowPos function acts on your window. If some of the siblings have their z-orders changed, you don't get a message. Nobody called SetWindowPos on your window. You can see this by writing a test program that juggles the z-order of some child windows.
This makes sense because there might be an arbitrary number of sibling windows, and it could be an unbounded amount of overhead to notify all of them. It also would be nearly impossible to come up with a consistent set of rules for delivering these messages to all the siblings given that some of the siblings could react by further shuffling the z-order. Do the siblings that haven't yet received the first notification now have two pending notifications? Do they get posted or dispatched immediately? What if the queue grows and grows until it overflows?
This is different from WM_KILLFOCUS/WM_SETFOCUS notifications in that it affects, at most, two windows. That puts a reasonable bound on the number of notifications. Even if there's a runaway infinite loop because the losing control tries to steal the focus back, the queue won't overflow because there's only one SetFocus call for each WM_KILLFOCUS delivered.
Also, it's reasonable that windows might need to react to a loss of focus. It's much less likely that window C needs to know that B is now on top of A instead of the other way around, so why design the system to send a jillion unnecessary messages?
Hacking the UI of apps you don't control and that don't have well-defined APIs for doing the types of things you want to do is anywhere from hard to impossible, and it's always fragile. Groups that put out toolbars and browser customizations employee more people than you might expect, and they spend much of their day probing with Spy++ and experimenting. It is by nature hacking.
In spite of there being a Human Interface Guidelines document (HIG), a lot of high quality Mac desktop applications use custom controls. My question is what is the best approach to start subclassing controls for Cocoa development? It surprises me how little (good) information there is on this topic. What path is the best to follow so you don't end up with a nice but half broken control?
Here's a checklist:
Make sure your control works correctly at double resolution. Use Quartz Debug to test this. You'll want to test both drawing sanity (in all states—normal, selected, pressed, disabled, and any others) and operation sanity (that hit testing matches where things appear on the screen/other destination device).
For extra credit, make sure your control works correctly at 1.5 (or some other, similarly non-integral) resolution.
Test how the standard control works when clicked. You'll probably do this anyway. Do as the standard control does.
Test how the standard control works when half-clicked (mouse down inside, mouse up outside).
Test how the standard control works when dark-side-of-the-clicked (mouse down outside, mouse up inside).
Test how the standard control works when dragged within.
Test above four with the other mouse buttons (right and middle).
Test what the standard control does when you scroll with a scroll wheel. Also test shift + scroll and, on a mouse that has them (e.g., most Logitech mice), scroll left/right buttons.
Test what the standard control does when you two-finger scroll in each axis and in both axes.
Test what the standard control does when you pinch and when you unpinch.
Test what the standard control does when you swipe with three and four fingers in each axis.
Test how the standard control works with “Full Keyboard Access” turned on. Can you tab into it? Can you press it with the space bar? Can you enter it with the return key? Can you tab out of it?
Test how the standard control responds to Accessibility queries. Use Accessibility Inspector. See the Accessibility Programming Guidelines for Cocoa for information on responding to accessibility queries and messages in your control.
Test your app—including, but not limited to, your custom controls—in VoiceOver. Blindfold yourself and try to use the app with VoiceOver alone.
If applicable, test printing your view. You can print to Preview if you don't want to kill a tree for your development process.
Test printing in other paper sizes. If you're in the US, test A4; otherwise, test US Letter. Test still other paper sizes (such as Legal and A3) if you're feeling thorough.
If you're implementing a scroller (poor you), test that your scroller responds correctly to the “Jump to the (next page|spot that's clicked)” preference in the Appearance pane in System Preferences. “Correctly” means it should do what the user selected.
Make sure it correctly implements all four scroll-arrow-position settings: One at each end (Mac style), both at the lower/left end (NeXT style), both at the upper/right end, and both at each end (power user style). As always, you need to both draw correctly and hit-test/react correctly. (Suggested by #radiofreelunch/by David Dunham)
Also, if you're implementing a scroller, make sure it responds to the “Smooth scrolling” preference correctly.
Test that it responds to different scrolling speed preferences correctly.
If you're implementing a text entry field of some sort, or any view that responds to some sort of special hot key (like Enter to send a message in an inputline), test right-to-left (Hebrew/Arabic) text input and alternate input methods. The Character Viewer is a good start.
Also, test that you don't break ctrl-q. For example, ctrl-q, tab should always enter a tab character. The same typically goes for option + (key), such as option-return in an inputline.
Test that it responds to different key-repeat preferences correctly.
If you implement any custom keyboard shortcuts (⌘ + zero or more other modifiers + one or more character keys) by means other than Cocoa's standard menu shortcut handling, test your custom shortcut behavior under Dvorak. There is no faster way to sour our perceptions of your app than to respond to ⌘' by quitting.
Show your app to users who've never used it nor seen any mockups before. Disqualify programmers. If they don't recognize your control as a (whatever it's supposed to be), redesign it. If you ever say “the scroller is over here” or “you need to click that”, you instantly fail.
Test that your control responds (or doesn't respond, if responding would be dangerous) when your app is in the background. (Suggested by #chucker.)
Test that your control responds, but does not bring the app forward, when your app is in the background and the user clicks on it with the ⌘ key down. (Suggested by #chucker.)
Test resizing your view. Among other things, this will ensure that you set the autoresize mask correctly. You're also looking for drawing bugs—distorted elements, gaps, etc. (Part of this suggested by #Bagelturf.)
If your control is, in fact, a control, send it sizeToFit and make sure that it does the right thing. (Suggested by #Bagelturf.)
If you work with mouse coordinates, don't assume that they will be whole numbers. Ensure that you handle fractional numbers, zeroes (positive and negative), and negative numbers correctly. (Part of this suggested by #Bagelturf.)
You might also consider splitting your control into a control and a cell. In the latter case, also perform all of these tests on your cell embedded in an NSMatrix and in an NSTableColumn.
If your control has a menu, test what happens when the control is at one or more edges of the screen. The menu should move over to not fall outside screen space.
If your control has a menu, test that the user can enter it with the down arrow key when using “Full Keyboard Access”. If it is also a text field (like a combo box), test that this only happens when the user presses the down arrow at the end of the text; otherwise, normal text field behavior should rule: Pressing down on a line that is not the last line should move the cursor down a line, and pressing down on the last line should move to the end of the line.
If your control has a menu, test that it stays open when clicked and does not immediately close when held open. There is a function you can use to do this correctly, and it is available in 64-bit.
If your control has a menu, test that it is navigable (all four arrow keys + Home, End, Page Up, Page Down), usable (spacebar/return press action), and cancellable (esc) with the keyboard.
Hard to add anything to Peter's list, but if you're doing a scroll bar, be sure it handles all the deviant placements of the scroll arrows (like DoubleBoth).