Android Question button click event fired in spite of it being disabled?

[leitor79]

Hello,

I have this kind of function:

Sub Button1_Click
    DisableButtons
    DoStuff1
    DoStuff2
    DoStuff3
        DoStuff3a
        DoStuff3b  <--------- ISSUE HERE
        DoStuff3c
    EnableButtons
End Sub

In DoStuff3b, when I fast-compulsively-hit Button1 (testing purposes), I get an exception telated to that sub being fired more than once before it is finished for the previous execution (some list, that's cleared at the end, having more items than it should; also, debugging logs seems to confirm that)

It seems strange to me since DisableButtons goes like this:

Button1.Enabled = False
Button1.Visible = False 'added to try to avoid the previous exception; It didn't worked
Sleep(0) 'same comment as the line above

I appreciate directions about where could I look for issues...

Thank you very much!

 

[stevel05]

There is not really enough information to give an answer, but as a first guess : do any of the called subs have a Callsubdelayed, or a Wait For in them?

 

[leitor79]

There is not really enough information to give an answer, but as a first guess : do any of the called subs have a Callsubdelayed, or a Wait For in them?

Hi Steve, thank you very much for your answer.

I know there is a little information, but the code involved is too long; I don't pretend anyone to give me a straight answer, just something like you did.

I don't have callsubdelayed or wait for in the code involved. Just Sleep(0).

Thank you very much!

 

[DonManfred]

try to increase the time a bit. maybe 200 (ms)

 

[stevel05]

The Sleep function will return from the sub at the point it's called, so all subsequent subs will be run at that time. When the Sleep is resumed all the other process (including the enable buttons) will have run. So if you are accessing the list after the sleep, it may well have been altered. See the simple example attached.

 

[leitor79]

Thank you very much for your answer, Don!

Incrementing the sleep time helped in debug mode, but in release mode the issue is still happening.

I don't know if it could have something to do, but I have a progressdialogshow(2) that "dissapears", before the ProgressDialogHide, in middle of DoStuff3b (no matter if the exception is raised or not)

try to increase the time a bit. maybe 200 (ms)

Thank you very much for your answer, Don!

Incrementing the sleep time helped in debug mode, but in release mode the issue is still happening (less frequently).


Regards!

 

[leitor79]

The Sleep function will return from the sub at the point it's called, so all subsequent subs will be run at that time. When the Sleep is resumed all the other process (including the enable buttons) will have run. So if you are accessing the list after the sleep, it may well have been altered. See the simple example attached.

Thank you very much for your time, and your answer!

I've tried your example and I see potential trouble there. I should add some Wait For between DoStuffX. However, this is not what it's happening; most likely otherwise.

For example; DoStuff2 loads a Global list with 4 items (always 4). DoStuff3 uses that list and clears it at the end. When the exception is raised at DoStuff3 is because the list has 12 items. Debug logs seems to confirm DoStuff2 is executed 3 times before DoStuff3 ends.

I think I've traced the problem to a text update issue.

In fact, in my code, Button1_Click shares the same logic with a (modified) AutoTextSizeLabel. So, ALabel1_Click does the same that Button1_Click (and it's also disabled an re-enabled). Since both controls are close (over?) to each other I don't really know which one I was compulsively clicking. DoStuff1 changes the text of ALabel1, which fires SetText method, that uses StringUtils.MeasureMultilineTextHeight and MeasureStringWidth (maybe there are some async calls there?).

I don't know why, but if I remove the ALabel1_Click event, the issue stops happening.

Changing the text of this control could be, briefly, re-enabling it?

Maybe setting the text is calling some async stuff?

Anyway, although not being the cause of my problem, your suggestion pointed me to a future problem I can solve before it happened, thank you very much!!!