editbox backcolor and fontcolor

[Roberto Lopez]

I do sometimes think about it.

HMG and HMG Ext. are somewhat different products now by varying compilers, approaches to system handles etc, though the basic is the same. Both of them have their own plus and minus. Now that they are different, as Roberto suggests, it would be better if we contribute to enhance/optimize HMG code here, instead of comparing these two products.

I am sure, Grigory will take this in right perspective and spirit.

Thanks for your support.

[Roberto Lopez]

Hello everyone,
first of all I hope I have not created problems writing (bad English) a few posts.
In particular, in the latter, with the word "suspicion" meant that HmgEx probably had
<...>

Luigi:

I've selected this post to point the Grigory's attitude, but I could use many others.

So, my words are not related specifically with your comments at all.

Regarding the 'problem' itself this is not really a bug.

This is a behavior inherited from the Windows API.

Windows API designers decided that read-only/disabled controls must have the same look in all the applications, this is the reason because those controls do not respond to standard color treatment.

This has a 'logic': An user could recognize a control that is read-only or disabled in any application, simply by its appareance. IMHO that is a good thing.

So, we should not call this a 'bug'.

IMHO, THE BUG (or BAD DESIGN DECISION) IS that a control show the same colors for normal and read-only states using the BACKCOLOR and FORECOLOR properties data.

The RIGHT SOLUTION FOR THIS IS TO HAVE SEPARATE PROPERTIES to handle colors in normal and read-only/disabled states.

I'm considering to add 'disabledbackcolor' and 'disabledforecolor' properties for upcoming releases of HMG. This is in my TODO list.

[l3whmg]

Hi Roberto,
I'm understand your words, but I preferred to clear my opinion about some words
I'm very to know about 'disable...' option.
Best regards

[gfilatov]

Hi Roberto,

Sorry, sorry, sorry... if it seems as promotion for other product on HMG forum

It's my fault

BTW There is the following description in the HMG Ext. changelog:

...
* Enhanced: ReadOnly state of EDIT controls family (TEXT & EDIT) preserve userdefined FontColor and BackColor
properties now. We can also define these properties as array of RGB arrays {aEnabled,aReadonly}
Contributed by Jacek Kubica <kubica@wssk.wroc.pl>
(see demo in folder \samples\basic\ReadOnlyEdit)

If user was defined the colors for readonly state when it will be used for drawing this control at the WM_CTLCOLOREDIT and WM_CTLCOLORSTATIC events.

Example of usage:

Code: Select all

/*
 * MINIGUI - Harbour Win32 GUI library
 * Copyright 2002-05 Roberto Lopez <harbourminigui@gmail.com>
 * http://harbourminigui.googlepages.com/
 *
 * Readonly Text/Edit controls colors - DEMO
 * (C) 2005 Jacek Kubica <kubica@wssk.wroc.pl>
 * HMG Experimental 1.1 Build 12a
*/

#include "minigui.ch"

