Weird behaviour of Textbox on change event

Moderator: Rathinagiri

User avatar
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

Post by Rathinagiri »

Hmm. AutoTrim. :)

So great Roberto. It is that simple a solution.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
User avatar
Alex Gustow
Posts: 290
Joined: Thu Dec 04, 2008 1:05 pm
Location: Yekaterinburg, Russia
Contact:

Re: Weird behaviour of Textbox on change event

Post by Alex Gustow »

Yes, Roberto, "AutoTrim" solved a problem (I think) and gives more freedom to programmer.
User avatar
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

Post by esgici »

Roberto 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 :)
Hi Roberto

Personally I like ALL of your ideas :D

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 :D
PeteWG
Posts: 176
Joined: Sun Mar 21, 2010 5:45 pm

Re: Weird behaviour of Textbox on change event

Post by PeteWG »

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

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
See also attached demo.prg

best regards,


---
Pete
Attachments
SMARTEND.7z
(1.58 KiB) Downloaded 301 times
User avatar
Roberto Lopez
HMG Founder
Posts: 4004
Joined: Wed Jul 30, 2008 6:43 pm

Re: Weird behaviour of Textbox on change event

Post by Roberto Lopez »

PeteWG wrote:
Now, the idea of an 'AUTOTRIM' property is just excellent!
Thanks. I guess that I'll finally do it.
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.
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.

Anyway, being optional, it could be implemented...
Regards/Saludos,

Roberto


(Veritas Filia Temporis)
User avatar
Roberto Lopez
HMG Founder
Posts: 4004
Joined: Wed Jul 30, 2008 6:43 pm

Re: Weird behaviour of Textbox on change event

Post by Roberto Lopez »

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 ?
All my answers were merely 'theoretical' without had tested with real code, so, my answer is 'I hope yes' :)
Regards/Saludos,

Roberto


(Veritas Filia Temporis)
User avatar
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

Post by esgici »

Roberto Lopez wrote:... my answer is 'I hope yes' :)
Thanks :)

--

Esgici
Viva INTERNATIONAL HMG :D
Post Reply