Weird behaviour of Textbox on change event

Moderator: Rathinagiri

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 »

Hi Rathi

If you will use ON CHANGE event, don't trim textbox's value :!:

That's all :)

Regards

--

Esgici
Viva INTERNATIONAL HMG :D
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 »

rathinagiri wrote:Please consider this sample
<...>
I've been very busy this week and I've absent from the forum until today.

I've downloaded the sample, I'll test it in the next week and I'll post about it here.

There is a pending bug about inputmasked textbox and onchange event, that I've undone since it bring new problems.

As I've stated on other post, inputmask needs to be reworked.

In fact I've done a fully new inputmask processing with a completely new approach from the scratch and added new functionality, but I do want to publish until new grid code be reliable enough (too much problems at the same time :) )

This new code do not work with onchange nor ongotfocus/onlostfocus events (I've subclassed textbox to trap the keys) so all of problems related with those events will vanish.
Regards/Saludos,

Roberto


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

Thanks a lot for your concern Roberto.

It is great to hear about the new inputmask. :)
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
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 »

Well...

Until now, I've believed that the only person knowing HMG almost as much as me, was Grigory, but, appears to be that Pete is another one :)

He has the right answer to this.

If you look at 'h_controlmisc.prg', line #476 (_SetValue function) you'll find the following code:

Code: Select all

 SetWindowText ( c , rtrim(value) ) 
SetWindowText is a Windows API function that allows (among other things) allows to change the content of an EDIT (TextBox) control.

The first parameter is the control handle and the second is a character string containing the new content.

_SetValue function is called when you assign a new value to a control.

As you can see, the value sent to the TextBox is 'rtrim(value)' instead simply 'value'.

There is the missing character giving the 'weird' result described by Rathinagiri.

The obvious proper answer from my part should be 'This is not a bug. This behavior is by design'.

Yes... it's a terrible answer, but is the true :)

I've considered that trailing spaces in a string to be edited are unnecessary and that removing them could make the editing process easier (I still thinking so).

But, we could talk about that here and if the impact on backwards compatibility is acceptable and we find good reasons to change it, we can do it...

I'm listening...

PS: Thanks Pete. A fantastic analysis and response!
Regards/Saludos,

Roberto


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

Thanks a lot for the explanation Roberto.

Let us not further complicate the things. :) Leave it as it is.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
User avatar
sudip
Posts: 1454
Joined: Sat Mar 07, 2009 11:52 am
Location: Kolkata, WB, India

Re: Weird behaviour of Textbox on change event

Post by sudip »

Sometimes trailing spaces create problems with SQL database. Rathi, I also used trim() in C2SQL() function with character values.
Regards.
Sudip
With best regards,
Sudip
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 »

Hi Roberto
Roberto Lopez wrote:'This behavior is by design'.
Your design is the best as always :D
Roberto Lopez wrote:I'm listening...
HMG users will TRIM their own values (variables, fields, etc) freely,

but if they will use ON CHANGE event for TEXTBOXs, don't trim textbox's value;

that's all.

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:Until now, I've believed that the only person knowing HMG almost as much as me, was Grigory, but, appears to be that Pete is another one :)
Yeah! sure.. Me too, I do have almost the same opinion about him 'Pete'.
Imagine you, one of my innermost wishes is to become, some day, a minigui-adept,
like this guy -and then of course, I will have reached yours (and Grigory's)
admirable expertise about minigui! ;-)
Roberto Lopez wrote: I'm listening...
Now seriously, about textbox's trailing spaces trimming or not.
I think trim(), is a very high level functions family,dedicated to application developers to use them as they need.
Keep in mind that trim operation affects straightly the real data, for which the only one responsible is and must be the application developer.
I can't imagine why the system/programming tool developer should or might be interested to manipulate user data. His task is to create the tools by which we'll be able to handle data on an application layer.
Trimming data "under the hood", is IMHO an arbitrary and perhaps unwanted involvement by the side of system/tool developer.
And if he takes the freedom to trim the data, why not to also capitalize them, why not to transform them into f.e. UTF16, Russian or Greek (thank you very much) codepage and so on..?

