nested open window

[davidk64]

call first

sub first
   call second
   open "first" for dialog_modal as #firstWnd
   print "opened first"
   wait
end sub

sub second
   button #secondWnd.button, "Exit", closeSecond, UL, 10, 10
   open "second" for dialog_modal as #secondWnd
   #secondWnd "trapclose closeSecond"
   wait
end sub

sub closeSecond handle$
   close #secondWnd
end sub



When I run this and press "Exit" in second dialog window I'd like it to close second window and open first window. I read about GOSUB/RETURN but that only for branch labels?

[tsh73]

I got something working, but with a branch handler
call first

sub first
   call second
       print "after call second"
   open "first" for dialog_modal as #firstWnd
   #firstWnd "trapclose closeAny"
       print "opened first"
   wait
end sub

sub second
   button #secondWnd.button, "Exit", [closeSecond], UL, 10, 10
   open "second" for dialog_modal as #secondWnd
   #secondWnd "trapclose [closeSecond]"
   wait

   [closeSecond]
       close #secondWnd
end sub

sub closeAny handle$
   close #handle$
end sub



[Rod]

Your probably going to have more questions. The thing about WAIT inside a Sub is that you need to be really sure all event handlers are Subs themselves. Positioning the second window is next since the dialog opens at the mouse click.

nomainwin
call second

sub first
   open "first" for dialog_modal as #firstWnd
   #firstWnd "trapclose closefirst"
   wait
end sub

sub second
   button #secondWnd.button, "Exit", closeSecond, UL, 10, 10
   open "second" for dialog_modal as #secondWnd
   #secondWnd "trapclose closeSecond"
   wait
end sub

sub closefirst handle$
   close #firstWnd
   end
end sub

sub closeSecond handle$
   close #secondWnd
   call first
end sub


[davidk64]

Thanks Ant and Rod!

Yes after much head scratching I ended up calling the first sub in the second sub close sub as well. But it's not what my programming background expects. I'm used to code after a sub call executing when the called sub completes. There must be something different about the way JB is implemented.

Here's a theory why Ant's method works. In my attempt there are two levels of subs below the original call of sub second. While in Ant's there is only one because the close second is handled by branch label within sub second. So perhaps the JB implementation only supports returning from one level of nested sub not two.

All good fun.

[Rod]

?…. No a Sub is a Sub, they are never really “nested”. An event is an event, a button click or a close click, each must have a handler. They can share a handler. You can also know in the handler who called it by parsing the handle$.

[tsh73]

>> So perhaps the JB implementation only supports returning from one level of nested sub not two.

Nesting procedure calls, even recursion, works in JB - more or less OK

Probably something with event handler.
In your
sub second
   button #secondWnd.button, "Exit", closeSecond, UL, 10, 10
   open "second" for dialog_modal as #secondWnd
   #secondWnd "trapclose closeSecond"
   wait
end sub
it never actually hits "end sub"
So from program point of view, you never return
(== properly return, with all stack dances involved)
from that sub.

[davidk64]

Aug 10, 2022 8:06:40 GMT tsh73 said:

>> So perhaps the JB implementation only supports returning from one level of nested sub not two.

Nesting procedure calls, even recursion, works in JB - more or less OK

Probably something with event handler.
In your
sub second
   button #secondWnd.button, "Exit", closeSecond, UL, 10, 10
   open "second" for dialog_modal as #secondWnd
   #secondWnd "trapclose closeSecond"
   wait
end sub
it never actually hits "end sub"
So from program point of view, you never return
(== properly return, with all stack dances involved)
from that sub.

Okay that makes sense. I close the second window and my expectation is that the second window wait would "disappear" but for some reason the JB implementation leaves the program still waiting for an event on the closed second window. Sounds like a bug to me!

[Rod]

Not really, the program is doing exactly what you asked it to do WAIT. It sits waiting for the next event to fire. Then it jumps to the next handler.

