Hello friends
I have an application that calculates days between dates, the first two TextBox
enter the dates and the rest is only for the result and the previous calculation
historic.
The TextBox that just are to report the results and the rest is history.
-> READONLY. T. and BACKCOLOR (180,200,255) <-
When compiled with HMG can not enter data READONLY. T. but the bottom
TextBox does not change the color, if compiled with Extended or ooHG see the
background color of the TextBox.
If you could provide any solution will be very grateful.

HMG establishes read-only property for a textbox, sending the appropiate message to the control using corresponding Windows API function, so, the behavior and appearance of the control is determined by Windows.

I've not care specially about this, because I think that the user must have a consistent experience across applications. That was the goal of the Windows API creators, so, a read-only textbox should look the same in all applications.

Anyway, I'll consider the addition of this feature in future versions.

And, if someone has some sample to help Mustafa on this, please, post here.

I think, this is the same problem as mine with progressbars as graphs - when I switch desktop for using windows themes, some settings of colours are from windows - when themes are off, all of them look as I defined them.

In my opinion, It would be great to programmatically control behavior of features - indenpendend from windows.

mol wrote:I think, this is the same problem as mine with progressbars as graphs - when I switch desktop for using windows themes, some settings of colours are from windows - when themes are off, all of them look as I defined them.

In my opinion, It would be great to programmatically control behavior of features - indenpendend from windows.

The problem is basically because Windows XP/Vista/7 themes API are not fully backwards compatible with non-themed desktops. So, the same code that allowed you to change certain color when no XP theme is used, does not work when a theme is applied.

This behavior is by design.

The only way to overcome this is to create owner-drown versions of the controls.

The problem with this is that the control should be re-coded on every windows version to be in-sync with them to 'mimic' each new theme look (I've simplified the problem to explain it, but is really more complicated).

Please, do not forget that the idea of the themes, is that each control type have the same look in all applications.

Roberto Lopez wrote:
The problem is basically because Windows XP/Vista/7 themes API are not fully backwards compatible with non-themed desktops. So, the same code that allowed you to change certain color when no XP theme is used, does not work when a theme is applied.

This behavior is by design.

The only way to overcome this is to create owner-drown versions of the controls.

The problem with this is that the control should be re-coded on every windows version to be in-sync with them to 'mimic' each new theme look (I've simplified the problem to explain it, but is really more complicated).

Please, do not forget that the idea of the themes, is that each control type have the same look in all applications.

Anyway, there is a dirty trick (always there is one )

in \hmg\resources\minigui.rc, delete the line #6 (1 24 HMGRPATH\WindowsXP.Manifest) and recompile the resources...

and... VOILA!

Your application will not be themed even when XP style be active, so the colors will perform like in Win9x, so you could change progressbar color.