Order of Execution

[tmiranda]

I have a question regarding widget execution order within a listener when there is an OptionsMenu thrown in the mix. My situation is as follows: (See attached screenshot)

- I have a listener for Delete that executes a few action widgets (to set some variables), then displays an OptionsMenu (it's a reference to the OptionsMenu widget if that matters), then tests some variables that are set by the OptionsMenu processing.

- When I look at the DebugLog statements I have peppered in there it seems as if the tests (located after the OptionsMenu widget) happen before the OptionsWidget chain has completed. The STV behavior is also consistent with this odd situation.

What I'm doing is displaying an options menu allowing a user to take some action on a group of shows and then after the options menu has closed checking to see if any files were deleted. If shows were deleted I refresh the screen and make sure the focus goes to where it should be.

The problem is that no deleted shows are detected UNLESS I press delete AGAIN (which displays the options menu a second time) and then close the options menu THEN the deleted shows are detected.

What am I doing wrong? I've been staring at this issue for 2 days now.

[GKusnick]

I do this sort of thing all the time and it works as expected for me.

Listener
  var = false
  DebugLog("Before OptionsMenu")
  OptionsMenu
    ...
  DebugLog("After OptionsMenu")
  If var
    ...

The "After OptionsMenu" message does not appear in the console window, and the following If does not execute, until the OptionsMenu has been dismissed.

You example is considerably more complex than this, of course. Among other things, I notice that there's a reference to the After code from elsewhere (but your screenshot doesn't show where). So the first thing I'd check in your case is whether there's another path to that code that you're not accounting for.

When in doubt, try simplifying your example down to the the minimum code that displays the unexpected behavior. That usually helps clarify which statements are responsible (because when you delete them, the bug goes away).

[tmiranda]

I expect the same behavior, but something odd is happening.

Thanks for confirming what I hoped was true. Now if I could only find out where the Gremlin is......

[tmiranda]

I'm still stumped by this. Everything I see indicates that the widgets are getting executed out of order. Take the following excerpt from the debug log:

Thu 2/11 18:00:03.335 [AWT-EventQueue-0@79e304] Group Focus Changed
Thu 2/11 18:00:04.110 [AWT-EventQueue-0@79e304] TVED: Multiple Episodes in Group listener.
Thu 2/11 18:00:04.111 [AWT-EventQueue-0@79e304] processOptionsMenu optionsMenu=default:BASE-59014|OptionsMenu:Ask Delete ALL
Thu 2/11 18:00:05.847 [AWT-EventQueue-0@79e304] TVED: Size ShowsBeforeAction and TVEDeleted = 4:0
Thu 2/11 18:00:05.847 [AWT-EventQueue-0@79e304] processOptionsMenu optionsMenu=default:BASE-59023|OptionsMenu:Confirm Delete ALL
Thu 2/11 18:00:07.663 [AWT-EventQueue-0@79e304] processOptionsMenu optionsMenu=default:BASE-59040|OptionsMenu:Show Deletion Progress
Thu 2/11 18:00:08.817 [ReProcessHook@12be5f0] TVED: INCREMENTING.

The second line that starts with TVED: in the code (where I print ShowsBeforeAction and TVEDeleted) comes AFTER the third line that starts with TVED: (where I print INCREMENTING) My code is not working because a variable that should have been incremented is not.

I've checked Studio many times; the widgets are in the correct order. In the attached .jpg the highlighted widget is a reference to the code that does the checking and the widget just before it is a reference to the code that does the incrementing.

I really don't know what else to try at this point. I really hope it is something very obvious that I am overlooking, but I do not see what it could be. Suggestions welcome.

[tmiranda]

Oops, here is the .jpg

[GKusnick]

If you're not making any headway debugging this example, try a different approach. Start with a small test case, just a few lines, to see if that works as expected. Then gradually build up to something resembling your real code to see at what point it stops working.

[PLUCKYHD]

played with an IDE at all yet Tom? I have better luck executing long codes like this in native java as they are just easier to code and check in an IDE IMHO. I know that doesn't help your current situation or the question you asked just thought I would throw my 2 cents.

[Opus4]

We are not seeing the complete picture from the code snippets posted, but I can make a guess based on the log snippet that you are calling CloseOptionsMenu(), then closing & opening more options menus, then finally expecting it to return to the code below the first options menu in the screen cap.

When you call CloseOptionsMenu, you are saying that the options menu widget is done executing & to continue with the code that comes after it. Either do all of this as a series of options menus that remain on the screen until they are all done, then call CloseOptionsMenu() however many times you need, or else rearrange your code so that the code you want to execute last is done somewhere else after closing that last options menu.

