Re: Weird behaviour of Textbox on change event
Posted: Wed Apr 14, 2010 5:08 pm
Hmm. AutoTrim.
So great Roberto. It is that simple a solution.
So great Roberto. It is that simple a solution.
Exclusive forum for HMG, a Free / Open Source xBase WIN32/64 Bits / GUI Development System
http://hmgforum.com/
Hi RobertoRoberto Lopez wrote: ...
Perhaps, I could add the following:
"To make the things easier for the user, I could add a new property for TextBox called 'AutoTrim' (defaulted to true) that could make the job automatically if the user wants such behavior".
I really like the last idea
I agree, the "End key" problem as described above is an absolutely valid argument, and perhaps justify the trailing spaces auto-triming . This problem is an annoyance that comes from the raw and I'd say "non-intuitive" operation of End key in ms-win platform. The same "raw and non-intuitive" behavior has the Home key too. (I have no idea how other OSes utilize these keys) but I'm sure that this is the reason that many advanced text editors (PsPAD for example) have invented the so called SMART or EXTENDED[*] HOME/END keys. It's because the real life has showed that when a user press the END key, he/she most probably want to move cursor exactly at the end of the existent (non emty) text, and NOT at the end of the edited control buffer. Going beyond all over empty spaces, that might contain an editable text line, does not make any sense, and is very rare the case a user to want to move cursor there.Roberto Lopez wrote: The most complex situation comes when you attempt to edit and (ie) pressing the [End] key (going to many spaces to right of the true current data end).
Even worst situation arises if you set the MaxLength property to meet field length. In that case the field could be impossible to edit without deleting characters (trailing spaces) first.
Code: Select all
*********************
PROCEDURE _SmartEnd( lSet )
*********************
LOCAL cWindowName
LOCAL cControlName
LOCAL cControlType
LOCAL nLen
DEFAULT lSet TO .T.
cWindowName := ThisWindow.Name
cControlName := ThisWindow.FocusedControl
IF ( cControlType := GetControlType( cControlName, cWindowName ) ) $ ;
"TEXT,EDIT,RICHEDIT,MASKEDTEXT,CHARMASKTEXT"
IF lSet
nLen := Len( RTRIM( GetProperty( cWindowName, cControlName, "Value" ) ) )
ELSE
nLen := Len( GetProperty( cWindowName, cControlName, "Value" ) )
ENDIF
Setproperty( cWindowName, cControlName, "CaretPos", nLen )
ELSE
/*
Probably here we should:
a. SET SMART END OFF (that is, _ReleaseHotKey() END)
b. fetch an END to edited buffer and let system do whatever it is normaly doing with END
c. SET SMART END ON again.
But... it seems to me a bit complicated to do it here & now ;-)
*/
ENDIF
RETURN
Thanks. I guess that I'll finally do it.PeteWG wrote:
Now, the idea of an 'AUTOTRIM' property is just excellent!
This is really a very interesting idea, but, the problem with it, is that the user (our final app. user) must to know how to use it and since this is not a standard Windows behavior he must be trained/informed about this feature.PeteWG wrote:
However the need of an "extended" END key is still here and it would be very useful to be implemented in parallel to Autotrim.
All my answers were merely 'theoretical' without had tested with real code, so, my answer is 'I hope yes'esgici wrote: Only one point disturbing me: sorry for my ignorance, after "Auto Trim", does ON CHANGE event will work as expected for Auto Trimmed text box ?
ThanksRoberto Lopez wrote:... my answer is 'I hope yes'