Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to defeat EditBox ReadOnly back color (Bad framework
Message
From
05/03/2010 14:25:35
 
 
To
05/03/2010 13:27:29
James Hansen
Canyon Country Consulting
Flagstaff, Arizona, United States
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Environment versions
Visual FoxPro:
VFP 9 SP2
Miscellaneous
Thread ID:
01452840
Message ID:
01452850
Views:
94
This message has been marked as a message which has helped to the initial question of the thread.
>Maybe I'm just obtuse, but I never could figure out how to set a chosen background color on a read-only editbox. It always goes to a strange color I can't seem to control, especially when it looses focus. So I have resorted to KeyPress and dangerously simplistic or annoyingly complex keystroke checks.
>
>The other day I stumbled on a way to control the BackColor on an EditBox with ReadOnly set to .T.
>
>I put the editbox in a container of the same size, a zero-width border and the opaque background color I desire. If I want the background to be the same whether or not the editbox has the focus, I need to have the editbox background set to Opaque for some strange reason or it gets wierd again. I set the editbox's DisabledBackColor to the same color as the container just so I can preview and remember the colors when I'm editing, although it doesn't seem to matter at run time. I also set the anchors for the editbox to be anchored all four ways inside the containr so resizing the form works as expected.
>
>The only downsides I've found so far are that I have an extra level of addressing to access the editbox, I have to remember the container when I'm editing the form, and resizing the editbox in the editor is awkward, but I can live with those. (Resizing in the editor is not hard: I just resize the container and then manually set the same height and width for the editbox.)
>
>Like I said, maybe I'm obtuse and have overlooked something obvious to someone else, but in case I haven't, there it is.

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.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform