WebTextField.TextChanged Fires Twice (2014r2.1) - please prioritize this bug

Or tell me if I am missing something.

FYI - <https://xojo.com/issue/35602>

I’m using Xojo 2014r2.1 on Windows 8.1, and Firefox (latest version). Here’s what I have (since I’m unable to download your project to test with):

webPage w/ textField1 and label1 on it. In the textField1.textChange event, I have the following code:

label1.text = str(val(label1.text) + 1)

Works as expected for me. No double events being fired. If anything, if I type too fast, it doesn’t fire enough (which is understandable, because of latency). Could it be a browser specific issue? Please let me know what browser you’re using, and possibly attach a link to your project here for me to try. Thanks!

I was fooled by the same thing. After you change the text, click on the page to take the focus off of the textfield and tell me if you don’t see the label value increment one more time.

Okay, was able to get your project… let me take a look.

You are right, Mark. Losing focus caused the textChange event to fire for me too.

I went for a couple days thinking there was something special (problematic) in my customer app - since I saw the same single fire you mention above - but couldn’t pin it down, so looked harder in the test app and finally noticed the second fire.

Add a global property labeled ‘lastText’. Use:

if lastText <> textfield1.text then Dim i As Integer kounter = kounter + 1 Label1.Text = str(kounter) lastText = textfield1.text Button1.SetFocus end if

It’s a workaround, which isn’t what we want (we want it to work as intended to begin with), but this should be easy to implement and quickly.

I like that - I think I can make that work.
Thanks.

Anytime, man!

The bug is extremely vicious. In a test project where I record through system.debuglog (much better than a label) the Ticks value in the TextChanged event of a TextField,

Not only is it not consistent, and sometimes the double firing does not occur, And sometimes the second firing occurs one second after the first one.

So, to work around the bug, you cannot rely on a single boolean to weed out the second firing that may not come.

Eric’s idea is probably the best.

For the record - and to keep the pressure on Xojo to fix the bug - this proposed change has some risk for my app.
I have a few pages, each with a container that has 50-70 text fields in it. The TextChanged events all trigger the same DataModified event of the container - so that is where I need to implement this work around (since I do NOT want to change the code for 200 TextFields).

So the problem I face is if the value of the previous field is the same as the newly entered value of the current field - I probably won’t properly detect the change in the new field (I need to work with this a little - to see) - and that would be bad because I am not saving the new data the customer entered for that field.

I was playing with another workaround that used a timer that is triggered by the SaveButton I have on the page. When user clicks the SaveButton - I wait 3 seconds before saving - which gives enough time for the second TextChanged event to fire after the field loses focus (because the user clicked on the SaveButton). I hope I can get your approach to work, because that is a cleaner user experience.

There may be another way : the bug does not seem present in the TextArea (just tested).

[quote=133204:@Mark Pastor]For the record - and to keep the pressure on Xojo to fix the bug - this proposed change has some risk for my app.
I have a few pages, each with a container that has 50-70 text fields in it. The TextChanged events all trigger the same DataModified event of the container - so that is where I need to implement this work around (since I do NOT want to change the code for 200 TextFields).

So the problem I face is if the value of the previous field is the same as the newly entered value of the current field - I probably won’t properly detect the change in the new field (I need to work with this a little - to see) - and that would be bad because I am not saving the new data the customer entered for that field.

I was playing with another workaround that used a timer that is triggered by the SaveButton I have on the page. When user clicks the SaveButton - I wait 3 seconds before saving - which gives enough time for the second TextChanged event to fire after the field loses focus (because the user clicked on the SaveButton). I hope I can get your approach to work, because that is a cleaner user experience.[/quote]

Can you pass the .controlId of the textfield object to help handle this? I would probably then, instead of a property as a string to handle this, create a dictionary… then use something like (but in the DataModified):

if myFields.lookUp(me.controlId, nil) <> me.text then
Dim i As Integer
kounter = kounter + 1
Label1.Text = str(kounter)
myFields.value(me.controlId) = me.text
Button1.SetFocus
end if

Thanks for checking that out - I thought about that, but didn’t test it yet. At first glance, changing 200 of them didn’t sound very attractive - I know I can probably ‘bulk’ change them, but then I have to deal with impacts to styles, etc, etc. But I will definitely keep that approach in mind.

I haven’t been on the forum much lately Michel - nice to see your new earthling image!

[quote=133215:@Eric Brown]Can you pass the .controlId of the textfield object to help handle this? I would probably then, instead of a property as a string to handle this, create a dictionary… then use something like (but in the DataModified):

if myFields.lookUp(me.controlId, nil) <> me.text then
Dim i As Integer
kounter = kounter + 1
Label1.Text = str(kounter)
myFields.value(me.controlId) = me.text
Button1.SetFocus
end if[/quote]

Sorry guys - it looks like my responses were not coming in sync to your comments.

Yep - id’ing the calling object may help - I might just add LastObject with LastText and use them both. Was also wondering if setting LastText in the GotFocus event would work - but timing between GotFocus of one object and LostFocus of another has always been a problem for me.