I am calling querying the extended window styles of a window using the GetWindowLog property and it is returning values in many cases that are not documented in msdn.
Particularly 0x00000800L and 0x00000100L or a combination of the two. Does anyone have information about these values, or a more complete list than what is documented on the msdn site?
I ran across this thread while looking for an answer to why this value changes when Microsoft Word "disappears" a window. I maintain an app that tracks the HWND values in order to do application sharing. This works well, but Microsoft Office applications often handle these in unusual ways. In this particular case, I found that if you do the following in Microsoft Word 2013:
Open two new documents in separate windows.
Save the HWND values for both windows.
Close one of the two windows.
Both HWND values will, when interrogated with the IsWindow, IsVisible, etc Windows functions, appear to be normal, still visible, etc. There's no way I can find to tell that one of the windows has been closed -- except this undocumented dwExStyle value. 0x800 will be 'on' in the window that's still visible, and 'off' in the window that isn't visible any more.
(BTW, I know you're not "supposed" to save HWND values this way -- but try tracking windows for sharing without saving this value -- not so easy!)
Since 0x00000100L is listed right on the Extended Window Styles page it is a little unclear to me if you mean the normal or extended style so I'll describe both.
Style:
Dialog & old (user32) controls
0xFFFF for control/dialog specific styles
Common control:
0x00FF is generally used by the shared common control styles (CCS_NORESIZE, CCS_TOP etc)
0xFF00 for control specific styles, for a toolbar you would have TBSTYLE_LIST, TBSTYLE_TRANSPARENT etc
ExStyle:
0x00000100L=WS_EX_WINDOWEDGE
0x00000800L=Don't know, undocumented flag maybe (Edit: ReactOS has/had 0x00000800 as WS_EX_MAKEVISIBLEWHENUNGHOSTED, that does not mean that it has the same meaning on windows since ReactOS is not 100% compatible with windows)
Jeremy, this is just a bug of GetWindowInfo (for any OS after Win98: 2k, XP, Vista, Win7).
see http://rsdn.ru/forum/winapi/3362548.all.aspx ("WINDOWINFO.dwExStyle error")
try small tester therefrom: http://files.rsdn.ru/42164/wi_exstyle.zip
kero
Related
Is there anyway to find out number of controls at run-time for a dialog in VC++.
No, not in general way. The suggested EnumChildWindows() or GetWindow() with GW_CHILD plus GetNextWindow() can be instructed to enumerate nested windows or not. But the problem is - how do you know if you should? A composite control may have multiple child windows that are NOT dialog controls, while there might be a window that groups multiple controls as their parent...
You need to specify - what exactly do you want to count. And, possibly - why? As this information may not mean much to you after all.
Explorer seems to always start my application with SW_MAXIMIZE (STARTF_USESHOWWINDOW is set in STARTUPINFO.dwFlags). I know that ShowWindow will use this value the first time you/Windows needs to display a window but it has the unfortunate consequence of maximizing a window that should never be maximized.
My window is created with CreateDialogIndirectParam and has the following styles: WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_CLIPCHILDREN|DS_MODALFRAME|DS_CENTER|WS_VISIBLE. Why does ShowWindow not check if WS_MAXIMIZEBOX is set before allowing STARTF_USESHOWWINDOW to force SW_MAXIMIZE? Is this a bug in Windows?
This happens on a HP Stream 7 with Windows 8.1. I'm not sure if Explorer does this because it is touch enabled or because of the small screen.
Is this Explorer behavior documented anywhere and is there a way to turn it off? What is the best way to stop Explorer (or any other parent process) from affecting my initial window mode? (I don't want to block people starting me with SW_*MINIMIZE*)
WinVer.exe in system32 has the same problem:
My first thought was to turn off STARTF_USESHOWWINDOW in the PEB if the parent wanted me to start maximized but that is too nasty and undocumented so I have not tried that yet.
Preventing any kind of size change (which is OK for my application since it is just a "modal" dialog) sort of works:
case WM_WINDOWPOSCHANGING:
((WINDOWPOS*)lp)->flags |= SWP_NOSIZE;
return true;
The problem is that the window position is still set to 0 x 0 like a maximized window.
A better solution seems to be to detect and correct the problem after WM_INITDIALOG:
case WM_INITDIALOG:
PostMessage(hDlg, WM_APP, 0, 0);
break;
case WM_APP:
if (IsZoomed(hDlg)) ShowWindow(hDlg, SW_SHOWNOACTIVATE);
break;
I am the proud owner of several HP Stream 7 tablets and I would like to add my 2 cents here. Microsoft has made an arbitrary decision that devices with screen sizes smaller than 8 inches will behave differently than the norm. A lot of users are somewhat aware of this, but unaware that this is where your problem originates.
Windows determines a screen's size by reading the EDID information from the screen, which contains sizing information in it, in centimeters.
If no sizing information is present in the EDID, or the sizing information is below Microsoft's arbitrarily chosen 8 inch threshold, you get this apparent misbehavior which is at the very least, aggrivating to those who notice it and don't want it.
The solution is to override the default driver for the monitor in Device Manager with one that informs Windows that the screen is in fact, 8 inches or larger.
To do so, you need to first read the EDID information from the registry with a tool such as Deltacast's E-EDID Editor (free, last time I checked), and modify the size values and save the modified file someplace you can find it.
After you have modified your EDID file and saved it, download Monitor Asset Manager from EnTech (also free) and use it to create an INF file.
Once the INF file has been created, you need to restart Windows with the Advanced settings menu and choose to Disable Driver Signing Enforcement, since the INF file you created won't be digitally signed. Once disabled, open Device Manager in Windows and update the driver for the monitor using the INF file you created. You will need to confirm that you do in fact want to install the unsigned driver file.
Reboot and Windows will now behave normally with the one catch that, the onscreen keyboard will now appear a different size and will have more options available.
Sadly, Microsoft can change this behavior in the future, so there is no guarantee that through the same flawed decision making process they used to implement this in the first place, they won't force it down our throats again, using a much more difficult to counteract method.
In my apps I use sometimes: ShowWindow(MyForm.Handle, SW_SHOW).
The documentation for ShowWindow function has a section for SW_SHOWNORMAL that says
"An application should specify this flag when displaying the window
for the first time".
Does it means that for every form (that I pass to ShowWindow) I need to keep a boolean var to see if the form was displayed or not and based on that I should use SW_SHOW or SW_SHOWNORMAL?
What is the deep meaning of SW_SHOWNORMAL?
The term normal is synonymous with restored. This terminology dates back to older versions of windows and nowadays all the MSDN documentation uses restored rather than normal or normalized.
So, SW_SHOWNORMAL sets the window state to restored and makes the window visible. On the other hand, SW_SHOW simply makes the window visible.
Back in the day, restored was called normalized, minimized was called iconic, and maximized was called full screen. If memory serves, that older terminology was still in use in Windows 3.1, but was changed with Windows 95 and NT.
SW_SHOW is often used in conjunction with SW_HIDE so if you were showing/hiding a window for some reason (e.g. based on a user action) you would use them in tandem. SW_SHOWNORMAL was originally used in the 'old' days when first showing a window.
SW_SHOWNORMAL is sometimes valuable if you want to make sure a window is not minimized (or maximized) at some particular point in the program (e.g. if the window might be minimized but you want to 'restore' it so the user can interact with it).
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 have searched through internet & found that there are no any direct method that disable nodes of CTreeCtrl control.
check one post at http://www.ucancode.net/faq/MFC_CTreeCtrl-CListCtrl.htm & also on codeguru.com but not clear about how to disable node of CTreeCtrl.
Well, I think, the article you linked, speaks the truth: It's not possible (at least not for Windows versions before Vista, see below). You have to program the workarounds recommended in the link to "simulate" item disabling. It means: Give the item a specific colour (light grey for instance) and catch all the events which can occur on a TreeView item and cancel the actions (like expanding/collapsing a node, and so on).
Here, http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/3350ba1e-1fcf-47fe-ab6b-e20c6b5afd91, the statement of the article is more or less confirmed by Microsoft experts. They recommend the same workaround (and actually link to the same article). Also note the link to http://www.codeproject.com/KB/tree/colortreectrl.aspx on how to change individual item colors which might help if you really want to start programming the workaround.
"More or less confirmed" means: There seems to be an exception for Vista and higher:
"CTreeCtrl::SetItemStateEx() supports TVIS_EX_DISABLED (described in TVITEMEX structure) style which disables treectrl node. But its only supported from Vista onwards."
I've seen that sometimes it is talked about a possible value TVIS_DISABLED of the state flag of the TVITEM structure and actually the MSDN of the old VC6 compiler contains a technical article (from 1994 before release of Windows 95 ;)) which says that such a state value should exist with the meaning: "The item is disabled and is drawn using the standard disabled style and color." This article was preliminary ("Please note that this article is based on preliminary information that is subject to change before the final version of Windows 95.") and obviously this value for item disabling did not make its way into the final release of Windows95 as you cannot find it in any VC header files.
So either you can make sure that your program is only used on Vista or higher computers (then it's probably easy with the extended state flag above) or it will be an ugly work (though doable and not necessarily very difficult).