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/2fba982c-ba7e-4e18-a544-96a94043817fn%40googlegroups.com.
