I need to display a tooltip over a window. I'm creating a second window with the tool tip and using SDL_RaiseWindow() to bring it to the top. However, doing that causes the tooltip to steal focus which is not what I want. Is there a way to bring a window to the top without changing focus?
Also, is there a way to set focus (mouse and/or keyboard) without changing the Z order of the windows?
The answer offered by Neil will only work under X11 as SDL_SetWindowInputFocus() is only implemented for that environment. In essence, the desired behaviour is otherwise not achievable. I have seen that there is a feature request in the SDL forums for an overload of the SDL_RaiseWindow() function to include an optional bool parameter to indicate if the raised window should also receive the input focus, or not. I hope they do implement that.
In any case, the support for multiple windows under SDL 2.x is a little weak. There is no built in support for the Z-order of different windows, and trying to build one based on the "painter's method" works, but leaves one no control over the input focus.
Old question, but this came up during my own search. You could try SDL_RaiseWindow() to bring your tooltip to the top, then use SDL_SetWindowInputFocus() on the main window to switch focus back to it.
I got this working sufficiently for my tooltips on mac by using SDL_WINDOW_ALWAYS_ON_TOP flag with SDL2:
SDL_CreateWindow(tooltip_window->name, x, y, w, h,
SDL_WINDOW_OPENGL | SDL_WINDOW_BORDERLESS |
SDL_WINDOW_ALWAYS_ON_TOP);
SDL_RaiseWindow(windowThatShouldHaveFocus);
// ...render what you want on that tooltip (SDL_RenderClear, SDL_RenderCopy, SDL_RenderPresent) & hide it with SDL_HideWindow
And when showing the tooltip:
SDL_ShowWindow(tooltipWindow);
SDL_RaiseWindow(windowThatShouldHaveFocus);
Related
I am trying to capture windows hidden behind my application. I am using windows 7 and VC++. I have tried printwindow() function which draws the both non-client and client area of hidden window, but captured window in the device context doesn't show desktop composition effects(aero effects). Instead it shows the captured window with windows 7 basic theme.
I have also tried with GetWindowDC() to retrive the DC of hidden window, and then Bitblt() it to memory DC but the captured window doesn't show non-client area (caption, close button, minimize button etc) correctly.
Anybody faced this issue?
Please help.
Click the link below. It leads to a MSDN site that lists all the existing Windows Functions ever of all history since Windows 95 up to Windows 8 (from period where Microsoft started Windows until present). It shows old windows functions of first Windows and new windows functions added for the new windows.
http://msdn.microsoft.com/en-us/library/windows/desktop/ff468919(v=vs.85).aspx
Anyway follow this site.
You will see the name of each function as a link.
Click any of them that you are interested.
Each link there leads to another MSDN site that explains all the basics knowledge that you must know about the function before using it, that you want to learn more. What that function does, its purpose, all its parameters and how to use each one, all their flags, all parameters types, return value and at last remarks section that shed more light and sometimes gives tips about the selected function.
Of course, you don't have to read all of them. Find in the list only the necessary functions to fit your needs. The functions that will solve your problem and answer your question that you posted.
By the way, I read your post, and I think that I found in the list the necessary functions that will do what you want to do, I will list them below, and say in one sentence what each does for what you need:
AnimateWindow - Enables you to produce special effects when showing or hiding windows. There are four types of animation: roll, slide, collapse or expand, and alpha-blended fade.
FlashWindow - Flashes the specified window one time. It does not change the active state of the window.
FlashWindowEx - Flashes the specified window specified number of times. It does not change the active state of the window.
Use these functions to achieve the aero effects that you want.
SetWindowPos - Changes the size, position, and Z order of a child, pop-up, or top-level window. These windows are ordered according to their appearance on the screen. The topmost window receives the highest rank and is the first window in the Z order.
Use this function to show the hidden windows on the top side (above all other windows) and on the screen front of you. The operating system will automatically draw the both non-client and client area of these windows without using any gdi, draw and paint functions yourself.
If you want these windows to return back to their previous state (where they were hidden), then save their state with GetWindowPlacement function and later call SetWindowPlacement to bring them back to their hidden state. You can try GetWindowRect and SetWindowPos instead to achieve the same goal.
I also think that you will be interested in GetWindowTheme and SetWindowTheme functions and all the draw theme functions (BackgroundEx, Edge, Icon, Text, TextEx).
There are more theme functions. Find in msdn and in other sites on the web.
I'm building an application to generate an array of colors based on a color chosen by the user.
The default on Mac OS X for color selection is to open a NSColorPanel containing multiple NSColorPickers. But, as the color selection process is the main interaction the user will have with the app, it'd be better to avoid the extra clicks and panel-popping in favor of a more straightforward way.
So, is there any way to add a NSColorPicker object to a window?
I know this is an older question, but check out NSColorWell. From the docs:
NSColorWell is an NSControl for selecting and displaying a single color value.
Interresting Question.
I strongly doubt it (but would love to be proven wrong). NSColorPickers are not NSControls (nor NSCells) so there's no clean wrapper to insert into a window.
Even if you were to instanciate an NSColorPanel and get a reference to its contentView and copy it (with all that defines the color picking controls) to your own window... there's no obvious way of obtaining the color value. NSColorPickers are plug-ins so you can't forsee the controls of a colorPicker.
The only other way I can see (and that's a stretch) would be to manually load the NSColorPickers plug-ins directly. I don't know how successfull this would be.
File a bug report and request the feature?
Is it possible to create an invisible X window? For initialization of an OpenGL ES 2.0 context, one has to create a X window manually, but I can't find a way to make it invisible. Since I'm only doing GPGPU I don't need an output window. In fact, it is rather annoying in my case.
I'm aware of a solution from an earlier question, where it has been pointed out to use InputOnly in XCreateWindow(). This, however, leads to the X error GLXBadDrawable. Probably because EGL requires the window to respond to graphics request. Is there another way? Maybe create it minimized? But I can't find anything on that either. Also setting the window's size really small doesn't help, since it always occupies the whole screen on my device (Nokia N9).
When you create an X window, it is created unmapped, so what about creating an InputOutput window and leaving it unmapped? Another option would be (if the window must stay mapped), to move it out of the screen.
I'm wondering how I can give the focus back to the window that it before my window got it. I've looked around and so far only seen functions to get, not release, focus.
I wonder if you just need the focus released, or do you need to focus on another entity instead, after releasing the focus from said entity?
If you need to know previous widget in your form tab order, take a look at QWidget::nextInFocusChain and QWidget::previousInFocusChain. You should be able to get next\previous widget in your widget's focus chain. Once you know it, you can pass focus to it.
If you're looking to get next\previous window in Z-order take a look at winapi GetNextWindow function (GW_HWNDPREV in wCmd parameter will return a handle to the window above the given window). Once you know the previous window you can bring it back to from using BringWindowToTop
hope this helps, regards
I'm creating a ToolTip window and adding tools to it using the flags
TTF_IDISHWND | TTF_SUBCLASS. (c++, win32)
I have a manifest file such that my program uses the new WindowsXP themes
(comctrl32 version 6).
When I hover over a registered tool, the tip appears.
Good.
When I click the mouse, the tip disappears.
Ok.
However, moving away from the tool and back
again does not make the tip re-appear. I need to hover over a different tool
and then come back to my tool to get the tip to come back.
When I remove my manifest file (to use the older non-XP comctrl32), the
problem goes away.
After doing some experimentation, I discovered the following differences
between ToolTips in Comctl32 version 5 (old) and Comctl32 version 6 (new):
New TTF_TRANSPARENT ToolTips (when used In-Place) actually return
HTCLIENT from WM_NCITTEST if a mouse button is down, thus getting
WM_LBUTTONDOWN and stealing focus for a moment before vanishing. This causes
the application's border to flash.
Old TTF_TRANSPARENT ToolTips always return HTTRANSPARENT from WM_NCHITTEST,
and thus never get WM_LBUTTONDOWN themselves and never steal focus. (This seems to be just aesthetic, but may impact the next point...)
New ToolTips seem not to get WM_TIMER events after a mouse-click, and
only resume getting (a bunch of) timer events after being de-activated and
re-activated. Thus, they do not re-display their tip window after a mouse
click and release.
Old ToolTips get a WM_TIMER message as soon as the mouse is moved again
after click/release, so they are ready to re-display their tip.
Thus, as a comctl32 workaround, I had to:
subclass the TOOLTIPS_CLASS window and always return HTTRANSPARENT from
WM_NCHITTEST if the tool asked for transparency.
avoid using TTF_SUBCLASS and rather process the mouse messages myself so
I could de-activate/re-activate upon receiving WM_xBUTTONUP.
I assume that the change in internal behavior was to accommodate the new "clickable" features in ToolTips like hyperlinks, but the hover behavior appears to be thus broken.
Does anyone know of a better solution than my subclass workaround? Am I missing some other point?
You're not the only one who has hit compatablity issues with tooltips between these DLLS.
I too have had nothing but trouble with the new tooltips in the themable common controls. We have already been monkeying with mouse messages and active/deactivating the tips before adding the manifest and theming our application - so it sounds like what your doing isn't too crazy.
We're still living with problems with TTN_NEEDTEXT messages being send constantly as the mouse moves (not just when hovering), positioning problems with large tips (maybe not something new), and odd unicode messages being sent instead of the ANSI versions (which I plan to post as a question at some point).
I don't know, but this sounds like a really "hard" problem (in the sense that all real-world) problems are really hard. I bet the underlying problem is something to do with the setting of the focus. Windows that manually do that are evil and generally suffer from all manner of bugs.