- Andy

[tmiranda]

Originally Posted by Opus4

We are not seeing the complete picture from the code snippets posted, but I can make a guess based on the log snippet that you are calling CloseOptionsMenu(), then closing & opening more options menus, then finally expecting it to return to the code below the first options menu in the screen cap.

When you call CloseOptionsMenu, you are saying that the options menu widget is done executing & to continue with the code that comes after it. Either do all of this as a series of options menus that remain on the screen until they are all done, then call CloseOptionsMenu() however many times you need, or else rearrange your code so that the code you want to execute last is done somewhere else after closing that last options menu.

- Andy

This is exactly what I am doing and probably explains my problem. I'll have to verify it, but I suspect you have nailed it Andy - Thank you!

I open one Options Menu, close it, open another, close it, and maybe open and close a third options menu. I did a lot of debugging and found out that the action widgets started executing after the first CloseOptionsMenu().

(I'm actually referring to the malore menu code that confirms if a user really wants to delete all recordings. If the user chooses yes, it closes the options menu and puts up another asking if you really want to delete them all. Finally, if there is an error deleting the recording it puts up a third options menu alerting the user of the problem.)

I'll try this out and post results when I can. I'm going to Daytona Saturday and Sunday (I live an hour from the track and go every year) so it may not be for a few days depending on how much beer I drink

[Opus4]

Originally Posted by tmiranda

(I'm actually referring to the malore menu code that confirms if a user really wants to delete all recordings. If the user chooses yes, it closes the options menu and puts up another asking if you really want to delete them all. Finally, if there is an error deleting the recording it puts up a third options menu alerting the user of the problem.)

If you see a problem like this in the original code, let me know & I'll look into it.

- Andy

[tmiranda]

The original code is fine. It's me trying to reuse the original code in ways it was not designed for. In the original code the reference to the Options Menu is always the last item in the action chain. In my code I try to stick the reference in the middle of an action chain which I believe is causing the problem.

Thanks for all your help Andy.

[tmiranda]

I can verify that this was the problem, thank you Andy.

So the lesson for me is, if you have code that looks like this:

Action
Action
OptionsMenu
Action
Action

The Action after the OptionsMenu will execute immediately after the FIRST CloseOptionsMenu() is processed.

Now off to Daytona

Tom

[GKusnick]

Originally Posted by tmiranda

The Action after the OptionsMenu will execute immediately after the FIRST CloseOptionsMenu() is processed.

Actually, it's the CloseOptionsMenu() call that closes that particuler OptionsMenu, not necessarily the first call. As Andy said, CloseOptionsMenu() closes the topmost menu currently on screen (i.e. the one most recently opened) and resumes execution following that menu's widget. So if you strictly nest the open/close calls as shown below, so that the menus stack up on screen, then it will be the last call that closes the first menu and resumes execution following that widget.

OptionsMenu1
  ...
  OptionsMenu2
    ...
    OptionsMenu3
      ...
      CloseOptionsMenu()  closes OptionsMenu3
    CloseOptionsMenu()    closes OptionsMenu2
  CloseOptionsMenu()      closes OptionsMenu1
execution resumes here after the third call to CloseOptionsMenu()

[tmiranda]

Greg,

Yes, that is how I solved the problem but my code was a little different and not as straight forward. My code looked like this:

Action 1
   OptionsMenu 1
   CloseOptionsMenu 1

   OptionsMenu 2
   CloseOptionsMenu 2
 
   OptionsMenu 3
   CloseOptionsMenu 3

Action 2

In this case Action 2 executes as soon as CloseOptionsMenu 1 is processed, even though OptionsMenu 2 and OptionsMenu 3 are children of Action 1. I assumed (incorrectly) that Action 2 would execute after CloseOptionsMenu 3.

This is very odd behavior and programatically unlike anything else I've seen.

[GKusnick]

Actually your code was more like this:

OptionsMenu 1
  CloseOptionsMenu 1       resumes Action 1
  OptionsMenu 2
    CloseOptionsMenu 2     resumes Action 2
    OptionsMenu 3
      CloseOptionsMenu 3   resumes Action 3
    Action 3
  Action 2
Action 1

Nesting matters in terms of what code gets executed next.

Originally Posted by tmiranda

This is very odd behavior and programatically unlike anything else I've seen.

Actually we see this sort of thing all the time with hooks, which get executed out of lexical sequence when their triggering events fire. So think of the code following each OptionsMenu as being on a kind of implicit AfterMenuUnload hook that gets fired from within CloseOptionsMenu.