It's inconsistent on devices. That's the biggest problem. We can't grab a screenshot of a browser component on the device due to technical/security concerns so we can't implement dialog properly when a browser component is below it.
On Wednesday, December 16, 2020 at 1:29:52 PM UTC+2 P5music wrote: > I reverted my code back to using Dialogs instead of InteractionDialogs. > The code is much simpler and readable. I see that now the Dialog does not > block the BrowserComponents in the underlying layout, so it can be used. > > [I was said, if I am not wrong, that when the Dialog is displayed it is > like another form is shown, unlike the InteractionDialog. And a sort of > freezed image of the previous screen is displayed, it is sort of fake. No > problems for me. > When the Dialog is dismissed the BC comes back. It seems that it is just > displayed again and not reloaded (I see no onload event). This is good. > My advice is to perfection Dialog and not InteractionDialog, because with > ID mouse events leak onto the underlying form and have to be handled, as > also has the back command.] > But > I see that while the Dialog is displayed, the underlying BrowserComponents > are empty and all white (although greyed out). > When the Dialog is displayed I see that the other UI components are > displayed with their content, so why just the BrowserComponent is blank? > Maybe this is a bug and it was forgotten to make its "screenshot", like for > other components? > Is it so also on devices? > > Thanks, regards > > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/28a5fd31-2610-4bc8-9910-df3c0cf1222dn%40googlegroups.com.
