Yeah, I just provided the error because you asked about, I just would like
to know why the user interface is not reconstructed after orientation
change. The provided mehod above is called both at startup and when an
orientation change occurs, but in the latter case it fails in recreating
the user interface.
Regards
Il giorno domenica 20 settembre 2020 alle 07:18:05 UTC+2 Shai Almog ha
scritto:
> OK I see this printout. Do you have CEF enabled?
> Is there a browser component somewhere?
> This error should be meaningless and shouldn't impact the behavior of the
> app, it's related to the simulator.
>
> On Saturday, September 19, 2020 at 12:30:49 PM UTC+3 P5music wrote:
>
>> No back trace is available, just the text you have read in the previous
>> post.
>> The fab is only added to mainForm and bound to masterContainer (you can
>> see in the code snippet above) but
>> even if I do not have the fab at all in the application the error is
>> issued:
>> Exception in thread "AWT-EventQueue-0" Exception in thread
>> "AWT-EventQueue-0" Exception in thread "AWT-EventQueue-0" Exception in
>> thread "AWT-EventQueue-0" Failed to get location on screen:component must
>> be showing on the screen to determine its location
>>
>> No line is highlighted in the source code because no Java exception is
>> issued.
>>
>> Il giorno sabato 19 settembre 2020 alle 07:41:29 UTC+2 Shai Almog ha
>> scritto:
>>
>>> Do you see the full stack trace?
>>> It should point at a specific line. What's added at that line?
>>> That component should be removed.
>>>
>>> The FAB could be problematic since FAB is added in a unique way. Is it
>>> added to the form or an arbitrary container?
>>>
>>> On Friday, September 18, 2020 at 10:43:10 AM UTC+3 P5music wrote:
>>>
>>>> I only get
>>>> Exception in thread "AWT-EventQueue-0" Failed to get location on
>>>> screen:component must be showing on the screen to determine its location
>>>> Failed to get location on screen:component must be showing on the
>>>> screen to determine its location
>>>> Indeed in my code the removal is performed:
>>>> editingContainer.remove();
>>>> itemListContainer.remove();
>>>> fab.remove();
>>>>
>>>> So what could be the reason?
>>>>
>>>> Il giorno venerdì 18 settembre 2020 alle 06:15:30 UTC+2 Shai Almog ha
>>>> scritto:
>>>>
>>>>> Look at the console when debugging this in the simulator. You would
>>>>> probably see exceptions indicating you can't add a component to a
>>>>> Container
>>>>> if it's already added to some container (even if it's the same
>>>>> container).
>>>>> Yes, you need to adapt the code to handle that logic. Orientation change
>>>>> re-layout needs to be slightly different from first showing of the UI.
>>>>> I'd
>>>>> also recommend an animation on orientation change which is something we
>>>>> don't need/want for the first showing of the form.
>>>>>
>>>>> On Thursday, September 17, 2020 at 12:07:41 PM UTC+3 P5music wrote:
>>>>>
>>>>>> I created a method like the one you can see below. It is called at
>>>>>> startup and it works. It is also called in the orientation change
>>>>>> listener.
>>>>>>
>>>>>> But when the orientation changes I see that the user interface is
>>>>>> cleaned up and no containers appear, that is, the new rotated interface
>>>>>> does not appear, does not form, it is blank.
>>>>>> If there is no call to the remove() methods I get errors like
>>>>>> "already added", and it is reasonable because the containers don't get
>>>>>> removed.
>>>>>> So the right version has to include the remove() calls.
>>>>>>
>>>>>> Hence, I think the code is adding the right containers as it happens
>>>>>> at startup but the user interface is not shown. Why?
>>>>>>
>>>>>> private void setContainersAndForm()
>>>>>> {
>>>>>> editingContainer.remove();
>>>>>> itemListContainer.remove();
>>>>>> fab.remove();
>>>>>>
>>>>>> if (isPortrait() && (editingConditions))
>>>>>> {
>>>>>> new
>>>>>> EditingForm(appData,myData,mainForm,editingContainer,otherParameters).show();
>>>>>> setEditor();
>>>>>>
>>>>>> if (isPortrait() && !(editingConditions)
>>>>>> {
>>>>>> removeContainers();
>>>>>>
>>>>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(1*100)),fab.bindFabToContainer(masterContainer));
>>>>>> }
>>>>>>
>>>>>> if(isTablet() && !isPortrait() )
>>>>>> {
>>>>>>
>>>>>> removeContainers();
>>>>>>
>>>>>> ((EditingContainer)editingContainer).setCallingForm(mainForm);
>>>>>>
>>>>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(leftContainerRatio*100)),fab.bindFabToContainer(masterContainer))
>>>>>> .add( editingContainer);
>>>>>> if (editingConditions) setEditor();
>>>>>>
>>>>>> }
>>>>>>
>>>>>> // also with these two lines
>>>>>> //mainEditingContainer.revalidate();
>>>>>> //itemListContainer.revalidate();
>>>>>>
>>>>>> mainForm.revalidate();
>>>>>> }
>>>>>>
>>>>>> Il giorno giovedì 17 settembre 2020 alle 06:15:49 UTC+2 Shai Almog ha
>>>>>> scritto:
>>>>>>
>>>>>>> Look sat the code for kitchen sink. Notice we encapsulate each demo
>>>>>>> in a Demo class. Then in the main KitchenSink class we show either a
>>>>>>> Form
>>>>>>> or a Container based on the mode (tablet or phone). Yes it's pretty
>>>>>>> similar
>>>>>>> to this.
>>>>>>>
>>>>>>> On Wednesday, September 16, 2020 at 9:54:57 AM UTC+3 P5music wrote:
>>>>>>>
>>>>>>>> What you say seems to be merging the two things, like I am already
>>>>>>>> doing? Indeed my app is for tablet and phone, so my question was just
>>>>>>>> about
>>>>>>>> the management of these two scenarios, and the orientation too.
>>>>>>>>
>>>>>>>> Is this what you are advicing?
>>>>>>>>
>>>>>>>> if (isPortrait() && (editingConditions))
>>>>>>>> {
>>>>>>>> new
>>>>>>>> EditingForm(appData,myData,mainForm,editingContainer,otherParameters).show();
>>>>>>>> setEditor();
>>>>>>>>
>>>>>>>> if (isPortrait() && !(editingConditions)
>>>>>>>> {
>>>>>>>> removeContainers();
>>>>>>>>
>>>>>>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(1*100)),fab.bindFabToContainer(masterContainer));
>>>>>>>> }
>>>>>>>>
>>>>>>>> if(isTablet() && !isPortrait() )
>>>>>>>> {
>>>>>>>>
>>>>>>>> removeContainers();
>>>>>>>>
>>>>>>>> ((EditingContainer)editingContainer).setCallingForm(mainForm);
>>>>>>>>
>>>>>>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(leftContainerRatio*100)),fab.bindFabToContainer(masterContainer))
>>>>>>>> .add( editingContainer);
>>>>>>>> if (editingConditions) setEditor();
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> Thanks in advance
>>>>>>>> Il giorno mercoledì 16 settembre 2020 alle 04:40:29 UTC+2 Shai
>>>>>>>> Almog ha scritto:
>>>>>>>>
>>>>>>>>> My advice is to use Containers for everything but have global
>>>>>>>>> navigation logic. So when you need to show a UI element you can
>>>>>>>>> invoke that
>>>>>>>>> single place that decides.
>>>>>>>>>
>>>>>>>>> If this is on a phone you would create a Form add the container to
>>>>>>>>> it and set its title etc. then show.
>>>>>>>>> If this is a tablet you would replace the last container.and
>>>>>>>>> update the subtitle in the UI
>>>>>>>>>
>>>>>>>>> On Tuesday, September 15, 2020 at 10:39:40 AM UTC+3 P5music wrote:
>>>>>>>>>
>>>>>>>>>> So your advice is to use one form for the master/detai in every
>>>>>>>>>> configuration, just managing the container, with the override of the
>>>>>>>>>> back
>>>>>>>>>> button and using the back command to manage the container inside the
>>>>>>>>>> form.
>>>>>>>>>> So I have not to do this:
>>>>>>>>>>
>>>>>>>>>> if (isPortrait() && (*conditionsAreTrue*))
>>>>>>>>>> {
>>>>>>>>>> new EditingForm(appData,myData,mainForm,editingContainer,other
>>>>>>>>>> parameters).show();
>>>>>>>>>> }
>>>>>>>>>> (this is what I am trying to do now)
>>>>>>>>>>
>>>>>>>>>> the form will be just used when a new screen has to be presented,
>>>>>>>>>> like the help form.
>>>>>>>>>> Is it right?
>>>>>>>>>>
>>>>>>>>>> Il giorno martedì 15 settembre 2020 alle 03:50:41 UTC+2 Shai
>>>>>>>>>> Almog ha scritto:
>>>>>>>>>>
>>>>>>>>>>> You can use setBackCommand and override the hardware back
>>>>>>>>>>> command to have any functionality you want. It can just replace
>>>>>>>>>>> containers
>>>>>>>>>>> and then eventually move a form. You obviously need to keep track
>>>>>>>>>>> of
>>>>>>>>>>> everything which isn't simple.
>>>>>>>>>>>
>>>>>>>>>>> On Tuesday, September 15, 2020 at 12:48:15 AM UTC+3 P5music
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> My app needs to manage cases where a back navigation occurs but
>>>>>>>>>>>> not toward the original master/detail form, indeed to a different
>>>>>>>>>>>> orientation of the editing view itself.
>>>>>>>>>>>> For example the editing view in portrait mode is fullscreen and
>>>>>>>>>>>> can undergo a device rotation: in that case the landscape mode is
>>>>>>>>>>>> the new
>>>>>>>>>>>> full screen mode for the editing view, while master/detail is
>>>>>>>>>>>> reached back
>>>>>>>>>>>> only when further back navigation occurs when the user tap the
>>>>>>>>>>>> back button.
>>>>>>>>>>>>
>>>>>>>>>>>> So I thought this has to be accompished with a new form: the
>>>>>>>>>>>> editing form, to which the editing container is added, because I
>>>>>>>>>>>> think it
>>>>>>>>>>>> is the right way to manage back navigation, that is. navigation is
>>>>>>>>>>>> between
>>>>>>>>>>>> forms, back and forth.
>>>>>>>>>>>>
>>>>>>>>>>>> I ask whether the editing container has to be recreated, or it
>>>>>>>>>>>> can removed from the master/detail form and then added to the
>>>>>>>>>>>> editing form.
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Il giorno domenica 13 settembre 2020 alle 03:43:59 UTC+2 Shai
>>>>>>>>>>>> Almog ha scritto:
>>>>>>>>>>>>
>>>>>>>>>>>>> I mean having containers side by side in one form (see the
>>>>>>>>>>>>> kitchen sink where we do just that).
>>>>>>>>>>>>> I don''t recommend having a form embedded in a form. Forms are
>>>>>>>>>>>>> very "heavy" and things sometimes fail when you add a form inside
>>>>>>>>>>>>> another
>>>>>>>>>>>>> form. Historically this was prohibited (we'd throw an exception
>>>>>>>>>>>>> in that
>>>>>>>>>>>>> case) but some use cases for embedding a form do exist. I'd still
>>>>>>>>>>>>> avoid it
>>>>>>>>>>>>> when possible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Saturday, September 12, 2020 at 12:31:31 PM UTC+3 P5music
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, do you mean having two forms side by side, that
>>>>>>>>>>>>>> expands when in portrait mode going full screen singularly, or
>>>>>>>>>>>>>> you mean
>>>>>>>>>>>>>> that I open another form on top of the main form?
>>>>>>>>>>>>>> I started creating an editing container that can be added to
>>>>>>>>>>>>>> the main form or to the editing form, so I remove all and then
>>>>>>>>>>>>>> add again.
>>>>>>>>>>>>>> Is this the right way to do that?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Il giorno sabato 12 settembre 2020 alle 07:04:13 UTC+2 Shai
>>>>>>>>>>>>>> Almog ha scritto:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In some cases you need two forms and in some cases two
>>>>>>>>>>>>>>> containers.
>>>>>>>>>>>>>>> The trick for doing this is to work with two containers and
>>>>>>>>>>>>>>> when necessary wrap them in a Form to enable the two page
>>>>>>>>>>>>>>> master detail.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Friday, September 11, 2020 at 3:41:56 PM UTC+3 P5music
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> My Codename app has master/detail layout.
>>>>>>>>>>>>>>>> According to orientation the detail (editing) or the master
>>>>>>>>>>>>>>>> can stay full screen.
>>>>>>>>>>>>>>>> I have to handle many orientation and editing status
>>>>>>>>>>>>>>>> configurations, so sometimes the editing screen will be
>>>>>>>>>>>>>>>> displayed out of
>>>>>>>>>>>>>>>> the master screen in portrait orientation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The back navigation (button and other gestures) has to be
>>>>>>>>>>>>>>>> managed in both cases.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am not sure if I have to use a main form and two
>>>>>>>>>>>>>>>> containers, or instead two forms, that is, also an EditingForm
>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>> EditingContainer inside.
>>>>>>>>>>>>>>>> Thanks in advance
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
--
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 codenameone-discussions+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/8649649a-ce77-4694-934e-316f43810914n%40googlegroups.com.
