I am creating a child window for a VST3 plugin and am finding that the style of the child is different to the parent - in fact windows seems to be picking up an older rounded style from somewhere when I am on windows 10 which has the modern square style.
I don't have control over the parent window style. In this scenario an audio workstation hands me a HWND that I use as the parent handle in
window->win32.handle = CreateWindowExW(exStyle,
_GLFW_WNDCLASSNAME,
wideTitle,
style,
xpos, ypos,
fullWidth, fullHeight,
parent_handle,
NULL,
GetModuleHandleW(NULL),
NULL);
I am using (a slightly modified - to accept a parent handle - and freshly compiled) version of GLFW to create the window.
Does anyone have an idea about where the style could be changing?
When I create the window as a parent window the correct style is applied. To create the child I am adding WS_CHILD to this. Digging out the exact style is hard because GLFW constructs it in a sequence of functions.
As a Late Edit. It seems similar to this problem reported with MDI windows
where MDI child window styles don't match the parent style from wayyy back in Win7 - but still is being mentioned.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/34b29567-28a1-4aeb-97d2-d1476ba856f5/mdi-child-window-appearance?forum=vcgeneral
Related
Please take a look at this screenshot:
As you can see, the "Executable modules" and "Threads" child windows are free to roam about in the sandbox-like "Themida" parent window, and if they get dragged past the edge the overflow simply gets hidden. How can I create this effect?
That is a Multiple Document Interface (MDI) application. The containing window, with the dark grey background is the MDI client window, and the windows inside are the MDI child windows.
The use of MDI has been discouraged by Microsoft for many years so you may wish to think twice about using it in a new application.
Simply set the window style to WS_CHILD, and the window will be confined in the parent client rectangle.
You can do this during window creation, or after using SetWindowLongPtr() and GetWindowLongPtr():
SetWindowLongPtr(hwnd, GWL_STYLE, WS_CHILD | GetWindowLongPtr(hwnd, GWL_STYLE));
P.S. You don't need to create an MDI application to have this behavior.
I tried to implement a switch-to-fullscreen mode for an ActiveX control. This currently works by removing and hiding the parent window and changing my control's placement and position.
However, I have a problem with switching between applications while the control is in fullscreen mode. If I switch to another application and then click on my window area (not in the taskbar), it seems to not be activated. You can see in the taskbar, that another application still has the highlight and on the main screen, my window is partly hidden behind the taskbar unless it has the focus.
I process the WM_LBUTTONDOWN window message to detect if my window is clicked. And I already tried to call the following WINAPI functions:
::ShowWindow(m_hWnd, SW_RESTORE);
::SwitchToThisWindow(m_hWnd, FALSE);
::SetForegroundWindow(m_hWnd);
::SetActiveWindow(m_hWnd);
::SetFocus(m_hWnd);
::BringWindowToTop(m_hWnd);
::SetWindowPos(m_hWnd, HWND_TOP, m_monitorInfo.rcMonitor.left, m_monitorInfo.rcMonitor.top, m_monitorInfo.rcMonitor.right, m_monitorInfo.rcMonitor.bottom, SWP_NOSIZE | SWP_NOMOVE | SWP_SHOWWINDOW); // SWP_NOACTIVATE, SWP_NOOWNERZORDER
I also tried to use ::SetWindowLongW(m_hWnd, GWL_STYLE, WS_VISIBLE); which surprisingly gave my window the focus back. But it then suddenly disappeared when trying to switch back from fullscreen mode again.
I have no idea why there are so many different functions that for me seem all to do roughly the same. But it doesn't matter as none of them worked anyway.
What is the/one correct way to behave my control correctly?
Windows might be getting a bit confused because you're filling the screen with a child window, but you want it to behave like a top-level (overlapped) window. The host application is probably not getting activated because you've hidden its window.
You might do better to create a new top-level full-screen window for full-screen mode. If this is owned by the top-level window that (ultimately) hosts your control then your new window will always be above it, so you don't need to hide the existing window. Activation should just work. In short, you want your window to behave like a pop-up modal dialog.
Adobe's flash player seems to do something similar. Full-screen playback is in a window of class ShockwaveFlashFullScreen.
I have a program which is not written by me. I dont have its source and the developer of that program is developing independently. He gives me the HWND and HINSTANCE handles of that program.
I have created a child window ON his window, using win32 api.
First thing I need is to make this child window have transparency on some area and opaque on other area(like a Heads up display(HUD) for a game), so that the user may see things in both windows.
The second thing that I need is to direct all the input to the parent window. My child window needs no input.
I know that WS_EX_TRANSPARENT only makes the child draw at the end like in painters algorithm.
I cant use WS_EX_LAYERED because its a child window.
p.s.
I have looked everywhere but didn't find any solution though there were similar questions around the internet.
Actually this is a HUD like thing for that game. I can't draw directly on parent window because of the complexity with multi-threads any many other reasons.
-- EDIT ---------------------------
I am still working on it. I am trying different ways with what you all suggested. Is there a way to combine directX and SetWindowRgn() function or directx with BitBlt() function? I think that will do the trick. Currently I am testing all the stuff as a child window and a Layered window.
You can use WS_EX_LAYERED for child windows from Windows 8 and up.
To support earlier versions of windows, just create a level layered window as a popup (With no chrome) and ensure its positioned over the game window at the appropriate location. Most users don't move the windows they are working with all the time, so, while you will need to monitor for the parent window moving, and re position the HUD, this should not be a show stopper.
Not taking focus (in the case of being a child window) or activation (in the case of being a popup) is more interesting, but still quite do-able:- The operating system does not actually automatically assign either focus, or activation, to a clicked window - the Windows WindowProc always takes focus, or activation, by calling SetFocus, or some variant of SetActiveWindow or SetForegroundWindow on itself. The important thing here is, if you consume all mouse and non client mouse messages without passing them on to DefWindowProc, your HUD will never steal activation or keyboard focus from the Game window as a result of a click.
As a popup window, or a window on another thread, you might have to manually handle any mouse messages that your window proc does get, and post them to the game window. Otherwise, responding to WM_NCHITTEST with HTTRANSPARENT (a similar effect to that which WS_EX_TRANSPARENT achieves) can get the system to keep on passing the mouse message down the stack until it finds a target.
OK friends, finally I did some crazy things to make it happen. but its not very efficient, like using DirectX directly for drawing.
What I dis:
Used (WS_EX_TRANSPARENT | WS_EX_LAYERED | WS_EX_ TOOLWINDOW) and () on CreateWindowEx
After creating the window, removed (WS_EX_DLGMODALFRAME | WS_EX_CLIENTEDGE | WS_EX_STATICEDGE) from window styles, and also removed (WS_EX_DLGMODALFRAME | WS_EX_CLIENTEDGE | WS_EX_STATICEDGE | WS_EX_APPWINDOW) from extended window styles.
This gives me a window with no borders and its also now shown in the taskbar. also the hittest is passed to whatever that is behind my window.
Subclassed the window procedure of the other window and got the
WM_CLOSE,WM_DESTROY, to send the WM_CLOSE or WM_DESTROY respectively to my window
WM_SIZE,WM_MOVE, to resize and move my window according to the other window
WM_LBUTTONUP,WM_RBUTTONUP,WM_MBUTTONUP, to make my window brought to the top, and still keep focus on the other window, so that my window doesn't get hidden behind the other window
Made the DirectX device have two passes:
In the first pass it draws all the elements in black on top of a white background and copy the backbuffer data to an another surface (so it give a binary image of black & white).
In the second pass it draws the things normally.
Another thread is created to keep making the window transparency by reading that black & white surface, using the SetWindowRgn() function.
This is working perfectly, the only thing is it's not very good at making things transparent.
And the other issue is giving alpha blending to the drawn objects.
But you can easily set the total alpha (transparency) using the SetLayeredWindowAttributes() function.
Thanks for all the help you guys gave, all the things you guys told me was used and they guided me, as you can see. :)
The sad thing is we decided not to use this method because of efficiency problems :(
But I learned a lot of things, and it was an awesome experience. And that's all that matters to me :)
Thank You :)
You can make a hole in the parent window using SetWindowRgn.
Also, just because it is not your window doesn't mean you can't make it a layered window.
http://msdn.microsoft.com/en-us/library/ms997507.aspx
Finally, you can take control of another window by using subclassing - essentially you substitute your Wndproc in place of theirs, to handle the messages you wish to handle, then pass the remainder to their original wndproc.
I'm wondering how to create windows like these alt text http://img824.imageshack.us/img824/997/this.jpg
I'm refering to the one that says Marquee selection tool... these ones. I'm also not referring to the skin. I know how to do my own drawing and what not, this is not the issue. It's because windows usually need a parent which means it should not be possible for these windows to overlap into the tools. The only windows that can do this are context menus and menus. How can I create this style of window? Thanks
I think you are confusing the concept of owner windows and parent windows. Only dialog controls have parent windows, and these are automatically clipped by the parent's client area. Other windows have owner windows. This is a weaker relationship. There's nothing stopping a window from overlapping its owner.
Also, I wouldn't assume that just because the toolbar launches the context menu that the toolbar window has a relationship with the menu window. It might or might not, depending on how things are coded behind the scenes.
In any case, just try it out. Use the TrackPopupMenu() to create a popup. You can have it overlap the owner window without difficulty. Any window without the WS_CHILD style will exhibit the same behaviour.
I am creating a program that displays a popup at certain times (just like some chat clients for example) on which the user can click. However, I do not want to take away the focus from the current application.
The way I'm doing it now is by using a HWND with WS_POPUPWINDOW and minimizing and then restoring the window. However, this steals the focus from the current application. Setting foreground or hiding and showing a window did not make it appear on the foreground. I would like to be able to keep using a HWND so I can use other elements in this window, but I have no idea how to give it foreground without stealing focus.
I use win32 and c++.
To show without activating:
ShowWindow(hwnd, SW_SHOWNOACTIVATE);
To raise without activating:
SetWindowPos(hwnd, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE);
Unfortunately this is not working for me. The window is created with CreateWindowExA and is showed using ShowWindow(hwnd, SW_SHOWNOACTIVATE) however the keyboard focus is still stolen from the window which has the focus at the moment of the creation. (The window is created with layered and trasparent attributes by using SetWindowLong() and SetLayeredWindowAttributes() ).
PS: The window which has the focus is not parent of the new created window.
Solved: It worked when I removed the SetForegroundWindow call. This function cause the window passed as parameter to be activated.