I assumed incorrectly that you're adding a component that's already added.
I think what's happening is that you removed the components before the
re-layout then added them after. You would need to do either an
animateLayout() or a revalidate() in this case.
On Sunday, September 20, 2020 at 3:16:12 PM UTC+3 P5music wrote:
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/7e9d414d-28d2-4800-82bd-921ca4cd2855n%40googlegroups.com.
