Elegant solution:
I created the class BackCommand that extends Command.
BackCommand has a member that is a runnable that will be run from the
@Override actionPerformed() method.
A single instance of BackCommand is assigned to the form (and the toolbar),
it does not change.
The various dialogs that can be called even one on top of the other just
reference that single instance of BackCommand
and in turn change/restore only the runnable.
When a CommandDialog instance is created it performs the change/restore by
its own. It is very useful around the app in many places.
But I know that opening another InteractionDialog on top of it causes the
CommandDialog to release, and its show() method to return.
So when used in this special case the CommandDialog can retain from the
change/restore process and delegates the restore process to the method that
creates the InteractionDialog, passing the suitable runnable.
Regards
Il giorno lunedì 18 gennaio 2021 alle 12:47:38 UTC+1 P5music ha scritto:
> If nothing can be done for the strange releasing of the CommandDialog's
> latch
> [but something strange is happening because I cannot debug that point
> (there with a long delay)]
>
> I think the workaround I devised is acceptable:
> The method that opens the CommandDialogs will not restore the back command
> if the show method returns early, that is, after the further
> InteractionDialog has been opened (here's the latch release).
> So there is no concurrent setting of the backCommand.
>
>
> Then the CommandDialog is called again from inside the disposing
> InteractionDialog after its back command is called (now assigned to the
> toolbar and the form).
> (the old back command was passed as a parameter to the method that opens
> the InteractionDialog and swiftly restored)
>
> But
> I realized that the right way is to use both
>
> form.setBackCommand(backCommand);
> and
> form.getToolbar().setBackCommand(backCommand);
> to set
>
> and
>
> form.setBackCommand(oldBackCommand);
> and
> form.getToolbar().setBackCommand(oldBackCommand);
> to restore.
>
> Now I see three back buttons on the toolbar.
> I have to avoid this.
>
> How do I remove the old button, or change directly its command, instead of
> the toolbar's one?
> Thanks
>
> Il giorno domenica 17 gennaio 2021 alle 13:11:37 UTC+1 P5music ha scritto:
>
>> I have to say that a subtle reference mistake made debug not reliable.
>> Now I fixed the reference to the form, and restored the preferred user
>> experience (the back button on the toolbar is assigned to dispose the
>> further InteractionDialog: the old back command of the form is replaced and
>> after the disposal it is restored).
>>
>> (the user experience is like: a form opens a second form that in turn
>> opens a CommandDialog, that opens a further InteractionDialog when the user
>> clicks a certain button)
>> I think I understand what happens:
>> When the CommandDialog opens a further InteractionDialog, that causes the
>> latch in the CommandDialog to be released.
>> This causes the CommandDialog to dispose
>> and
>> the old back command of the form is restored so this is why using the
>> back button on the toolbar when the InteractionDialog is on screen causes
>> the second form to close and go back to the first form. (Indeed the old
>> back command was already restored by the unseen disposal of the
>> CommandDialog).
>>
>> Said that now the question is
>> why showing the further InteractionDialog causes the latch to release?
>> It is not mouse events fault, indeed I see that the ActionListener is not
>> called. (I remind you that there is a giant transparent button as
>> background of the CommandDialog to intercept the mouse events outside the
>> dialog)
>>
>> Do you know why the latch could be released?
>>
>> Il giorno domenica 17 gennaio 2021 alle 03:41:57 UTC+1 Shai Almog ha
>> scritto:
>>
>>> Can you isolate a test case of the toolbar not hiding?
>>>
>>> On Saturday, January 16, 2021 at 6:30:13 PM UTC+2 P5music wrote:
>>>
>>>> -In regard to the dialog being disposed
>>>> It seems that showing an InteractionDialog on top of a CommandDialog
>>>> makes the await() of the latch stop,
>>>> because the CommandDialog has a transparent background
>>>> InteractionDialog that consumes the mouse events, that is, it's like the
>>>> mouse was clicked outside when the user interacts with the second dialog.
>>>> -In regard to hiding the toolbar it just does not happen.
>>>>
>>>> Regards
>>>> Il giorno sabato 16 gennaio 2021 alle 07:37:20 UTC+1 Shai Almog ha
>>>> scritto:
>>>>
>>>>> Can you provide a screenshot and the way in which you used these APIs?
>>>>>
>>>>> On Friday, January 15, 2021 at 11:34:38 AM UTC+2 P5music wrote:
>>>>>
>>>>>> Those instructions did not succed in hiding the toolbar.
>>>>>> Also, if I click the "back" button in the second dialog
>>>>>> (InteractionDialog or CommandDialog, does not make any difference) it is
>>>>>> disposed, but I do not see the first dialog anymore (CommandDialog).
>>>>>> Regards
>>>>>>
>>>>>> Il giorno venerdì 15 gennaio 2021 alle 06:31:45 UTC+1 Shai Almog ha
>>>>>> scritto:
>>>>>>
>>>>>>> try setVisible(false) and setHidden(true)
>>>>>>>
>>>>>>> On Thursday, January 14, 2021 at 12:04:21 PM UTC+2 P5music wrote:
>>>>>>>
>>>>>>>> So I tried hideToobar() but it does not work, the toolbar still is
>>>>>>>> there.
>>>>>>>> What can be done?
>>>>>>>> Regards
>>>>>>>> Il giorno giovedì 14 gennaio 2021 alle 03:59:56 UTC+1 Shai Almog ha
>>>>>>>> scritto:
>>>>>>>>
>>>>>>>>> Try hideToolbar()
>>>>>>>>>
>>>>>>>>> On Wednesday, January 13, 2021 at 11:23:32 AM UTC+2 P5music wrote:
>>>>>>>>>
>>>>>>>>>> I did some debugging and it seems that the old toolbar cannot be
>>>>>>>>>> overidden.
>>>>>>>>>> The last resort is to change the user experience, avoid using the
>>>>>>>>>> toolbar but I cannot get rid of it. I used
>>>>>>>>>> form.getToolbar().setEnabled(false);
>>>>>>>>>> but the toolbar is there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Il giorno mercoledì 13 gennaio 2021 alle 04:19:49 UTC+1 Shai
>>>>>>>>>> Almog ha scritto:
>>>>>>>>>>
>>>>>>>>>>> It's hard for me to tell without a debugger. Try stepping over
>>>>>>>>>>> the code to understand the flow.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tuesday, January 12, 2021 at 11:25:03 AM UTC+2 P5music wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I think it is better for my app to create a further
>>>>>>>>>>>> InteractionDialog.
>>>>>>>>>>>> When I do so I have to manage the back command on toolbar.
>>>>>>>>>>>>
>>>>>>>>>>>> The user experience is to start from the main form, then call a
>>>>>>>>>>>> second form and there the first dialog is displayed.
>>>>>>>>>>>>
>>>>>>>>>>>> This is the code portion at the beginning of the method that
>>>>>>>>>>>> shows the second dialog from the first dialog:
>>>>>>>>>>>>
>>>>>>>>>>>> Toolbar toolbar=form.getToolbar();
>>>>>>>>>>>> InteractionDialog dialog=new InteractionDialog();
>>>>>>>>>>>> Command oldBackCommand=form.getBackCommand(); //no method
>>>>>>>>>>>> toolbar.getBackCommand()
>>>>>>>>>>>> Command backCommand=new Command("Back") {
>>>>>>>>>>>> @Override
>>>>>>>>>>>> public void actionPerformed(ActionEvent evt) {
>>>>>>>>>>>> toolbar.setBackCommand(oldBackCommand);
>>>>>>>>>>>> form.setBackCommand(oldBackCommand);
>>>>>>>>>>>> dialog.dispose();
>>>>>>>>>>>> }
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> form.setBackCommand(backCommand);
>>>>>>>>>>>> //or
>>>>>>>>>>>> //form.setBackCommand(null); same behaviour
>>>>>>>>>>>>
>>>>>>>>>>>> toolbar.setBackCommand(backCommand);
>>>>>>>>>>>> ....
>>>>>>>>>>>> ....
>>>>>>>>>>>>
>>>>>>>>>>>> What I get is that when the second dialog is displayed (full
>>>>>>>>>>>> screen) and I would click the back button, it is the same I would
>>>>>>>>>>>> click the
>>>>>>>>>>>> back button on the form, so the previous form is shown back while
>>>>>>>>>>>> I want to
>>>>>>>>>>>> stay on the current form with the first dialog displayed.
>>>>>>>>>>>> I just wanted to dispose the second dialog to go back to the
>>>>>>>>>>>> previous dialog, not the previous form.
>>>>>>>>>>>>
>>>>>>>>>>>> What's wrong?
>>>>>>>>>>>>
>>>>>>>>>>>> Il giorno martedì 12 gennaio 2021 alle 03:41:51 UTC+1 Shai
>>>>>>>>>>>> Almog ha scritto:
>>>>>>>>>>>>
>>>>>>>>>>>>> You can re-show the dialog with animation disabled after the
>>>>>>>>>>>>> on show event. You can store state in client properties to track
>>>>>>>>>>>>> whether a
>>>>>>>>>>>>> form has a currently showing dialog.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Monday, January 11, 2021 at 8:53:01 PM UTC+2 P5music wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In my CodenameOne app it can happens that a InteractionDialog
>>>>>>>>>>>>>> is displayed and from there a form is called with text inside,
>>>>>>>>>>>>>> arranged in
>>>>>>>>>>>>>> three areas.
>>>>>>>>>>>>>> The dialog is a subclass of InteractionDialog in fact
>>>>>>>>>>>>>> (CommandDialog), that avoids showing a form for itself.
>>>>>>>>>>>>>> When the second form is called from the CommandDialog it
>>>>>>>>>>>>>> works but when the showBack command is invoked the dialog
>>>>>>>>>>>>>> disappears.
>>>>>>>>>>>>>> I say "disappears" because when the form disposes itself the
>>>>>>>>>>>>>> previous form is displayed in its previous state, including the
>>>>>>>>>>>>>> BrowserComponent content and the CommandDialog, then the dialog
>>>>>>>>>>>>>> disappears.
>>>>>>>>>>>>>> So it seems that the disappearing could be avoided.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can open another InteractionDialog, but I would like to
>>>>>>>>>>>>>> know what's happening, and if there is the possibility to call a
>>>>>>>>>>>>>> form and
>>>>>>>>>>>>>> then coming back to the CommandDialog.
>>>>>>>>>>>>>> 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/ad54a2b4-9ab9-4075-94bc-1c54b12c00c5n%40googlegroups.com.
