Weird behaviour of Textbox on change event
Moderator: Rathinagiri
- 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 Rathi
If you will use ON CHANGE event, don't trim textbox's value
That's all
Regards
--
Esgici
If you will use ON CHANGE event, don't trim textbox's value
That's all
Regards
--
Esgici
Viva INTERNATIONAL HMG
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: Weird behaviour of Textbox on change event
I've been very busy this week and I've absent from the forum until today.rathinagiri wrote:Please consider this sample
<...>
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)
Roberto
(Veritas Filia Temporis)
- 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
Thanks a lot for your concern Roberto.
It is great to hear about the new inputmask.
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.
South or North HMG is worth.
...the possibilities are endless.
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: Weird behaviour of Textbox on change event
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:
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!
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) )
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)
Roberto
(Veritas Filia Temporis)
- 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
Thanks a lot for the explanation Roberto.
Let us not further complicate the things. Leave it as it is.
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.
South or North HMG is worth.
...the possibilities are endless.
Re: Weird behaviour of Textbox on change event
Sometimes trailing spaces create problems with SQL database. Rathi, I also used trim() in C2SQL() function with character values.
Regards.
Sudip
Regards.
Sudip
With best regards,
Sudip
Sudip
- 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 Roberto
but if they will use ON CHANGE event for TEXTBOXs, don't trim textbox's value;
that's all.
Best regards
--
Esgici
Your design is the best as alwaysRoberto Lopez wrote:'This behavior is by design'.
HMG users will TRIM their own values (variables, fields, etc) freely,Roberto Lopez wrote:I'm listening...
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
Re: Weird behaviour of Textbox on change event
Yeah! sure.. Me too, I do have almost the same opinion about him 'Pete'.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
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!
Now seriously, about textbox's trailing spaces trimming or not.Roberto Lopez wrote: I'm listening...
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
- 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
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.
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.
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: Weird behaviour of Textbox on change event
It could appear srtange, but I must say that I fully agree with youPeteWG 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..?
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)
Roberto
(Veritas Filia Temporis)