FiveTech Software tech support forums

In the past, when a GET was marked READONLY, a change had been made that allowed the following:
TGet():nClrGrayText := 25

This allowed us to use a different color than grey which could be more readable, and yet differentiated from editable text.

Apparently this capability has been removed since it no longer functions as it once did. Can this be corrected ?

Tim,

We are reviewing it

many thanks for your feedback

Tim

You can control the color of your Get\Say yourself .. consider this code :

Code: Select all  Expand view

oFontB  := TFont():New("Ms Sans Serif",,-6,.F.,.T. ,,,,.F. )


REDEFINE SAY oSay16 var cSay16 ID 147 of oEmpl UPDATE  
   oSay16:SetFont( oFontB )
   oSay16:SetColor(nRgb(7,7,224)) // blue


// disabled
REDEFINE GET oUserid     var cUserid     ID 126 of oEmpl COLOR CLR_BLACK, 15987697 READONLY

 

Rick Lipkin

Rick,

Of course we can, but a few versions back, Nages made a modification so we could actually set a get value in one spot to be applied universally. That change disappeared.

Here is why it was important. Some of my clients ( many actually ) complained that the grey used for READONLY fields was too hard to read in well lit settings. That setting is normally drawn from the Windows color scheme, and uses the system setting for COLOR_GRAYTEXT.

Now, the get is changed to a default color of 17 in the current (17.12) version source code.

Rather than go and add code to every GET that uses a READONLY value, that capability was a real benefit. I'm not sure why it went away.

Tim

Tim

Put this at the top of your program .. I use it in all my applications .. see if it helps.

Rick Lipkin

Code: Select all  Expand view

//fix for readonly gets
TGet():lDisColors := .f.
 

The CLASSDATA nClrGrayText was first provided in FWH1512. Extract from whatsnew.txt:

* Enhancement: Class TGet COLOR_GRAYTEXT constant use changed into a CLASSDATA
::nClrGrayText as per Tim Stone requirement

We verified once again and did not find any change in the behavior since FWH1512 till now.

You assigned a value of 25 to TGet():nClrGrayText. GetSysColor(25) returns 0, i.e., CLR_BLACK which is the same as text color of normal Get. So, both disabled and normal Gets are displayed with the same colors, i.e., COLOR_BLACK/COLOR_WHITE. That must be the reason you did not notice the difference in the colors of disabled and normal Gets.

We can see the difference by assigning a different color, such as 16 (COLOR_BUTTONSHADOW).
Test program:

Code: Select all  Expand view

#include "fivewin.ch"

function Main()

   local oDlg, oFont, aGet[ 4 ]
   local aVar  := { "One       ", "Two       ", "Three     ", "Four      " }

   SetGetColorFocus()
   TGet():nClrGrayText  := 16 // COLOR_BTNSHADOW

   DEFINE FONT oFont NAME "TAHOMA" SIZE 0,-14

   DEFINE DIALOG oDlg SIZE 300,200 PIXEL TRUEPIXEL FONT oFont

   @  20,50 GET aGet[ 1 ] VAR aVar[ 1 ] SIZE 200,26 PIXEL OF oDlg
   @  55,50 GET aGet[ 2 ] VAR aVar[ 2 ] SIZE 200,26 PIXEL OF oDlg READONLY
   @  90,50 GET aGet[ 3 ] VAR aVar[ 3 ] SIZE 200,26 PIXEL OF oDlg WHEN .F.
   @ 125,50 GET aGet[ 4 ] VAR aVar[ 4 ] SIZE 200,26 PIXEL OF oDlg

   ACTIVATE DIALOG oDlg CENTERED
   RELEASE FONT oFont

return nil
 

The behaviour is exactly the same with every version of FWH from 1512 till now.

I discovered late yesterday that it does still work. However, I was trying to use the old color equivalents from the Clipper / xHarbour values. Thus the colors I originally entered were all showing up black. For example, 1 was blue, but it shows as black.

After realizing that the include is wcolors.ch I scanned those values and was able to find a value that actually would display in a workable color. When 10 fields are displayed, but 8 are readonly, having all of them in black doesn't work well when a client needs to know which field they can edit.

I have it under control now. Originally having it at black on other screens was fine ( and easier to read than grey ), but now that I needed two separate colors, my values were just not registering changes. All is OK now.

Tim