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/81b581f0-3573-4840-be4d-d80314d68c1cn%40googlegroups.com.
