1. RE: Win32Lib: Common Controls revisited
- Posted by Brian Broker <bkb at cnw.com> Aug 19, 2004
- 440 views
Derek wrote: > > I don't know if there are any other potentially unnecessary handlers in > > there but this is at least a start. > > Well, 'unnecessary' might be a bit harsh. I need to act upon these > Windows > messages for apps that explictly set the background color of a control > to something specific - thus overriding any active manifest. > > -- > Derek Parnell > Melbourne, Australia Well, that's why I said "potentially unnecessary", because I really don't know. All I know is what my simple little programs look like when attempting to use themes. I really appreciate your efforts in trying to resolve these issues. Thanks, -- Brian
2. RE: Win32Lib: Common Controls revisited
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Aug 24, 2004
- 429 views
Derek Parnell wrote: > Brian Broker wrote: > > > > If it doesn't break anything else, can we get this fix? I'd really like > > to have my programs look right with version 6 common controls. > > The problem is triggered by the use of XP manifests. The way the Win32lib > works is that it sets the background color to the values built-in to the > library, whenever Windows asks for the user-defined background color. That > is to say, Win32lib gives all controls a user-defined color. By default > this is the colors set by the user in the current Display Appearance Scheme. > > But this only works when there is no manifest in place, or the manifest > is using the 'classic' scheme. If an alterate manifest is active, Win32lib's > operation is always replacing whatever the manifest does with the built-in > colors (though not in ways you'd expect). > > To 'fix' this, I have to change the internal usage of a number of color > attributes so that the library only sets the background color for those > controls that have explicitly been asked by the user app to use a specific > color. This might also affect text colors too. So more research will > need to be done. > > The upshot is that it will take me a few days to get it right! I guess this is where you've changed the classBGColor values from COLOR_WINDOW to w32NoColor? This causes a problem under Win2KPro with treeviews. The tree lines now are dark grey, while the rest of the control is white. Perhaps the old behavior should be maintained, and a new routine like useThemes() could be implemented to change the appropriate backgrounds. I suppose you could autodetect this for XP. Matt Lewis
3. RE: Win32Lib: Common Controls revisited
- Posted by CoJaBo <cojabo at suscom.net> Aug 24, 2004
- 430 views
Matt Lewis wrote: > > Derek Parnell wrote: > > Brian Broker wrote: > > > > > > If it doesn't break anything else, can we get this fix? I'd really like > > > to have my programs look right with version 6 common controls. > > > > The problem is triggered by the use of XP manifests. The way the Win32lib > > works is that it sets the background color to the values built-in to the > > library, whenever Windows asks for the user-defined background color. That > > is to say, Win32lib gives all controls a user-defined color. By default > > this is the colors set by the user in the current Display Appearance Scheme. > > > > But this only works when there is no manifest in place, or the manifest > > is using the 'classic' scheme. If an alterate manifest is active, Win32lib's > > operation is always replacing whatever the manifest does with the built-in > > colors (though not in ways you'd expect). > > > > To 'fix' this, I have to change the internal usage of a number of color > > attributes so that the library only sets the background color for those > > controls that have explicitly been asked by the user app to use a specific > > color. This might also affect text colors too. So more research will > > need to be done. > > > > The upshot is that it will take me a few days to get it right! > > I guess this is where you've changed the classBGColor values from > COLOR_WINDOW to w32NoColor? This causes a problem under Win2KPro with > treeviews. The tree lines now are dark grey, while the rest of the control > is white. This happens on XP PRO too. > > Perhaps the old behavior should be maintained, and a new routine like > useThemes() could be implemented to change the appropriate backgrounds. > I suppose you could autodetect this for XP. > > Matt Lewis >