| Author |
|
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 25 2007 at 12:09 | IP Logged
|
|
|
Hi - I was doing some programming today, and had a few questions I couldn't answer from the docs…
1) What's the proper argument to the Submacro command? I'm using a formula, seems to work, but everytime the submacro finishes, I get a log entry:
Macro: Submacro 0 Executed.
Which seems odd (and clutters the log). So I wonder if I'm doing things right.
2) How do I pass information from a submacro back to the calling macro? Is there a way to do something in the formula field of the Submacro command like
[TEMP1] = ph_macroparm(...)
?
Right now I'm setting a global variable in the submacro, which seems a bit clumsy. It works because PH is executing one command at a time, but I really should be using a variable with limited scope. I tried setting a [TEMP], but it appears that the system uses the TEMPs for it's own purposes in the calling macro.
Thanks!
/j
Edited by jeffw_00 - December 25 2007 at 18:22
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 25 2007 at 12:18 | IP Logged
|
|
|
Until Dave chimes in, this is what I've found here on the forum...
The Sub Macro command expects the ID of the macro to call in the formula field.
A SubMacro won't get its own set of internal variables but will instead inherit the calling macro's variables.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 25 2007 at 12:19 | IP Logged
|
|
|
Thanks Tony, except
Putting a formula in the formula field worked fine.
I'm interested in how to RETURN a value BACK to the calling macro.
8-}
Happy Holidays
/j
Edited by jeffw_00 - December 25 2007 at 12:20
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 25 2007 at 12:22 | IP Logged
|
|
|
Sure, if the formula evaluates to a macro name. 
Just use one of the primary macro's TEMP or LOCAL variables since they are shared.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 25 2007 at 12:25 | IP Logged
|
|
|
(sigh).. I'm not explaining myself well. Let me try again.
I put ph_macroparm("<macroname>",parameters...) in the Formula field of the submacro (so I could pass down parameters). It worked fine.
LOCAL parameters are passed DOWN by default. If I modify one in the submacro, I'm not sure the modified value is passed back (are you?)
I tried TEMP parameters but did not get the desired result, the value of the TEMP parameter at the calling macro level was not the same as what it was set to in the submacro, suggesting that the TEMP is not passed up.
thanks though 8-}
/j
Edited by jeffw_00 - December 25 2007 at 12:28
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 25 2007 at 22:00 | IP Logged
|
|
|
I just verified that changes to LOCAL's in a submacro are shown in the calling macro.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 25 2007 at 22:39 | IP Logged
|
|
|
Hi Tony - I thought LOCAL1 - LOCAL5 were set by the calling macro. Are you suggesting that the submacro over-write one of them? What LOCALn did you test with?
and though I appreciate the effort, and believe that it works as you suggest, I'd like to hear from Dave to see if that's the recommended way, as it doesn't seem clean to me to be modifying parameters that are pushed down, I'm wondering if there's a cleaner way
thanks though
/j
Edited by jeffw_00 - December 25 2007 at 22:40
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 25 2007 at 23:10 | IP Logged
|
|
|
I set LOCAL1 in the main macro, modified it in the submacro, and then displayed it (via a user message) back at the main level.
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: December 26 2007 at 08:36 | IP Logged
|
|
|
Jeff,
You always ask for programmatic help, get it from lots of the great, long time, program writing people here, and more often than not your reply to their kindly and freely given help/advice is "thanks, but I'll just wait on Dave". If you only want assistance from Dave, which is seems you do, then just email him and, when you get a working macro to share, post it. Sorry for the apparent rant, but I've seen this repeatedly in your posts. I know if I was the one giving advice, I would become quickly frustrated with this. Especially when Dave chimes in with "so and so has you covered" etc.
Edited by cmhardwick - December 26 2007 at 08:38
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 26 2007 at 09:27 | IP Logged
|
|
|
ummm - I'm sorry if it comes across that way. I will (and have) taken help gratefully from anyone who posts.
However, when the answers are "you can't do that" I admit that I wait for Dave before I give up (and you must admit, he's often had better answers 8-]). In this case, I'm sure that using [LOCALx] works (just as using a global works) but, for reasons I've tried to explain, both seem dirty and I'm not convinced there -isn't- a better way.
Sorry it's come across negatively, it's not my intent
/j
Edited by jeffw_00 - December 26 2007 at 09:27
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 27 2007 at 11:41 | IP Logged
|
|
|
Hi - It was stated (I think even by Dave) that calling a submacro suspends the calling macro, but I'm not seeing that experimentally. I have a ph_macro("<macro>") as the argument to the submacro command, but the next command gets executed as soon as the submacro does a "Wait". That may be expected behavior but I thought i should mention...
/j
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 27 2007 at 18:33 | IP Logged
|
|
|
A WAIT suspends the flow to let other actions happen, so, you should use DELAY if you don't want that.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 27 2007 at 18:40 | IP Logged
|
|
|
Yeah - doesn't surprise me, but didn't know it un-suspended the calling macro until I tried it.
Submacros aren't quite subroutines 8-}
So I worked around it by absorbing the submacro (which was all of 2 lines) into the calling routine and posted it earlier today under SEND_INSTEON. It modifies LOCAL5 and works fine.
Modifying LOCALs still seems 'dirty' to me though - LOCALs should be passed from calling routines and not modified in the called routine, I think (just my snobbiness, I guess). I would have thought TEMPs are the variables you could modify with abandon, but they seem to be set to meaningful values so I'm afraid to modify them because I don't know what's using them.
thanks
/j
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 27 2007 at 19:53 | IP Logged
|
|
|
So I think I answered my own question.
Use LOCAL6 - LOCAL10. These are not passed down from above so they're fair game.
Love that PH.
8-}
/j
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 27 2007 at 22:34 | IP Logged
|
|
|
Where there's a will...
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 27 2007 at 23:51 | IP Logged
|
|
|
Just wanted to post a quick note...I'll be catching up on forum messages most likely tomorrow and give everyone an update on the recovery effort.
In the meantime...using the ph_macroparm function as the formula for a Sub Macro command will not work (properly). The Sub Macro command expects the formula to evaluate to the ID of a macro. When you use the ph_macroparm function as the formula, the macro specified in the ph_macroparm function will indeed execute, but not as a Sub Macro. It will execute just as if the macro command had been of type Formula, Immediate. When the macro in the ph_macroparm function is complete, the ph_macroparm function will return a "0" value. PowerHome will then attempt to launch a macro with an ID of "0" as a Sub Macro. Most likely, this does not exist so the Sub Macro never actually executes.
A macro will execute (and hold the execution queue) until it either ends, waits, or opens a message or input box. When any of these conditions occur, control is returned to the execution queue. If it didnt, PowerHome would appear to be hung until the wait timeout has passed or the message or input box is closed (probably not the desired result). It should be noted that the "Delay" command does not return control to the execution queue (so Delays, should be relatively short...typically less than a second).
This behaviour is why the "Sub Macro" command exists. It doesnt have the same "return to the execution queue" type of behaviour. Say you have a macro. This macro calls another macro using the traditional "Macro" command, ph_macro, or ph_macroparm type functions. The first macro's execution is suspended and control is transferred to the called macro. This macro executes and encounters a message box command. As soon as the message box is displayed, the second macro is terminated (actually suspended) and control is returned to the first macro which will then continue on. When the message box from the second macro is closed, the second macro data is added to the end of the execution queue. When this data becomes active, the second macro is reloaded with all of its current variables restored and execution continues at the statement after the message box. When the second macro is first launched by the first macro, it inherited the [TEMP] variables of the first macro and got a fresh set of [LOCAL] variables. Any [TEMP] or [LOCAL] variables that are modified by the second macro ARE NOT passed back up to the first macro when the second macro terminates or waits.
When a Sub Macro is called, it's called as if it's actually a part or extension of the first macro. ALL of the [LOCAL] and [TEMP] variables in the first macro are present in the second macro and any changes made to the variables in the Sub Macro will be visible in the first macro when the second macro terminates because the Sub Macro is treated as if it is a part of the first macro. In our previous example, the first macro now calls the second macro as a Sub Macro. When the second macro hits the message command, control is NOT returned to the first macro (the second macro is an extension of the first macro) and control instead goes back to the execution queue. When the message box is closed, the sub macro regains control and when it finally terminates, control then goes back to the first macro to the line following the Sub Macro complete with any changes made to [LOCAL] and [TEMP] variables by the Sub Macro.
The distinction between [LOCAL] and [TEMP] variables have become blurred in recent versions. Originally, you had 3 types of system variables, [LOCAL], [TEMP], and [GLOBAL] (not to be confused with a database global variable...a [GLOBAL] system variable is stored in memory only). [GLOBAL] variables were easy and were just as implied...global. They could be changed and accessed anywhere. [TEMP] variables were unique to the macro or formula but could be passed down to another macro or formula...never passed up. [LOCAL] variables were unique to the particular macro or formula and every new macro or formula got a fresh set. With the advent of plugins and triggers that need to pass alot of data, the [LOCAL] always being a fresh set has changed somewhat. Since [TEMP] variables always could be inherited, these were the variables that were used to pass data to a called macro or formula from a trigger. Recently, we need to pass more data than is available for the [TEMP] variables so macros and formulas called from triggers (or plugins) can also inherit data in [LOCAL] variables.
Sooo, [TEMP] variables should always pass down, [LOCAL] variables will pass down sometimes. However, no variables will pass back up (except in the case of a Sub Macro).
PS...a great way to demonstate how a Sub Macro works is with a couple of small macros. Create a simple two line macro with Line 10 calling a sub macro and Line 20 a message box stating that this is macro 1. Create a second macro with a single line 10 that is a message box stating that this is macro 2. Execute macro 1. You should get a message box that states that this is macro 2. Move the message box around so you can see nothing is behind it. Click OK and you should get a message box stating that this is macro 1 showing that the first macro waited for the Sub macro to complete. Change Line 10 in the first macro from a Sub Macro to a standard Macro command. Execute the first macro. You'll see a message box appear stating that this is Macro 1. Move the message box to the side and you'll see a message box stating that this is Macro 2. What happened is that the second macro popped up it's message box and returned control to the first macro that then popped up it's message box on top of the second macro's message box showing that the first macro now does not wait for the second macro to complete.
HTH,
Dave.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 28 2007 at 09:45 | IP Logged
|
|
|
Hi Dave - as always, thanks for the detailed response. This explains all the behavior I was puzzling over, and clarifies a lot of things. I get that you can call a submacro without parameters because the parameters are passed by default.
I was surprised that I saw that some TEMP variables were "preset" (for example, TEMP1 was the ID of the calling macro). Are there TEMPs that I shouldn't change?
I think my problem was that I was trying to apply a different paradigm. I'm a zealot on maintainability of code so I never want to copy/paste. What I was trying to do was create clean subroutine calls. I think submacro can do this, but you would have to track all the variable/parameter usage implicitly (which you could document with comments).
As always, you've clarified a lot.
We should really start a Wiki or something, so that you never have to write this stuff more than once 8-}
Best Regards
/j
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 28 2007 at 10:21 | IP Logged
|
|
|
Quote:
| We should really start a Wiki or something, so that you never have to write this stuff more than once |
|
|
That's what the board's search function is for!
Also, when this doesn't get you what you want, you can use Google by adding "site:myx10.com" or "site:power-home.com" to your search.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: December 29 2007 at 11:25 | IP Logged
|
|
|
Hi Tony - it was an idle comment as I realized later I didn't want to make -more- work for Dave. And yes, it's all in the forum if you can find it. I was thinking, somewhat idealistically, that a Wiki had the advantage of organization. I hate to make Dave think he has to do a new manual some day when all the information is here in the forums. If we did a Wiki, it would have the advantage of being organized like a manual, and as each of these threads reached completion, we could encourage posters to put the 'ultimate' answer into the Wiki.
again, just an idealistic thought. Personally, every time one of my threads closes out I print it and keep it in a notebook for future reference. But even that is inefficient because usually all the information is in one or two posts of the thread.
/j
/j
Edited by jeffw_00 - December 29 2007 at 11:25
|
| Back to Top |
|
| |
TonyNo
Moderator Group
Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
|
| Posted: December 29 2007 at 13:19 | IP Logged
|
|
|
Trying to organize the info would be the trick.
Not sure what Dave uses on his server, but maybe he can find a Wiki package for it. I just looked around for one I could run, and came up dry.
Edited by TonyNo - February 04 2008 at 22:15
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: Returning data from a submacro...
