FAB wasn't designed for form adding/removing. There's a bit of logic there. I'll try to add an unbind() method for next weeks update.
On Thursday, September 24, 2020 at 10:08:30 AM UTC+3 P5music wrote: > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/fc65b150-7ef4-4355-91a7-04a66421c38bn%40googlegroups.com.
