I'm trying to position my form precisely above the taskbar. Unfortunately my efforts are hampered by the fact that this.Height on my form returns a value which is 10 pixels smaller than the actual form (with all the borders, title bar, etc). I'm running Windows 7 with Aero. When Aero is turned off (and the borders are thinner), all works as expected. The form border style is FixedSingle. I don't want to implement Aero-specific hacks. What can I do to get the correct height?
Yes, Aero lies about the window size returned by GetWindowRect(). It is a rather important appcompat hack, without it far too many programs would have a client area that's too small. Unfortunately there's neither an API call nor a manifest entry that can be used to turn off the lie. The only way is to set the Windows version in the EXE header and mark it Vista compatible.
You can do so with Editbin.exe in a postbuild event:
set pathsave=%path%
set path=$(devenvdir);$(devenvdir)..\..\vc\bin
editbin.exe /subsystem:windows,6.0 "$(targetfilename)"
set path=%pathsave%
Beware that your program will not run in XP anymore after this.
UPDATE: this is now done by default in VS2012 and up when you target .NET 4.5
Related
I know XP is old, but I just have to know the issue here.
I don't see a way to provide a popup menu with anything like an icon or bitmap with a mask, only a bitmap. So, if I use a compatible bitmap, it will look transparent when the selection bar is not highlighting it, but when highlighted the entire graphic still shows (with a square button face color around it).
If I use a 32bit DIB with alpha, the transparent item just shows black (whereas Windows 10 handles the transparency fine - I presume Vista and Win7 would, too).
If I manually set all the A's to 0 in the DIB, it is still black (on Win10, the images where color would normally be appear white - I would have thought it would be transparent).
Anyway, was there ever a way to provide an icon (since it has a mask), or a bitmap with mask, to a menu so things like XP can handle it automatically (no owner draw)?
Is there a way to force loading of an .ICO file to be the 256 color version instead of the 32bit RGB/A version? I don't have a 24bit RGB graphic in the .ICO, so maybe XP would pick that if it existed instead?
I know GDI doesn't support alpha in all cases, but sometimes it does, and it appears the Windows version matters as well.
Does someone have a background on this, and can tell if this is a known XP issue with 32bit bitmaps?
On XP you must custom draw but not the entire thing, just the bitmap/icon.
On Windows 95/NT4 the only way to do this properly is to custom draw the entire menu item. Before Vista the menu look only changed once, the addition of flat menus in XP, so custom draw everything is certainly possible.
Some time around Windows 98/2000 the ability to set MENUITEMINFO.hbmpItem to HBMMENU_CALLBACK was added. Use DrawIconEx or a image list.
Vista added support for 32bit ARGB bitmaps. You should not use the callback method here because that will disable the new visual style.
See also:
Themed menu’s icons, a complete Vista and XP solution
MSJ cool custom draw
I have a large legacy application which is showing up with a perpetually grey border on every Windows 8 machine we run it on, while the other windows for other apps accurately use a color derived from the desktop background. For the life of me I can't find out why.
I've tried my best google-fu to crawl MSDN for APIs to control this but came up empty. The app looks like all others in Windows XP, Vista, and 7...just Windows 8 is grey in color. We definitely haven't added Win8 specific code to treat this otherwise.
It's just an MFC window on the outside, but inside it embeds a .NET/WPF component and a Direct3D 9-enabled visual area.
My best guess is it could somehow be related to having a Direct3D surface in the window, but I couldn't validate that anywhere.
Any help would be greatly appreciated!
Thanks
Edit: The grey matches the effect of not having focus, and we definitely do play games with window focus...so that could be it.
The problem was a developer overloaded OnNcActivate() and returned TRUE at the end. They needed to call up to the baseclass's (CWnd) OnNcActivate instead.
This was visible on Windows 7 as well if you looked close enough.
The Desktop in Windows 8 does not use transparency in window borders like Windows 7 and Vista did with the Aero Themes. If you are move the focus to another top window in your app, this could explain why your seeing the grey border. Try changing the colors for windows without the focus to something discernable from grey to verify that is what you are seeing.
Assume a GUI application is opened on three machines running Windows XP, Windows Vista and Windows7. In all the three machines, the screen resolution and the DPI settings are set to be the same value. Will there be a difference in the way the application is displayed on the screen in terms of number of pixels used and their position on the screen?
The reason for asking this question is:
I am using position based record-and-play method for GUI automation. Any change in the position of a control can impact the playback of the GUI recording. I want to be sure that a recording captured on Windowx XP platform works on Vista and Windows7 platforms.
Yes. The OS chrome (starting with window borders and titles) have different styles (e.g. Vista and Win7 will likely have Aero on and thus translucent title).
And that's before considering any OS dependent code in the application.
The menu bars will probably all be different sizes, so you'll probably need to record separately on all three machines.
Bearing in mind, that each user could have any number of accessibility settings on/off, any DPI setting, and also that features such as button sizes and window border sizes are different on each of these OS's...
No one here could possibly guarantee you'll be fine - the only way is to test.
A side note: there MUST be a better way than position based playback? I've used tools previously that can read screen text and base the automated navigation on that, which seems far more sensible, but still horribly flawed.
In a small project of mine I've came across the need of a collapsible group box.
Searching the Net, I've found one here. In one of the comments there's an improvement on the original code that uses the VisualStyleRenderer class in order to acquire the TreeView open and closed glyph.
Running the code it draws properly the Plus and Minus sing as Windows XP would draw it, however in Windows Vista and Windows 7 the glyph for open and closed nodes are small triangles.
What kind of interface, class or PInvoke, I need to use in order to acquire the right glyph?
By default, TreeViews have the same appearance as in XP in Windows 7 and Vista. To get the little arrow glyphs you need to set the window theme for the control:
SetWindowTheme(hwnd, L"explorer", NULL)
This can also be used for ListViews.
I'm not sure how the collapsible group box renders the collapse/expand button so I'm not sure how to get it to draw them with the Explorer theme.
I have an MDI application written in C++ that looks great under Windows XP. All of the MDI child windows end up looking like their parent window. Nice. However, under Windows 7 (and probably Vista), the parent windows have aero glass, and the child windows are this hideous unchangeable baby blue color (same as the Windows 7 Basic theme). So my application really looks very very bad.
You can see this same ugly behavior by launching Office 2003 and try looking at MDI child windows (perhaps in Excel). However, Office 2007 actually has three color themes - blue, silver, and black. These themes somehow carry through to the MDI child windows in Excel.
I don't know how Microsoft is doing this in Office 2007. I would love to know the trick. I need to hook and takeover the drawing of my MDI child windows and replicate what the Office 2007 team has pulled off. The problem is that I want to use all of the DrawTheme* calls so I get the gradients and rounded edges and buttons all drawn properly. And all of these system calls need a handle to a theme. But it doesn't seem to be possible to, for example, use SetWindowTheme to change to use the color scheme from another theme. At least as far as I can tell.
Anyone know how Microsoft accomplished this?
It's not a great solution, but poking around on the web, I found this article about how to place a WinXP rounded look into the squarish flat Win95/Win98/Win2k window style. It works by using BMP snapshots of the WinXP theme and than using bitblit functions to stretch them to appropriate sizes around the window frame border. I tried his demo software, and sure enough, it looks like WinXP Luna under Win7. I can use his example as a basis to hook and replace my MDI child window frame drawing.
The problem with this approach is that you either have to pick a titlebar width and stick with it and not respond to global theme adjustments that change the titlebar height, or you have to take many different BMP snapshots at different sizes. For my purposes, it is probably fine to just stick to one thickness and ignore user theme adjustments. Once in place, I can apply different themes just by BMP snapshotting them - so I could also apply the Office 2007 MDI child look as well.