I'm trying to handle background color properly in a dynamically generated property sheet in dynamically generated property pages in win32 api using MFC (though I expect my question is general, and not restricted to MFC, but since my code and examples use it, it's germane to my question anyway).
So we have a:
CPropertySheet
containing multiple
CPropertyPage
I generate the contents of any given page dynamically - from file resources using a custom dialog definition language - all irrelevant other than to say - a list of controls and their coordinates is created within a given page, and the page is resized to accommodate them. This logic is working beautifully.
However, what doesn't work is that the controls and background of each page draws using the dialog default color/brush.
I've tried a number of ways to attempt to force it to draw using the white color/brush that a hard-coded property sheet / page would.
There are two important pieces to this:
Page Background
Control (on the page) background
For #1, I've tried:
acquire the background brush from parent window class (it's dialog bkgrd) (same is true if I do this and ask the tab control)
change the property page to use WS_EX_TRANSPARENT (PreCreateWindow is not called by the framework when generating a page viz PropertySheet::AddPage)
For #2, I've tried:
overriding OnWndMsg / WM_CTLCOLORSTATIC to forward that request to (A) the parent (sheet), and (B) to the tab control (which is what wants the white in the first place).
However, anytime I use any of the above "ask for the background / forward the request" up the chain to either the sheet or the tab control - I get the dialog background color, never the white I'd expect.
Using Spy64, I can see that for a fully hardcoded property sheet / page - that the only discernable differences I can see is that the dialog window created in AddPage (or its moral equivalent) has WS_CHILD instead of mine which has WS_POPUP (the rest of the styles appear to be the same, such as WS_VISIBLE|DS_3DLOOK|DS_FIXEDSYS|DS_SETFONT|DS_CONTROL and WS_EX_CONTROLPARENT.
So, other than the WS_CHILD, I see no significant differences from what I'm creating and from another property sheet that works properly from a standard resource (i.e. hard coded).
I'm also flummoxed as to how this works normally anyway - since forwarding things like the ctrlcolor message doesn't respond correctly - and asking for the windows background colors similar doesn't - then how is it in a standard case the background colors of controls and pages comes out as white, and not dialog background?
Any ideas or help would be appreciated - I'm kind of running out of ideas...
When Visual Styles were added in Windows XP they really wanted to show off this new feature so they made the tab background a gradient (really a stretched image) instead of a single color and this caused problems in old applications that did custom drawing with the dialog brush as the background.
Because of this, only applications with a comctl32 v6 manifest got the new look but there was a problem; old propertysheet shell extensions would load in new applications (including Explorer) and things would look wrong.
To work around this they also require you (or your UI framework) to call EnableThemeDialogTexture(.., ETDT_ENABLETAB) to get the correct tab page look.
As if things are not tricky enough, there is a undocumented requirement that you also need a button or a static control on the page!
If you have custom controls they have to call DrawThemeParentBackground when you draw if they are partially transparent.
Turns out my old code had defined an ON_WM_ERASEBKGND handler - and removing that (and all of my above attempts) makes it work.
So simply doing NOTHING is the correct answer. D'oh!!!
I'm leaving my shame here in case someone else trips on this! [Whoops!]
(Still interested if anyone has deeper insight into how this mechanism works under the hood)
Related
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.
Say, I have an Image control (which seems to be a window-less control) and I want to make sure that it is on top of a TextBox. No matter what I do, the Image control will not appear on top of the Text box.
Is there a way?
P.S. I know I can use a PictureBox, but it does not support transparency, thus I must have the Image control.
There is no way to place an image control over a normal textbox as they are drawn onto the form itself so will always be below any other windowed components.
If you have VB6 installation media there are drawn (windowless) versions of controls including a TextBox you can use that will (probably) do what you want; http://support.microsoft.com/kb/184687
A custom usercontrol of some kind if probably better .. what is it exactly you want to overlay the textbox with?
The Image Control is considered a graphical control, like shapes, so it is always inferior to text controls. If you really want a transparent image, you can use a Microsoft 2.0 Form instead(only if you have it). Images there can be on top of textboxes, and you can make it transparent by setting the Backstyle to Transparent(0).
Completely different approach to my other answer (hence the seperate Answer), but you can set AutRedraw and ClipControls on your Form to false and it will allow the Image control to render on the same layer as a windowed control. You can get some flakey redrawing in some cases but for a quick solution you could try it.
http://msdn.microsoft.com/en-us/library/aa733621(v=vs.60)
I've created a tranparent overlay control to add a kind of annotation layer on top of a VB6 app. I'll attempt to describe it from memory, and if that doesn't provide enough information then you can post back and I'll try to dig up the code.
First, add a new USerControl to you application. Give it a name like ImageEx, PictureEx, or TransparntImage. There are several properties that you will need to use. Ensure the control is Windowed, so it can sit on top of other windowed controls. Locate the MaskColor property and set it to Cyan (or whatever color you elect to use to indicate a tranparent area. There might be an addition property enable the masking behavior, just browse the properties. Set the control background color to that of the MaskColor. At this point you have an invisible control. In my control I painted on top of the surface for annotations, but you can PaintPicture or maybe even set the image property for a really simple approach.
Of course, to make this a re-usable control, you will want to code in your own properties that allow the MaskColor and image, etc to be set so that you can the drop one of these on any form you want.
Some links:
MaskColor Property
MackPicture Property
1) Remove all your textboxes , labels and ... (But memorize their name and location in the form)
2) Go to (project > components) and mark the (Microsoft Forms 2.0 Object Library) then click ok
3) Now you can see new controls under your default controls in your toolbox...
4) Use its textbox and label controls instead of the default controls
5) Right click on your Image Control then click (Bring To Front)
I need to change the Background Image of my Application if user changes theme from "Light" to "Dark" or vice-vesa in code behind. I hope these should be done in Page Loded event
#TimDams pointed you to one of the nice ways to detect what-theme-is-now-set, but I didn't notice there any information how to detect a change to the theme during the application runtime. The user could start your app, then bump forward to the menu, change the theme, and get back to your app. While you may think that your app will be tombstoned and then restarted and renavigated to your page with full cycle with all pageloads -- it is not 100% true.
Firstly, the PageLoaded is NOT a good place to do the initial check-and-set-styles, because, if you get that event called, then the page, probably, has already rendered once. If I remember well, the PageLoaded is invoked just after the first render. If this is true, then you will have to detect the colors earlier, for example in the LayoutUpdated (warning: this event is a great spammer. I mean, it gets called gazillions times. Attach a single-shot handler, you know, such that will instantly unattach-self on first invocation). Maybe you will be able to do it in the Page's .ctor, just after InitializeComponent. Or in the OnApplyTemplate or MeasureOverride, or at least ArrangeOverride -- the visuals should be mostly/fully available there.
Buuuut. I've intentionally 'bolded-out' the word "initial". With Mango, there's some multitasking getting more and more common, but even the pre-Mango 7.0 version does not guarantee that your app will be tombstoned. From my observations in early 7.0, for example, starting the MediaPlayer from WebBrowser component does not tombstone your app:) If you have some time to read, check WP7 recover from Tombstone and return to page for details on the "pause" vs "tombstone".
Anyways, if your app gets "paused" and the user switches themes in the meantime, I think (I've NOT checked) that your page will (in most of the cases) be just temporarily hidden and upon returning to the screen, it will probably not be re-created and will not be re-(Page)Loaded. If it is true, then you will have not so easy problem to solve, because your app may be paused, the OS rethemed, and your app unpased virtually in any moment of time and the only events you will get in the mean time are .... global events of App.Deactivated and App.Activated. It is possible that completely none of per-page events will fire [but I've not checked - before you do anything I suggest below, CHECK IT].
If this pessimistic view is really true, than in those events, you will have to detect the current theme (->Tim's post), then somehow inform your current Page that themes changed - or not. If you have your ViewModel at least a bit separated from the rest of the app (as it should be:) ) you have an easy option to do it: create in that ViewModel a set of properties (dp or inotif) like Brush Background, Brush Foreground, Brush Hightlight, and other that you need, and instead of harcoding colours in your XAML - bind to those properties. You may event want to create a separate class for all those many Brushes and other Styles, let's say "pub class MyCurrentAppTheme" and keep that props there, and expose such object from ViewModel - whatever. Just Bind your colors to whatever -- but whatever that will be "logically global" and that will be easily accessible from the App.Acticated event handler. Having that done, in the App.Activated, detect the current theme and if changed, so through all the colors kept in VM and set them appropriatelly. Voil'a, whole your App gets recoloured properly.
But mind that still - there might be some transient blinks and flashes between the rendering of cached old theme, refreshing databound objects, and redrawing fresh theme. I hope not, but I sense it may occur, especially when returning from fast-switch tool (long back press): I think that the device captures the 'last screenshot' of your app in the backbuffer and uses that throughout all the time the app is 'minimalized' to do transitions animations, to show the fast-app-switch overview and so on.. again, I've not checked, but I doubt that during such animations the pagecontents are 'live', it could be very demaning on CPU/GPU resources. Any one knows anything on that? It could be a nice test to have some looping animation on the page and then to switch out and check in the fast-switch overview, whether the animation moves or is halted!:)
If your application is tombstoned, all your controls will be recreated and the new theme will be applied. If you'd like to manage your light/dark specific styles in a similar vein to normal themes, you might want to take a look at a custom ResourceDictionary I blogged about a while back.
Unfortunately, as of Mango there, is a bug (?) related to fast application switching that causes the theme to remain unchanged in your application. The bug is outlined in this question and its linked posts:
Is there a bug when changing themes when app is deactivated and reactivated in Windows Phone Mango
My ResourceDictionary is still useful for the initial startup but it appears, unfortunately, that nothing can be done to workaround the Mango bug.
For this no event exists. You need to figure this out manually by comparing the PhoneBackgroundBrush color to see if the user has the dark or light theme and compare it with your last stored value.
Were you able to do some test on the App.Activate - Deactivate?
I decided to use a different path to solve the issue of dynamic theme change.
I've assigned to all text and buttons only system resource colors.
For the icons inside the buttons in the window instead of using PNG images-icons I used the in XAML and assing it a Foreground color from system resource.
For the buttons in the SystemMenuBar there is no issue as they are always on a dark gray background so the black PNG images work just fine.
Hoping this helps.
You can check if the dark theme is in use with this simple check:
public static bool CurrentThemeIsDark
{
get
{
return (Visibility)Application.Current.Resources["PhoneDarkThemeVisibility"] == Visibility.Visible;
}
}
To modify a window of another program, I need to find a specific SysTreeView32 in it using EnumChildWindows API call.
When I inspect the window using Spy++, there are a number of SysTreeView32's in it but all are greyed out except one, which is the one I'm looking for.
The following picture is an example of grey items:
Why are the shown items gray and what API call does Spy++ use to know whether it should grey out an item or not?
Those are just non-visible windows - ie HWNDs that don't have the WS_VISIBLE style bit set. They are often worker windows - windows that just exist to process various messages in the background - or in some cases are UI that's yet to become visible. For example, a window that lets you hide or show a toolbar may just hide it by making it invisible rather than destroying it and recreating it later.
In your specific case, the WorkerW could be a placeholder for some other piece of UI that's not needed right now, while the msctl_statusbar32 looks like it's a hidden status bar.
I would like to know what should I do with GUI layout under WinAPI/MFC.
In the ideal world I should just create the form/dialog via resource editor, and everything should just work. In the real world the dialog editor is ancient behemoth from the ice-age and doesn't support most of the comctl32 controls.
This is where the problem creeps up. Dialog editor uses DLU units, and when I create new controls at runtime, I have to express them in pixel offsets.
I stumbled upon one article about calculating DLUs based on font http://support.microsoft.com/kb/145994/en-us, but also saw a warning somewhere that dialogs can have non system fonts in some circumstances, so this approach is not very safe. Plus the article seems to look only at English characters, without regard to all other characters in unicode space which might be wider?.
Has anyone done a research in this direction and found a better way?
P.S.: No Winforms/WPF/Delphi, requirements.
the dialog editor is ancient behemoth from the ice-age and doesn't support most of the comctl32 controls
It doesn't need to support the controls directly, you can still use it just for positioning by inserting it as a custom control and filling in the window class in the property page. For example, that's how I insert link controls in VS2005: as a custom control with class "SysLink".
MapDialogRect (mentioned in the article) is the function that Windows uses to translate the dialog units in the dialog resource to pixel units. MapDialogRect works (where GetDlgBaseUnits fails) because its given an actual handle to the dialog box, and can send it a WM_GETFONT message to retrieve the actual font the dialog will be rendered with.