I'm looking for some kind of a resource (website) that would list all possible window/dialog frame styles and their respective combinations with images. I'm only really interested in Vista, as my software won't support older platforms anyway.
I have a more specific case here too: I'm wondering if there are other ways to achieve a smaller-than-normal titlebar for my window than WS_EX_TOOLWINDOW? The tool window style would otherwise suit my needs, but in addition to the normal window border, it seems to add this one-pixel wide white border inside the black outline, and that just looks really ugly for my purposes.
I remember older versions of Adobe Photoshop (CS2?) having these ridiculously tiny titlebars on the tool windows, like 8-10px wide. I'm wondering if those can be done with normal winapi, since IIRC they came in vista flavour too, and conformed to whatever windows skin was in use..?
If it's Vista-only, you can try to use your own window decoration and use the Desktop Window Manager (DWM) API to still provide Aero Glass Theming.
On the other hand, if you're targeting Vista and later, you'll most likely not have to deal with low resolutions. Don't think too much about a few pixels more or less.
Related
Can I change Qt Creator's (latest version: 4.14.0, Windows 10) general GUI font size (or scaling)?
The problem is, my system display scaling is set to 250% and I have two options for high DPI compatibility in Qt Creator, but both have issues:
I can disable Creator's built-in High DPI Scaling and force System (Enhanced) in the Windows compatibility settings:
Or I can enable Creator's built-in scaling and leave the Windows compatibility scaling override turned off (Application scaling):
In the former case, it's actually a size I find very comfortable except the cursors are all too small and Designer gets wonky (plus it's tricky to layout GUI's because apps all run in System (Enhanced) mode from Creator).
In the latter case, the cursors and Designer work, and it's nice to not have heavy anti-aliasing everywhere, except the GUI font is too large for me, and everything feels cramped (especially the top bar, and the left bar reminds me of one of those old school children's telephones with the huge buttons). Plus the general GUI font is different enough in size from my editor font that the whole thing just feels jarring and kind of stresses me out.
So what I think I'd like to do, ideally, is use application scaling like in the latter example, but just shrink the GUI font size to match the former.
I think I ran through all the options thoroughly, and all I can find is settings for the editor window and the console, but not the rest of the GUI.
To be honest, I'm actually not entirely sure why they don't look the same; my expectation was that Qt's built-in High DPI support would take the scale factor into account in the same way that Windows' System (Enhanced) mode does, but I'm sure it's more complicated than that.
The problem is Qt automatically round up your 250% scaling to 300%. For Qt Creator application, you can create a "QT_SCALE_FACTOR_ROUNDING_POLICY" environment variable, and set it to "PassThrough". You can find details in this question: Qt Creator "too big" on 3840x2160 and 150% scaling on Windows 10.
It's also worth noting that Qt also behaves like this coding a GUI program. This can be fixed with:
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
Under Windows, when the DWM composition is active, there's a somehow "special path" for fullscreened OpenGL applications that prevents all other subwindows (popups, menus, tooltips) to be correctly layered on top of the fullscreened OpenGL window.
While this is useful for games and such, it's totally a pain for other fullscreen OpenGL applications (CAD, 3d editors, etc.). This problem is causing endless troubles for Qt users, see here, here, or here.
Is there a way to tell Windows not to enable the special path for a given application / fullscreen window? Either in the manifest, or via DWM APIs, I don't care.
Yes, this can be done by tricking Windows into thinking that the Window should be composited with transparency. For this you call DwmEnableBlurBehindWindow on the window. In case of a fullscreen WS_POPUP window this makes the window fully transparent (instead of the glass effect) and you can use the window's alpha channel to control the opacity; for a regular window with a title area and border you get the glassy effect then.
Now if you configure the pixelformat without an alpha channel or set the alpha channel to all 1 (full opacity) the compositor still has to assume some transparency may be present and goes through full composition.
Small update
Although WinXP and Win2k are beyond their EOL, it may be undesireable to hardlink the dwmapi.dll to the executable, e.g. if you have to support legacy systems with your software for some reason. For that I wrote a small wrapper library dwm_load that dynamically loads the dwmapi.dll if available or falls back to failsafe implementation of the DWM functions.
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.
As we know, several modern applications (IE9, Firefox 4, Chrome, Paint.NET, etc.) use DwmExtendFrameIntoClientArea for the Aero glass effect.
What type of applications should you really use this for, though? For browsers I can understand minimizing as much extraneous space as possible, but really, what's the point? Why not just create the window without a frame (like Google Chrome does when DWM is not present)? I'm just looking for some rough guidelines on what type of applications should use this effect and when.
Well, as this is purely a visual eye-candy type of thing, you're asking more for subjective opinion than anything else. First, check out the Windows User Experience Interaction Guidelines, though.
Personally, I like Outlook 2010, where the tab labels are on a glass background - I like the background image on my desktop (or windows behind) seeping through. I think it gives the impression that the window is not taking up quite so much of my workspace. I also love Chrome and it's use of glass for tab space.
I don't like windows media player where the controls are on glass - it makes them seem busy on a busy background. I also don't like the Add Gadget window, where the whole thing is glass (although more blurry) for the same reason.
So pick your design ideals and keep it consistent. My personal pick is to allow glass to come in on windows aspects that are mostly text and uniform, and not the main focus of interaction. On things that are "busy" and are high interaction areas, I dislike having glass behind.
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.