Archived Boards > WinBatch Dynamic Dialogs

Invoke a Dialog Callback Procedure From Within a Dialog Callback Procedure?

(1/6) > >>

USMuscle:
I wrote 3 dialog callback procedures, all of which work as designed when run by themselves. I would like to run two of them as "subroutines", for lack of a better term, from within a "main" dialog. I've discovered you can't put a callback procedure inside another one, and that you also can't make a GoSub for the auxiliary callback procedures because the main callback procedure can't "see" anything outside of its function. Is there some other way I can accomplish this? If it helps, the reason I need this is:

The main dialog contains a mix of editboxes people need to fill out and and itemboxes from which to make selections. I want the people to be able to open other dialog boxes to perform functions related to the main dialog box. I am aware that you can't pass variables between functions, but I have devised an alternative method for that which works just fine. So, I just need a way to have the main dialog be able to open the two other dialogs, both of which also have callback procedures in them.

td:
All you need to do is change your main dialog callback to a '#DefineSubroutine' instead of a '#DefineFunction' so it will have caller scope.  This will allow the 'Dialog' function for your child dialog template see the template variables.  Or you can place the child dialog templates directly in the user-defined-function so that the temple variables have function scope.   

Any user-defined-functions(UDF) and user-defined-subroutines(UDS) can be called by any other UDF or UDS as long as it has been defined before it is called and no UDF or UDS can be defined inside another UDF or UDS.

USMuscle:
Thank you VERY much! Not sure if I used the syntax you had in mind for "calling" the child subroutine, but I basically defined both Subroutines, then "nested" the Child Dialog statements within the Parent Subroutine, kind of like this:

#DefineSubroutine Child1.........
....................
....................
#EndSubroutine

#DefineSubroutine Parent.........
....................
...................
     Case [Control Number for Button]
     [Child Dialog lines]
     [Child Dialog lines]

#EndSubroutine

Parent Dialog
[Parent Dialog lines]
[Parent Dialog Lines]

Sorry so cryptic, but basically the Parent Dialog displays when I run the script, and when I click the Button in the Parent Dialog, the Child Dialog pops up and everything works as expected. If you meant for me to use a different (better) syntax, I'm all ears.

One other benefit I noticed is that by making the Parent and Child both Subroutines instead of Functions, I can actually pass variables between the two Subroutines, which begs the question: For what purpose might I choose to make Functions instead of Subroutines, when Subroutines seem to offer more flexibility?

Thanks again, so, SO much! :)

td:
You needed to either use a subroutine or define the child template within the parent callback but you didn't need to to both.  Although, obviously,  you can do both.

Subroutines and functions both have their uses and benefits.  Functions have benefits relating to the software design principles of  maintainability, data encapsulation and reusability among other things.

USMuscle:
So are you saying I could have placed the Child dialog lines in a Label OUTSIDE of the Parent Subroutine, below the Parent dialog lines, and simply used a GoSub from within the Parent Subroutine? If that's the case, could I then place the defined Child Subroutine below the Parent dialog lines, directly above the Child dialog lines, or must I leave the defined Child Subroutine ABOVE the Parent Subroutine?

Navigation

[0] Message Index

[#] Next page