Ok, now I understand how you implemented that. As it seems, you try to have
a real-time sampling of the existing UI components of the underlying form,
that are alive "somewhere" in memory.
I thought you make one screenshot. For me a single static screenshot would
be enough, but I see that it can be not practical for other developers, so
they would not use the Dialog at all in presence of a BrowserComponents
(useful for maps, instructions viewers, payment screens, and so on).
But at this point I think you have the possibility to create a method like:
WebView.setScreenshotFramerate(int value)
where value is 0 for static refresh
10 is ten per second, and so on.
There is a caveat for the developer who has to test it on real devices if
necessary and create a table of values
or, as in my case, just put 0 for a simple solution.
0 corresponds to a convenience screenshot not to see the BC become blank.
In my app this means that almost all the UI disappears. And so it is also
where a map is displayed, or an on-line payment is going on, for example
when the security code has to be entered over the credit-card webpage.
Regards
Il giorno mercoledì 23 dicembre 2020 alle 03:13:05 UTC+1 Shai Almog ha
scritto:
> That's not a practical solution. The screenshot process happens very
> frequently.
>
> On Tuesday, December 22, 2020 at 10:37:46 PM UTC+2 P5music wrote:
>
>> Thank you for your response.
>> I wonder if it is possible to have an alternate Dialog constructor with a
>> boolean parameter
>>
>> Dialog(boolean wantsToTakeWebViewScreenshot)
>> {
>> ...
>> }
>>
>> The WebView screenshot could be to added the other components' screeshot
>> list, optionally.
>> Optionally means that there is a caveat for the developer.
>> I think that the doing the screenshot for the WebView does not take so
>> long, at least for my application.
>> So I could test it on common devices or emulators, and the slowest ones
>> could be declared not compatible if the waiting time is really too much.
>> What about this?
>>
>> Il giorno martedì 22 dicembre 2020 alle 19:47:43 UTC+1 Steve Hannah ha
>> scritto:
>>
>>> So why obfuscate the underlying form in the first place? Why making
>>>> things like that the WebView is blank?
>>>>
>>>
>>> Dialog IS a Form. Only one Form is displayed at a time. To create the
>>> effect that the previous form is present, we take a screenshot of the form,
>>> and display it as a background to the Dialog.
>>>
>>> An InteractionDialog is NOT a Form. It is a component that is rendered
>>> in the current form's hierarchy.
>>>
>>> This is the fundamental distinction, and all other differences in
>>> behaviour stem from this.
>>>
>>>
>>>
--
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/30e3cef4-a6fe-482c-839e-82953f3a5832n%40googlegroups.com.