If you want to return immediately from a sub you would not put the WAIT. But in that case it would not wait for the user input it would just return and move on.

Normally short subs just return immediately. But they will return to a loop or a WAIT. They are all just tools to manage program flow.

The other command you need to be aware of is SCAN. This allows you to react to an event inside a loop. Once the sub handler ends you are right back at the SCAN. If the code is idle it will just be sitting at a WAIT statement.

Old BASIC used to loop and loop scanning for interrupts, that does not happen now, we issue events and wait for them to fire so your code will most often be sitting idle. (in the context of a GUI)

[davidk64]

We'll have to agree to disagree on that one Rod! If I open a window and ask the program to wait for user input on the window and then close the window I think it is reasonable to expect that the wait statement stops at that point. What user input could the program be waiting for on a closed window?

[tsh73]

We don't have "program per window" in JB
Program is single
so WAIT has no idea if it is related to window or not

[Rod]

Lets try again, this is your original program tweaked to use one WAIT statement so that you can better understand the program flow. Since no Sub has a WAIT the program will always return to the original WAIT and be ready to react to any user input. The issue is about program flow, follow the program flow in my code and your original code.

nomainwin
call second
wait

sub first
   open "first" for dialog_modal as #firstWnd
   #firstWnd "trapclose closefirst"
end sub

sub second
   button #secondWnd.button, "Exit", closeSecond, UL, 10, 10
   open "second" for dialog_modal as #secondWnd
   #secondWnd "trapclose closeSecond"
end sub

sub closeSecond handle$
   close #secondWnd
   call first
end sub

sub closefirst handle$
   close #firstWnd
   end
end sub


[Rod]

In your original code this is how the program flow goes.

You call first, it jumps to that sub. You immediately call second, it jumps to that sub. Note that nothing has been actioned in first. You simply immediately jump to second.

In second the window is established and two events are set up. Now you wait for user interaction.

The user clicks and the closesecond sub handler is called. It closes the second window and returns to the wait. Since you have no other events set up and since the window is closed the program just sits and waits as instructed.

What should happen is that as well as closing the second window you should open the first and set up its events. We never get there.

I have coded two examples where we do keep the program flowing.

As said it’s about program flow and understanding what WAIT really means.

[davidk64]

call first

sub first
   call second
   open "first" for dialog_modal as #firstWnd
   print "opened first"
   wait
end sub

sub second
   button #secondWnd.button, "Exit", closeAny, UL, 10, 10
   button #thirdWnd.button, "Exit", closeAny, UL, 10, 10
   open "second" for dialog as #secondWnd
   open "third" for dialog as #thirdWnd
   #secondWnd "trapclose closeAny"
   #thirdWnd "trapclose closeAny"
   wait
end sub

sub closeAny handle$
   close #handle$
end sub


Thanks Rod and Ant for persevering! The penny has finally dropped. I hope the code above demonstrates my understanding. When you exit one of the windows two and three the program is still in wait mode as you would want since there is another window open. Ant's solution with branch label works because when the program flow moves to the branch label it steps over the wait statement so the program is no longer waiting in second window and the end sub of second sub is reached allowing return to first sub post second sub call.

I'm glad I asked this question since I have learnt a lot from your answers!

[jarych]

Just the title by itself makes more sense to use than some of the description and examples shown in the topic discussion. NESTING of windows is fine if you are careful. Putting a window to be opened in a subroutine and then making the program WAIT inside a subroutine is just a bad idea.

I kind of like this arrangement:

------------------------------------------------------------------------
an event control to [anotherwindow]
an event control to [yetmorewindow]
open a windows
wait

close main windows
wait

END

[anotherwindow]
wait

[yetmorewindow]
wait
-------------------------------------------------------------------------


But the arrangement does not need to be like that. The two branches can come BEFORE the END statement. I am not sure if that makes for 'nesting' for not.

[Rod]

Nesting windows is possible. I would say it is easier to manage a single window. You can change the look of the window by hiding and showing controls.