Hmm. AutoTrim.
So great Roberto. It is that simple a solution.
Weird behaviour of Textbox on change event
Moderator: Rathinagiri
- Rathinagiri
- Posts: 5471
- Joined: Tue Jul 29, 2008 6:30 pm
- DBs Used: MariaDB, SQLite, SQLCipher and MySQL
- Location: Sivakasi, India
- Contact:
Re: Weird behaviour of Textbox on change event
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
South or North HMG is worth.
...the possibilities are endless.
- Alex Gustow
- Posts: 290
- Joined: Thu Dec 04, 2008 1:05 pm
- Location: Yekaterinburg, Russia
- Contact:
Re: Weird behaviour of Textbox on change event
Yes, Roberto, "AutoTrim" solved a problem (I think) and gives more freedom to programmer.
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: Weird behaviour of Textbox on change event
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
Personally I like ALL of your ideas
Beside that for me too, "Auto Trim" is the best solution.
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 ?
Even though "no", your solution is the best by point of backward compatibility
Best Regards
--
Esgici
Viva INTERNATIONAL HMG
Re: Weird behaviour of Textbox on change event
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.
Now, the idea of an 'AUTOTRIM' property is just excellent!
However the need of an "extended" END key is still here and it would be very useful to be implemented in parallel to Autotrim.
(I think that it is the 'extended features' like this that increase the smartness of any given software tool, making it to stands out among others similar products -and everybody here thinks that MiniGUI deserves this title of "outstanding tool")
_________________________________________________________
[*] Extended END key
"The End key moves the cursor to a point immediately after the last non-whitespace character on the line. Pressing End a second time moves the cursor to the last character on the line. This has no effect when Trim Trailing Spaces is enable."
Below is a function who demonstrates how this smart END could be implement.
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
best regards,
---
Pete
- Attachments
-
- SMARTEND.7z
- (1.58 KiB) Downloaded 301 times
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: Weird behaviour of Textbox on change event
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.
Anyway, being optional, it could be implemented...
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: Weird behaviour of Textbox on change event
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 ?
Regards/Saludos,
Roberto
(Veritas Filia Temporis)
Roberto
(Veritas Filia Temporis)
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: Weird behaviour of Textbox on change event
ThanksRoberto Lopez wrote:... my answer is 'I hope yes'
--
Esgici
Viva INTERNATIONAL HMG