Yes, I remember that discussion, I also adopted your solution, but the fab now is bound to a form, so why is the runtime complaining? If fab is problematic, what's the solution? Is this an issue? Thanks
Il giorno giovedì 24 settembre 2020 alle 04:41:33 UTC+2 Shai Almog ha scritto: > Fab is a bit problematic in that sense. You don't add it to a container. > You bind it. > It also acts differently depending on your target container, see this > recent discussion: > https://stackoverflow.com/questions/63845751/codenameone-floating-action-button-binding-error/63856717 > > On Wednesday, September 23, 2020 at 10:44:04 AM UTC+3 P5music wrote: > >> I just can use this workaround, because otherwise it does not work. So I >> have to call revalidate() in two differents steps. >> Said that, now the problem is the floating action button. As in the >> second example there is an error issued. >> What's wrong? >> Regards >> >> Il giorno mercoledì 23 settembre 2020 alle 04:17:41 UTC+2 Shai Almog ha >> scritto: >> >>> A single revalidate on the main form should work fine. Doing additional >>> revalidates might cause them to disrupt one another. >>> Notice that you might want to use the version of revalidate that plays >>> nicely with animations. >>> >>> On Monday, September 21, 2020 at 11:51:20 AM UTC+3 P5music wrote: >>> >>>> It's very strange. I had to add a revalidate() also after removing the >>>> containers. >>>> I do not know if it is intended behaviour but this code works (see also >>>> below this code, there is the second part of this message about fab >>>> breaking it): >>>> >>>> private void setContainers() >>>> { >>>> >>>> mainEditingContainer.remove(); >>>> itemListContainer.remove(); >>>> //fab.remove(); >>>> >>>> >>>> mainEditingContainer.revalidate(); >>>> itemListContainer.revalidate(); >>>> mainForm.revalidate(); >>>> >>>> if (isPortrait() && (other conditions*)*) >>>> { >>>> new EditingForm(appData,myData,mainForm,editingContainer,other >>>> Parameters).show(); >>>> >>>> } >>>> >>>> if (isPortrait() && !(*other conditions*)) >>>> { >>>> >>>> //mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(1*100)),fab.bindFabToContainer(itemListContainer)); >>>> >>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(1*100)), >>>> itemListContainer); >>>> } >>>> >>>> if(isTablet() && !isPortrait() ) { >>>> >>>> /*mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int) >>>> >>>> (leftContainerRatio * 100)), fab.bindFabToContainer(itemListContainer)) >>>> .add(mainEditingContainer);*/ >>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int) >>>> >>>> (leftContainerRatio * 100)), itemListContainer) >>>> .add(mainEditingContainer); >>>> >>>> } >>>> >>>> } >>>> >>>> mainEditingContainer.revalidate(); >>>> itemListContainer.revalidate(); >>>> mainForm.revalidate(); >>>> } >>>> ------ >>>> >>>> But now the fab problem is back. Indeed if I use this code >>>> >>>> >>>> private void setContainers() >>>> { >>>> >>>> mainEditingContainer.remove(); >>>> itemListContainer.remove(); >>>> >>>> if (!fabFirstTime) fab.remove(); >>>> >>>> >>>> mainEditingContainer.revalidate(); >>>> itemListContainer.revalidate(); >>>> mainForm.revalidate(); >>>> >>>> if (isPortrait() && (*conditions*) >>>> { >>>> new EditingForm(appData,myData,mainForm,editingContainer,other >>>> parameters).show(); >>>> >>>> } >>>> >>>> if (isPortrait() && !(*conditions*) >>>> { >>>> >>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int)(1*100)),fab.bindFabToContainer( >>>> itemListContainer)); >>>> } >>>> >>>> if(isTablet() && !isPortrait() ) { >>>> >>>> mainForm.add(tl.createConstraint().heightPercentage(100).widthPercentage((int) >>>> >>>> (leftContainerRatio * 100)), fab.bindFabToContainer(itemListContainer >>>> )).add(mainEditingContainer); >>>> >>>> } >>>> >>>> mainEditingContainer.revalidate(); >>>> itemListContainer.revalidate(); >>>> mainForm.revalidate(); >>>> >>>> if (fabFirstTime) fabFirstTime=false; >>>> >>>> } >>>> >>>> the user interface is not reconstructed again and no button is visible. >>>> If I do not remove the fab I get the error >>>> Component is already contained in Container: Container[x=0 y=0 >>>> width=1136 height=1920 name=null, layout = FlowLayout, scrollableX = >>>> false, >>>> scrollableY = false, components = [FloatingActionButton]] >>>> but I can see the button (in an wrong position because it is the old x >>>> position I think, indeed orientation change has occurred). >>>> Thanks in advance >>>> >>>> Il giorno lunedì 21 settembre 2020 alle 04:35:07 UTC+2 Shai Almog ha >>>> scritto: >>>> >>>>> 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 codenameone-discussions+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/c1b509fc-69ba-4e70-aa10-97df32983ebfn%40googlegroups.com.
