1. RE: Win32Lib: Common Controls revisited

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

new topic     » topic index » view message » categorize

2. RE: Win32Lib: Common Controls revisited

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

new topic     » goto parent     » topic index » view message » categorize

3. RE: Win32Lib: Common Controls revisited

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
>

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu