Posted: March 08 2004 at 16:07 | IP Logged

When I execute macro via a ph_macro in a formula before it executes the next line of the macro I'm in it seems to execute first then the macro called by ph_macro. Normally, I would use the Macro option where "Immediate" or "Post" can be set but I want to have a selected macro execute as in:

ph_macro(case(condition when 1 then "MACRO1" when 2 then "MACRO2".... <SCRIPT language=javascript>postamble();

Can I control this some way?

Posted: March 08 2004 at 16:12 | IP Logged

I seem to be spiralling out of the PH community. The strange <SCRIPT lang.... used to come up after my signature but now it pops up in the middle of my posts.

I will get a dead chicken and some bats wings and try to exorcise this. <SCRIPT language=javascript>postamble();

Posted: March 08 2004 at 17:19 | IP Logged

Pat,

If the ph_macro is being called in a formula that is "Immediate" rather than "Post", then it should execute before the next macro line executes.  I ran a couple of tests and verified using the PowerHome Status eventlog and all appears as it should be.

Now if the ph_macro appears in a formula that is "Post", then the formula is posted to the execution queue and is executed the first chance it gets.  This would be after the current macro terminates, launches an input or message box, or Waits.  A "Delay" command will not allow the execution queue to be processed.

Are you wanting the macro to execute immediately or after the current macro is executed?  If you want the macro to execute immediately, then your statement above should be fine, just make sure that the Formula is "Immediate".

If you want the macro to execute after the currently executing macro, its a little trickier.  You'll still want the formula to be "Immediate" but instead of just a ph_macro, you'll want to use a ph_postformula with the ph_macro inside like this:

ph_postformula('ph_macro("' + case(condition when 1 then "MACRO1" when 2 then "MACRO2") + '")')

What will happen above is that the "case" statement will be evaluated when the current macro is executed.  This is probably what you want since the "conditions" probably won't apply if the whole formula was posted.  The resulting string 'ph_macro("WHATEVER THE CASE STATEMENT RETURNED")' will then be posted to the execution queue.

Probably more that you wanted to know and not sure if I answered your question .

Dave.

Posted: March 08 2004 at 17:21 | IP Logged

If you figure out whats causing the <SCRIPT language=javasc..., let me know .  Im curious myself whats been causing it. 

Ive been thinking I should add it to all my posts just so you won't feel so special.

Dave.

Posted: March 09 2004 at 14:09 | IP Logged

Pat,

Your observations are correct.  Whenever a Message Box or Input Box command is processed, the macro info is stored within the message/input box and the macro is terminated.  This allows other macros or items in the execution queue to be processed.  When the message/input box is closed, the macro is reloaded into the execution queue and resumes where it left off.

Essentially, message and input boxes do not hang execution queue processing.  For all practical purposes, a macro is finished when it opens an input/message box.  When the box is closed (or times out), the macro is restarted where it left off.

Dave.

Posted: March 09 2004 at 16:47 | IP Logged

Dave,

I can see the sense of not holding up the execution queue when a message or input box is waiting for input.

From what you said it seems that the ph_macro launches the called macro and then proceeds to the next statement of the macro that the ph_macro resides in. Is this correct? If it is how do I get the calling macro (the one with the ph_macro in the formula) to launch the called macro and then wait until the called macro completes?

I suppose a "wait" or "delay" would hold it up but I'd waste a lot of user time that way.

Posted: March 09 2004 at 17:07 | IP Logged

Pat,

As long as the ph_macro is called in an "Immediate" formula and you don't have any message/input boxes or wait commands, then the calling macro WILL wait for the called macro to complete before continuing execution.  You should be able to verify this using just user messages in your macros. 

Definately don't try to use delay or wait because you shouldn't have to. 

If you have a particular sample that this doesnt seem to work for, please send it to me or post it here so I can test it.

HTH,

Dave.

Posted: March 09 2004 at 17:48 | IP Logged

Dave,

I guess I'm having problems because I do have message/input boxes in both the calling and called macros. I generally design my programs with a mainline macro and lots of called macros. This usually gives me a lot of flexibility for reusable macros and ease of testing via small chunks of code.

I'd really like to stay with this format.

Would it make any sense to let the macros do some some handshaking like:

mainmacro: glbl=0; lbl="top"; call submacro; wait 1; goto(if(glbl=0,"top","next"); ...rest of mainmacro ...

submacro: do this; do that; glbl=1; done;

or does this get me into more trouble with the way PH wants work?

Posted: March 09 2004 at 17:50 | IP Logged

Oops! I meant

mainmacro: glbl=0; call submacro; lbl="top"; wait 1; goto(if(glbl=0,"top","next"); ...rest of mainmacro ...

submacro: do this; do that; glbl=1; done;

Posted: March 09 2004 at 20:50 | IP Logged

Pat,

You raise a very interesting question and you've got a valid point...How do you make the main macro wait until the submacro is truly finished?

Ive turned it over and over in my head and can't really think of a better way than you describe.  Basically use a global var as a flag for whether the submacro is finished and have the main macro loop using a Wait command (be sure and use a wait and not a delay...the delay command does not allow control to be returned to the execution queue) until the global var is changed.

I wish there was a better way but I think you've already come up with it.

PowerHome used to work they way you expected...a message/input box halted all execution until the box was closed.  I changed it several versions back as this was causing problems because a macro would run and I would be at work and my whole system would be hung until I got home.

If you're interested, I could look at adding a couple of new macro commands with message/input boxes that will wait until closed.  That way you could have a choice between the current boxes or ones that hang the system until closed.

Nothing wrong with your programming style , I do the same thing...It's definately the way to go.

Let me know if you're interested in having new message/input boxes or if you're just as happy using the "flag and wait" method.

Dave.

Posted: March 10 2004 at 18:44 | IP Logged

Dave,

the "flag and wait" works fine for what I'm doing. It does add a few more lines to my macros everytime I call a macro. For a mainline macro it can get a little cluttered but its workable.

I'm not sure if the optional message/input boxes would work. I think that a macro command with a wait/nowait or ph_macro(s,n) that allows waiting until the called macro finishes would do it.

Posted: March 10 2004 at 23:46 | IP Logged

Pat,

Ive been thinking about the problem and have come to the conclusion that the optional message/input boxes that don't give control back to the execution queue is probably not the way to go and have been thinking about implementing exactly what you propose.

Ive been going over it in depth, and I think what Im going to do is create a new Macro command that allows you to launch what Im going to call a SubMacro. 

Its rather complicated to explain the inner workings of PowerHome, but I believe I can do this without too much trouble.  It will mean that a SubMacro however won't get its own set of internal variables but will instead inherit the calling macro's variables.  I'll have to create a couple of extra internal variable structures to track the calling macro/line to submacro/line to submacro/line, etc. to keep track of the levels as they are  traversed.

Dave.

Posted: March 12 2004 at 16:20 | IP Logged

Pat,

Ok, Ive gone through and Ive added the functionality.  It works great!!

When I say the submacros won't have their own variables, I mean they won't have their own unique copy.  A submacro will inherit the calling macro's variables.  This refers mainly to the local and temp variables.  I had to do it this way because there would be no way for me store the calling macro's variables in situations where you have a macro calling a submacro calling a submacro calling a submacro, etc. since the memory structure is so complicated.

I know what you mean about the pulse effect.  Thats exactly what I got when verifying the functionality.

Dave.

Posted: March 14 2004 at 22:38 | IP Logged

Dave,

I see that you've been busy while I was away for a few days. Let me be the first to thank you for adding this feature. Will there be an entirely new macro with a wait or will the existing macros have an option to wait?

Also, you said you experienced the pulse effect. I'm curious to know if you had any difficulty typing into input boxes in the called macro. I did because of the way I implemented the functionality.

Pat <SCRIPT language=javascript>postamble();

Posted: March 22 2004 at 17:23 | IP Logged

Pat,

Sorry to take so long to respond...missed your message.

Not a new macro, just a new macro command called "Submacro" instead of macro.  It doesnt have an immediate or post (it's always immediate) and instead of a dropdown ID list like the macro command, you can have a formula that evaluates to a macro ID in the Sendkeys field.

As I recall, I didn't have too much trouble typing in the input boxes.  Occasionally a key was missed if it was typed right when the pulse effect was happening.

I'll be putting out a beta soon with this latest functionality as well as some more implemented.

Dave.