Function Main()

   DEFINE WINDOW Form_1 ;
      AT 0,0 WIDTH 610 HEIGHT 320 + IF(IsXPThemeActive(), 8, 0) ;
      MAIN TITLE "Readonly Text/Edit controls - Colors DEMO - J.Kubica <kubica@wssk.wroc.pl>"

      // No back and fontcolor set - READONLY standard behavior

      @ 21,38 LABEL Label_1 VALUE "FontColor: <not set>" WIDTH 163 HEIGHT 16
      @ 42,38 LABEL Label_2 VALUE "BackColor: <not set>" WIDTH 160 HEIGHT 17

      @ 67,35  TEXTBOX TextBox_1 WIDTH 163 HEIGHT 23 VALUE  "TextBox_1 "
      @ 97,35  EDITBOX EditBox_1 WIDTH 164 HEIGHT 146 VALUE "EditBox_1 "

      @ 247,34 CHECKBOX CheckBox_1 CAPTION "Readonly" WIDTH 100 HEIGHT 28;
               ON Change {|| IIf(This.Value,(Form_1.TextBox_1.Readonly:=.t.,Form_1.EditBox_1.Readonly:=.t.),(Form_1.TextBox_1.Readonly:=.f.,Form_1.EditBox_1.Readonly:=.f.))}

      // Back and fontcolor set

      @ 21,38 +180 LABEL Label_1a VALUE "FontColor: White" WIDTH 163 HEIGHT 16
      @ 42,38 +180 LABEL Label_2a VALUE "BackColor: Red" WIDTH 160 HEIGHT 17

      @ 67,35+180  TEXTBOX TextBox_1a WIDTH 163 HEIGHT 23 VALUE  "TextBox_1a " FontColor  {255,255,255}  BackColor {200,0,0}
      @ 97,35+180  EDITBOX EditBox_1a WIDTH 164 HEIGHT 146 VALUE "EditBox_1a " FontColor  {255,255,255}  BackColor {200,0,0}

      @ 247,34+180 CHECKBOX CheckBox_1a CAPTION "Readonly" WIDTH 100 HEIGHT 28;
               ON Change {|| IIf(This.Value,(Form_1.TextBox_1a.Readonly:=.t.,Form_1.EditBox_1a.Readonly:=.t.),(Form_1.TextBox_1a.Readonly:=.f.,Form_1.EditBox_1a.Readonly:=.f.))}

      // Back and fontcolor set as arrays {aEnable,aReadonly}

      @ 21,38 +180+180 LABEL Label_1b VALUE "FontColor: {White,Yellow}" WIDTH 163 HEIGHT 16
      @ 42,38 +180+180 LABEL Label_2b VALUE "BackColor: (Blue  ,DarkBlue}" WIDTH 160 HEIGHT 17

      @ 67,35+180+180  TEXTBOX TextBox_1b WIDTH 163 HEIGHT 23 VALUE  "TextBox_1b " FontColor  {{255,255,255},{255,255,0}}  BackColor {{0,0,200},{0,0,100}}
      @ 97,35+180+180  EDITBOX EditBox_1b WIDTH 164 HEIGHT 146 VALUE "EditBox_1b " FontColor  {{255,255,255},{255,255,0}}  BackColor {{0,0,200},{0,0,100}}

      @ 247,34+180+180 CHECKBOX CheckBox_1b CAPTION "Readonly" WIDTH 100 HEIGHT 28;
               ON Change {|| IIf(This.Value,(Form_1.TextBox_1b.Readonly:=.t.,Form_1.EditBox_1b.Readonly:=.t.),(Form_1.TextBox_1b.Readonly:=.f.,Form_1.EditBox_1b.Readonly:=.f.))}

	DEFINE MAIN MENU

		POPUP "Set BackColor"
			ITEM "Set backcolor of TEXT_1 to WHITE" ACTION Form_1.TextBox_1.Backcolor:={255,255,255}
			ITEM "Set backcolor of TEXT_1a to BLACK" ACTION Form_1.TextBox_1a.Backcolor:={0,0,0}
			ITEM "Set backcolor of TEXT_1b to RED" ACTION Form_1.TextBox_1b.Backcolor:={255,0,0}
			SEPARATOR
			ITEM "Set backcolor of TEXT_1 to WHITE/RED" ACTION Form_1.TextBox_1.Backcolor:={{255,255,255},{255,0,0}}
			ITEM "Set backcolor of TEXT_1a to BLACK/RED" ACTION Form_1.TextBox_1a.Backcolor:={{0,0,0},{255,0,0}}
			ITEM "Set backcolor of TEXT_1b to RED/BLUE" ACTION Form_1.TextBox_1b.Backcolor:={{255,0,0},{0,0,200}}
			SEPARATOR
			ITEM "Set backcolor of TEXT_1 to  <not set>" ACTION Form_1.TextBox_1.Backcolor:=""
			ITEM "Set backcolor of TEXT_1a to <not set>" ACTION Form_1.TextBox_1a.Backcolor:=""
			ITEM "Set backcolor of TEXT_1b to <not set>" ACTION Form_1.TextBox_1b.Backcolor:=""
		END POPUP

		POPUP "Set FontColor"
			ITEM "Set FontColor of TEXT_1 to WHITE" ACTION Form_1.TextBox_1.FontColor:={255,255,255}
			ITEM "Set FontColor of TEXT_1a to BLACK" ACTION Form_1.TextBox_1a.FontColor:={0,0,0}
			ITEM "Set FontColor of TEXT_1b to RED" ACTION Form_1.TextBox_1b.FontColor:={255,0,0}
			SEPARATOR
			ITEM "Set FontColor of TEXT_1 to WHITE/RED" ACTION Form_1.TextBox_1.FontColor:={{255,255,255},{255,0,0}}
			ITEM "Set FontColor of TEXT_1a to BLACK/RED" ACTION Form_1.TextBox_1a.FontColor:={{0,0,0},{255,0,0}}
			ITEM "Set FontColor of TEXT_1b to RED/BLUE" ACTION Form_1.TextBox_1b.FontColor:={{255,0,0},{0,0,200}}
			SEPARATOR
			ITEM "Set FontColor of TEXT_1 to  <not set>" ACTION Form_1.TextBox_1.FontColor:=""
			ITEM "Set FontColor of TEXT_1a to <not set>" ACTION Form_1.TextBox_1a.FontColor:=""
			ITEM "Set FontColor of TEXT_1b to <not set>" ACTION Form_1.TextBox_1b.FontColor:=""
		END POPUP

		POPUP "Get ReadOnly Status"
			ITEM "Get ReadOnly Status of TEXT_1" ACTION msginfo("Readonly is " + if(Form_1.TextBox_1.Readonly == .t.,"TRUE","FALSE"),"TEXT_1")
			ITEM "Get ReadOnly Status of TEXT_1a" ACTION msginfo("Readonly is " + if(Form_1.TextBox_1a.Readonly == .t.,"TRUE","FALSE"),"TEXT_1a")
			ITEM "Get ReadOnly Status of TEXT_1b" ACTION msginfo("Readonly is " + if(Form_1.TextBox_1b.Readonly == .t.,"TRUE","FALSE"),"TEXT_1b")
		END POPUP

	END MENU

   END WINDOW

   Form_1.Center
   Form_1.Activate

