That wouldn't fit and would again create a bad UX for the end user.
On Wednesday, December 23, 2020 at 9:54:44 AM UTC+2 P5music wrote:
> 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/ab1a1947-68eb-44a2-9838-d928d83e621cn%40googlegroups.com.
