Al,

Are you talking about design time? Everything looks fine at design time. My problem is at run time.

It doesn't matter what colors I set for BackColor, ForeColor, DisabledBackColor or DisabledForeColor at design time, it picks it's own background color at run time. I suspect it gets it from the container, hence the fix. I don't particularly want to mess with juggling global themes. I just want to set the color for this one edit box the way I want it to be.

...Jim

>Maybe this is too obvious, but have you looked at the .DisabledBackColor and .DisabledForeColor of the editbox?
>
>I just did a quick test with a new form in VFP9 SP2 7423:
>
>- created a new blank form
>- added an editbox. Initially, its background color was white (255,255,255), controlled by the .BackColor property
>- set its .ReadOnly property to .T.. This caused its background color to change to the .DisabledBackColor value of 236,233,216 (default on my system)
>- then manually set .DisabledBackColor to 255,255,255. The editbox's background color changed back to white, as expected.
>
>The results of my testing:
>

>.ReadOnly / .Enabled      Foreground Color      Background Color
>--------------------      ----------------      ----------------
>
>.F. / .T.                 .ForeColor            .BackColor
>
>.T. / .T.                 .ForeColor            .DisabledBackColor
>
>.F. / .F.                 .DisabledForeColor    .DisabledBackColor
>
>.T. / .F.                 .DisabledForeColor    .DisabledBackColor 
>

You may also need to experiment with _Screen.Themes or SYS( 2700 ).
>
>If you're using a VFP framework, it may have its own ideas about how to handle foreground/background colours of ReadOnly/Disabled controls. The old VFE 5.0/5.5 framework did this, it was tricky to override.