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/10d0ba4f-3ad2-41a3-8844-424c35fea4adn%40googlegroups.com.
