Wish Consuming queued MouseEvents

Hi @Erel,
I don't know whether this is feasible at all (and extending it to all the platforms could be even worse).
Anyway, testing a B4J sw (in Debug mode) today I observed that a panel (splash screen) covering a second one (commands panel) not necessarily is able to consume all the pending MouseEvents (clicks) before becoming invisible (or moved to the back). This causes the secondary panel to receive a click originally performed on the now disappeared panel.

I solved with a Sleep(xx) instruction soon after the pnlSplah.Visible=False one, where xx depends on how quickly I click the mouse buttons when the splash panel is showing.
pnlSplash is set Enabled and event pnlSplash_MouseClicked contains its EventData.Consume instruction. So I believe it's a queue matter.

My wish is for a command like "empty the queue from pending MouseEvents" that I could call when I make the splash panel invisible and soon before the commands panel gets in full view, ready to accept clicks.

udg

Update
I tested the above with a simplified, no-B4xPages app and it doesn't show the same behaviour.
Working on my original B4xPages code I found a couple of surprising conditions:
1. B4xPage_Foreground gets called before B4xPage_Created (talking about MainPage)
2. The couple "Page1.Initialize - B4XPages.AddPageAndCreate(..)" is not "atomic" in the sense that if you have a few pages to init, you see the creation of all of them, then, eventually, some code (I tried with a simple Log instruction that follows the block of initializations) and, finally, by as many Resize actions as your initialized pages.

In my case I had the hiding of the splash screen just following the block, so the result was that the underlying panel came to view before all the init was done.
I changed my code so now I have an InitPages ResumableSub that's called by a wait-for in the Created event prior to hide the splash screen (and I could eliminate the sleep instruction mentioned in my post above).

Since this is a wish, maybe a better one could be:
- add a core/global AcceptInput(<code> as int, action as boolean)
where <code> would use constants like Mouse, Keyboard ANDed together to specify on which input channel apply the action
The function, when action is False, will cause an internal consumption of any event of the given type until a subsequent call to the same function with action=True.

Again, I don't know whether this is feasible.

Io non c'ho capito 'na mazza ?
(I didn't understand anything).

I only understood point 1 correctly and it seems to me somewhat strange/unlikely.

Yes, I find it surprising too, but to be honest the definition is:
B4XPage_Foreground - Called when the app moved to the foreground.
So it looks somewhat "indipendent" of the MainPage creation.

udg said:

Yes, I find it surprising too, but to be honest the definition is:
B4XPage_Foreground - Called when the app moved to the foreground.
So it looks somewhat "indipendent" of the MainPage creation.

Click to expand...

I don't think so; just Created was executed while the app was still in background but the sequence is still Created-->Foreground.
Note that B4XPage_Foreground is executed whatever page is currently on top of the pages stack.