I have question regarding the CreateWindowEx function. I have 2 windows, a main one and a popup one. I want a popup window to hide everywhere. It is currently not displayed in taskbar and it is not even visible in alt+tab menu. However it is visible on "Applications" tab in task manager. What flags do I need to use in CreateWindowEx to hide my popup window from there?
Current code:
hHistoryWindow = CreateWindowEx(WS_EX_TOOLWINDOW | WS_EX_NOACTIVATE | WS_EX_LAYERED, szAppName, L"HistoryWindow", WS_EX_TOPMOST | WS_POPUP, WIDTH, TOP, width, height, NULL, NULL, hInstance, NULL);
I also wanted to ask, whether I need to release a bitmap resource from "static" window before using DestroyWindow() function? I set image to a "static" window this way:
SendMessage (hStatic, STM_SETIMAGE, (WPARAM)IMAGE_BITMAP, (LPARAM)hWhiteStone);
Is it enough to release hWhiteStone or do I need to release also handle returned by SendMessage() (- or is it done automatically by DestroyWindow)?
Thank you for any info.
Kra
Make it a child of your main window. Do this by changing the fourth last parameter to the HWND of your main window. This SHOULD make windows treat your popup window as part of the same application as your main window.
Related
So I have a window, and I have coded it so that during run-time it can enter and exit full-screen mode. Entering full-screen works, but exiting places the window tile bar in reverse order.
Exit full screen code:
SetWindowLongPtr(hWnd, GWL_EXSTYLE, WS_OVERLAPPEDWINDOW);
SetWindowPos(hWnd, HWND_TOPMOST, 0, 0, 640, 480, NULL);
InvalidateRect(hWnd, NULL, TRUE);
Picture of the result: https://www.dropbox.com/s/p15eltz7b2hxx4y/window.png?dl=0
I tried using GWL_STYLE instead of GWL_EXSTYLE but that works even worse, with the window being visible but clicking anything on the window will act like the window is not there and the click on whatever is behind it...
Thanks!
Philip
Just a thought, couldn't you get the window style (with GetWindowLongPtr), store it as a member variable in you class and then use this as the style to reset in SetWindowLongPtr?
Following is uncheck code (this is assuming you are using C++),
MainWnd::OnFullScreen(...)
{
m_oldStyle = GetWindowLongPtr(GWL_EXSTYLE, m_hwd);
/*
what ever other code is necessary
*/
}
MainWnd::OnExitFullScreen(...)
{
SetWindowLongPtr(m_hwn, GWL_EXSTYLE, m_oldStyle);
/*
and other code as needed
*/
}
I've made two assumptions here:
(1) that you will have two variables, one to contain the old style (m_oldStyle) and one to hold the handle to the window (m_hwd). Note if you are doing strict SDK style coding then the handle will be passed to you as part of WndProc. If you are using MFC there should be member function in the class you derived you main window from. In other cases you are on your own.
(2) the second assumption is that SetWindowLongPtr is called prior to any change of screen type. I believe that SetWindowLongPtr is called during window construction, but it has been several years since I've done serious windows programming using Microsoft frameworks (now I tend to used QT's framework).
My application initially had a window (Def). Then it spawned a new window (New). All the two windows can be switched from the Window sub menu item or by the space control.
But if I tried to set the "New" window to a fake full screen mode on OSX 10.6.8, there would be a problem that if I switched to the "Def" window either by menu or space control. I cannot "fully" switch back to "New" window.
// setting a fake full screen window on 10.6.8
NSApplicationPresentationOptions prereqOptions =
NSApplicationPresentationAutoHideDock |
NSApplicationPresentationAutoHideMenuBar;
[[NSApplication sharedApplication]
setPresentationOptions:prereqOptions];
[[self window] setToolbar:nil];
[[self window] setStyleMask:NSBorderlessWindowMask];
[[self window] setFrame:[[NSScreen mainScreen] frame]
display:YES];
The "fully" means I can see the "New" is brought to the top of screen, but the window controller cannot receive the notification "NSWindowDidBecomeKeyNotification". Furthermore, by
[NSApp keyWindow], I can see the key window is always the "Def". And I can always see the "Def" is checked in the Window submenu.
Anyone had ever encountered this issue?
Finally after 2 days investigation, the answer goes back to the documentation of NSWindow.
There are two related methods.
(BOOL)canBecomeKeyWindow
Return Value
YES if the window can become the key window, otherwise, NO.
Discussion
Attempts to make the window the key window are abandoned if this method returns NO. The NSWindow implementation returns YES if the window has a title bar or a resize bar, or NO otherwise.
And
canBecomeMainWindow
Indicates whether the window can become the application’s main window.
(BOOL)canBecomeMainWindow
Return Value
YES when the window can become the main window; otherwise, NO.
Discussion
Attempts to make the window the main window are abandoned if this method returns NO. The NSWindow implementation returns YES if the window is visible, is not an NSPanel object, and has a title bar or a resize mechanism. Otherwise it returns NO.
So the conclusion is that if the window doesn't have a title bar or resize bar, it by default cannot become a main and key window. When setting the window to the fake full screen on 10.6.8 by [NSWindow setStyleMask:NSBorderlessWindowMask], the title bar is gong.
To resolve this issue, one needs to override the above 2 methods with returning YES.
I'd like to use Shell_NotifyIcon() to add an icon to the system tray but I do not want to have a visible window in my application. That's why I'm passing a handle to a message-only window to Shell_NotifyIcon(). The window has been created like that:
hTrayWnd = CreateWindowEx(0, CLASSNAME, "tray_dummy", 0, 0, 0, 0, 0, HWND_MESSAGE, NULL, HINSTANCE, NULL);
CLASSNAME points to the name of my class that I've registered using RegisterClassEx() and HINSTANCE is the handle of my instance.
Now the problem is: The tray icon is added but the WindowProc() of my class is never called. If I use a normal top-level window instead, everything is working fine.
Is there no way to create a tray icon without a top-level window? I've seen apps having a tray icon without a top level window so it must be possible somehow. But why does it not work with a HWND_MESSAGE window?
Thanks!
Oops, sorry, it was my fault. The reason why it didn't work was that I called CreateWindowEx() from a different thread. When I use the main thread it is working fine.
I have a WIN32 application. Its main window is hwndMain, one of its child is hwndView. There is one tab control hwndTab on hwndView.
When I resize hwndMain, hwndView is resized and so is hwndTab. It flicker a little, but not much.
I have tried to use WS_EX_COMPOSITED style ( for hwndView or hwndTab), but it just gave me blank window. I tried to use WS_EX_TRANSPARENT and it solves flicker, but when the windows is resized to be larger, the childs are updated very slow, e.g I see black region for one second, then the region is updated.
I have successfully sloved the flicker issue for TreeView by using WS_CHIPCHILDREN style. (See remark below). But using WS_CHIPCHILDREN stlye for hwndView doesn't fix the flicker issue for tab control.
I have paid attention to WM_ERASEBKGND and Not set hbrBackground also.
I want to use double buffer for tab control, but I can't find a tutorial for this purpose. All the tutorial I found is: In WM_PAINT, after creating CompatibleDC and CompatibleBitmap, draw what you want in memdc and.....; But I don't want to do any custom drawing in WM_PAINT for hwndTab. I just want to leave the tab control do this job, but shows the final result only.
Could someone show me a small example how to double buffer a tab control (if you think this will fix the flicker issue of tab control), in the language c + winapi, since I don't have the knowledge of C#, Net,..etc.
Remark: For my TreeView, it is a child of a window hwndContainer. It is created as:
win->hwndContainer = CreateWindowEx(
WS_CLIPCHILDREN,
_T("SUMATRA_PDF_TOCBOX"), NULL,
WS_CHILD,
0, 0, gGlobalPrefs.sidebarDx, 0,
win->hwndPanel, NULL,
ghinst, NULL);
Using WS_CLIPCHILDREN fix the flicker, even if I don't use double buffer. But it is strange to put
WS_CLIPCHILDREN in the first parameter position. If I put it after WS_CHILD, i.e
win->hwndContainer = CreateWindowEx(
NULL,
_T("SUMATRA_PDF_TOCBOX"), NULL,
WS_CHILD | WS_CLIPCHILDREN,
0, 0, gGlobalPrefs.sidebarDx, 0,
win->hwndPanel, NULL,
ghinst, NULL);
,then the flicker still occurs.
So I also tried to use the first way when I created hwndView, but it just gave blank white window.
I am really confused with these stuff.
Here is the blank window picture when I used WS_EX_COMPOSITED for hwndView.
There is no such problem when I used it for hwndContainer.
hwndView in fact has two child: a Tab Control hwndTab and a child which has its own double buffer and drawing. I am not sure if this cause the problem for using WS_EX_COMPOSITED.
You are using the WS_EX_COMPOSITED style. When you pass WS_CLIPCHIDREN as the first argument to the CreateWindowEx, it's interpreting the value of WS_CLIPCHILDREN as an extended window style. Since the value of WS_CLIPCHILDREN is 0x02000000L, the same as WS_EX_COMPOSITED, you've just created a composited window.
And a composited window, according to the documentation, has all of its descendants painted in a bottom-to-top painting order using double-buffering.
I'm not sure what you mean when you say:
I have tried to use WS_EX_COMPOSITED style ( for hwndView or hwndTab), but it just gave me blank window.
You'll have to post code the reproduces this problem. But your second-to-last code snippet is producing a composited window.
I'm using one 3rd party SDK which get hwnd (window handle) and paints something on my window. And i want to specify window painting region (left, right, top, bottom) ? How it's possible to do it ? I'm found WINAPI function SetWindowRgn, but it's not good for me because this function specify whole window region. I need specify just window painting area.
SetWindowRgn() is exactly what you need. You can create your region from a rectangle using CreateRectRgn(). A good introduction to window regions can be found here.
Alternatively you can modify the non-client area of your window, but I would not recommend that, because it has several side-effects.
If it's possible to give this library an HDC instead of the window handle - you should do this.
That is, get the drawing DC for your window's client area (GetDC), create the needed clipping region, and set it (SelectClipRgn).
In case your library insists on accepting the window handle - I can propose the following solution:
Inside your window create another child window, set the appropriate region for it. And give the handle of that window to your library.