HMGforum.com

Hi Rathi

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

That's all

Regards

--

Esgici

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.

Thanks a lot for your concern Roberto.

It is great to hear about the new inputmask.

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!

Thanks a lot for the explanation Roberto.

Let us not further complicate the things. Leave it as it is.

Sometimes trailing spaces create problems with SQL database. Rathi, I also used trim() in C2SQL() function with character values.
Regards.
Sudip

Hi Roberto

Roberto Lopez wrote:'This behavior is by design'.

Your design is the best as always

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

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

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.

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