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
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