LiveCode Forums.

Mark wrote:FlushEvents is incompatible with iOS (this thread is in the iOS Deployment forum). This was mentioned two times earlier in this thread.

Thank you for your correction, Mark, but please understand that I had searched for the string "flushEvents" before posting and came up empty. In which two posts was it mentioned, and more on-topic, why is this useful function not available for iOS?

Richard,

That's weird, if I search for "flushEvents" on the page, Firefox finds it. Don't ask me why this feature isn't available in iOS. Ask Kevin c.s.

Mark

Thanks anyway for your contribution Richard, though not in this case, I still want to read up on this flushEvents function.

Mag wrote:Thanks anyway for your contribution Richard, though not in this case, I still want to read up on this flushEvents function.

If it seems useful you may also consider filing a bug report to have that language feature enabled for mobile platforms; I couldn't find any outstanding issues for flushevents reported there:
http://quality.runrev.com/

Thanks Richard.

PS
Just to add a new information...

Card 1
Button "go to card 2"
Button "cover button" -- it covers the button below while the mergAV control is created

Card 2
Button "3"

Clicking 4 times in the location of button "go to card 2" when the button "cover button" is displayed happens this:

As soon as the control is created, you go in the next card and button 3 gets mouseUp 3 times

Hi,

I don't think this is a LiveCode bug. This much more seems like a Monte bug Have you reported this issue to him already? He might be able to give you some more insights into what is happening. Something seems to be locking the messages until after the control is created.

Best regards,

Mark

Hmm... Thanks Ivan for alerting me to this thread.

I'm not positive there's a bug here. It's standard engine behavior for messages to be queued while blocking commands are running.

It's a long thread and I might have missed something important but I'm wondering what the issue is with hiding the controls until the command returns. If you can isolate the problem then please send me a stack so I can test here.

Monte,

There is no reason to think that any commands are blocking the mouseDowns/mouseUps, except for your external. Perhaps you want to have a look at the project?

Best,

Mark

I'm more than happy to take a look Mark once I can define the problem. At the moment it appears that the problem could be stated as "a blocking command displays standard blocking behavior". So I'm not sure what to fix there.