Return Nil

Thanks for your attention

[Roberto Lopez]

Hi Roberto,

Sorry, sorry, sorry... if it seems as promotion for other product on HMG forum

It's my fault
<...>

From MSDN:

"An edit control that is not read-only or disabled sends the WM_CTLCOLOREDIT message to its parent window when the control is about to be drawn. By responding to this message, the parent window can use the specified device context handle to set the text and background colors of the edit control..."

In other words, read-only or disabled edit controls do not send the WM_CTLCOLOREDIT message, instead, they send the WM_CTLCOLORSTATIC message.

As I've said, IMHO the adequate way to implement this functionality is to add two new properties (DisabledBackColor and DisabledForeColor) to handle it as in (ie) VFP.

This must be done processing WM_CTLCOLORSTATIC, asking if the message sender is a read-only/disabled EDIT. In such case responding with values stored in THESE NEW PROPERTIES.

The reason is simple:

Please, consider the case of an user wanting custom colors for the normal state and 'system' ones for disabled/read-only state.

Having only one backcolor/forecolor set and FORCING the same color pair for BOTH STATES, the user will be unable to handle such situation.

Good chess players thinks various moves ahead prior to make a decision.

IMHO, when you are implementing a new feature, you must act as a good chess player, thinking on all possible future scenarios after your move.

This is the difference between implement a new feature or make a 'fix' to get something quickly.

Of, course, this is just my opinion and I could be wrong

[Roberto Lopez]

<...>
Having only one backcolor/forecolor set and FORCING the same color pair for BOTH STATES, the user will be unable to handle such situation.
<...>

The screenshot you've posted for the Luigi's sample, shows an EditBox using the backcolor/forecolor pair to set read-only state colors. Such behavior is (IMHO) not correct.

[Roberto Lopez]

Hi guys,
I've found a problem using BACKCOLOR and FONTCOLOR in an EDITBOX control when it's READONLY.
<...>

Temporarily, until proper code be implemented you could control the EditBox read-only colors simply adding the following:

Code: Select all

.Or. _HMG_SYSDATA [1] [i] == "EDIT"

to the end of line 379 of 'h_windows.prg' and recompiling the library.

I hope that this be useful for you.

[Roberto Lopez]

Hi Roberto,

Sorry, sorry, sorry... if it seems as promotion for other product on HMG forum

It's my fault

BTW There is the following description in the HMG
Ext. changelog:
<...>

Dear Grigory (Again:)):

You are insisting in your position with this response, simply showcasing HMG Ext. again.

...

I've retired from forums five years ago, because I've was not interested on power struggles.

So, across the following years I've continued publishing new HMG releases without no public activity.

In 2008, Rathinagiri invited me to this new forum, to give help and support to people that have chosen HMG instead other alternatives and I've started again from the ground.

We created a nice family here. A big group of good people helping each other.

I'm sure that nobody here (including me) is interested in any kind of 'competition' with some other development tool (including HMG Ext.).

So, I ask you again to stop your HMG Ext. advertising/comparison campaign here.

As I've said, I'm not interested on waste my limited time and energy on this, so, you can consider this post as my final one on this thread.


Please, let us to work in peace.


PS: Feel free to not answer this message.

[l3whmg]

Hi Roberto
many, many thanks for your suggestion , but...
for me it's not urgent because I'm not a professional developer on Xbase: I'm a selfmade on HMG world (when I had a job I must use RPG, COBOL, little VB).
Second, I'm not sure to be able to (re)compile HMG: for me would be the first time : I'll try to do

Any way...many, many thanks.
Best regards.

PS: If I can afford to say: do not get mad.

[gfilatov]

Hi Roberto,

I assure that will not be a problem from my side.

Thanks for your time!