"Sometimes trailing spaces create problems with SQL database", said our friend Sudip and he's right from his *specific* SQL-POV.
But arbitrarily trimmed data misleads the system to fire an Onchanged event there where there is no real data change, and this is a rather buggy behavior.
If you want a piece of data trimmed you have the trim(). Now, what if i want my data to remain unaltered? Do i have to invent an un_trim() function to put back in their places the "unasked trimmed" spaces?

I will give you an other arbitrary, silent, hidden, and beyond every expectation, *unwanted* low level data manipulation.
The culprit here is the HB_OEMTOANSI() function. This nice and really useful function receives a string value,
transcode it to ansi character set and returns the converted value back to the caller routine. So far so good, with one exception.
If you, accidentally pass to HB_OEMTOANSI() a non string var (e.g. numeric), this good function accept it without a grumble,
throw away its value, alters its type and returns back (you guess it) a null string! Not very cute behavior in my (not so humble) opinion.
I think it'd be much more gentle, informative and useful if HB_OEMTOANSI() threw an RTE, denoting this way, the wrong passed value.
An other, perhaps satisfactory, solution could be to return the value unaltered. But this cruel (and silent!) nullification is really
indescribable. The most annoying is that this HB_OEMTOANSI() 'feature' was and still is undocumented.
I have found other functions in harbour to have similar actions, it is not the place/time to expose/discus about them now and in NO CASE my
words constitute any kind of blame against respectable harbour developers. It is a technical thoughts exchange in a good-will basis.
Conclusively, i believe that, if it is not too much breaking backward compatibility, it'd be a good idea to remove this rtrim() out of the SetWindowText function, avoiding, this way, to "touch" user data. Whatever you decide to do, it is necessary a relevant documentation notice to be made.

Just my 0.02 euros (and apologies for my long message)



best regards,

---
Pete
User avatar
Czarny_Pijar
Posts: 172
Joined: Thu Mar 18, 2010 11:31 pm
Location: 19.2341 E 50.2267 N

Re: Weird behaviour of Textbox on change event

Post by Czarny_Pijar »

I agree with PeteWG. An additional trimm (or another change) while copying the values between the controls and the database is the certain source of weird behaviour, resulting, for example, with unexpected OnChange() firing.

In other words, while we are at the disposal of the operators 'equal' (=) and 'exactly equal' (==) and 'assign' (:=), however, we do NOT have the operator 'assign exactly ' ( :== ), so I expect this behaviour from the common 'assign'.

Assigning the values between the databases is another story, but I feel, here everybody are used to.
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: <...>
Trimming data "under the hood", is IMHO an arbitrary and perhaps unwanted involvement by the side of system/tool developer.
And if he takes the freedom to trim the data, why not to also capitalize them, why not to transform them into f.e. UTF16, Russian or Greek (thank you very much) codepage and so on..?
It could appear srtange, but I must say that I fully agree with you :)

I'll explain:

In the early times of MiniGUI library development, I've was extremely (too much) responsive to the users input.

There were many reasons for that, the main one, was that I've considered MiniGUI library as an experiment only, so, changes like this could be no so much relevant.

I've not found references to the value trim thing in the original MiniGUI library changelog, but I'm pretty sure that the origin for this was an user request based on the fact that if you assign the content of a character table field to a TextBox, trailing field spaces are copied to the TextBox.

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.

So, I've simply accepted the suggestion and made the change.

Some time later, the project become more serious, since many people was using the library to develop real world applications, so, I've become more and more careful taking changes to the code more seriously.

Today, my answer to this suggestion, could be something like that:

"The user is the responsible for the situation, and he should trim the data prior to send to the TexBox, so, sorry, but I'm not going to do your suggested change' (many, many people hates me for answers like this :).

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 :)
Regards/Saludos,

Roberto


(Veritas Filia Temporis)
Post Reply