I never used "With Parameter" before, or Instance variables, but it seems to me that they behave "kinda" the same way?
So I am able to set a value to the "With Parameter" field in "Execute a Macro" and then in the sub-macro I just set the %TriggerValue% to use that value, for example my main macro:
My sub-macro:
My notification when I run the main macro:
But according to what I read about Instance variables, it seems that this can be done as well. The only "disadvantage" is that we need to add an extra action to set the instance variable, but it seems that they end up doing the same thing, with the advantage of using instance variables that we are able to see what the value represents (instance__myName, for example), as opposed to just seeing %TriggerValue%
Why is your value underneath "Who Call Me?" empty?
If you used something in the "With parameter" field and for the display text you used %TriggerValue%, shouldn't "Who Call Me?" also be shown? Because if you look at my OP, I used the word "tiago" and it's shown in the notification...
Oh you're right! I guess I read that, but didn't fully absorbed the information... sorry about that haha
So my OP is clear enough about how it works, right?
You set anything you want to "With parameter" and then you get that "anything" you put there, by using %TriggerValue" in the sub macro. Is it all it does?
Contrariwise -- to use an Instance variable to pass data to your sub-macro you need to know, and use, the name of the Instance variable the macro uses.
By passing a parameter and getting a result back, the sub-macro becomes a "black box" -- you know what it does (eg sums three numbers), know it wants as input (eg three, comma-delimited, numbers), you know what it returns (eg a single number). You don't know, you don't need to know, how it does any of that.
That makes the sub-macro more generally useful while allowing you to use "meaningful" variable names in your calling macros. One caller might be using prices, so it would have Local_price1, Local_price2, Local_price3. Another might be doing weights and have Local_grams1 etc.
But, all the time, your sub is using Local_n1, Local_n2, Local_n3 because, to it, they're just numbers to add together.
What I mean is that when you are editing the sub-macro a few days / weeks / months / years later, you can see what is being received by the main macro, instead of just %TriggerValue% which then forces you to go back to the main macro and dig until you find the Execute a Macro with the parameter. If the main macro has 50 "Execute a Macro" actions, then it's 50 actions you need to inspect as opposed to seeing %Variable%Local_myAge" for example. That's what I mean.
Correct. Also remember that %TriggerVaue% can return more than just an Execute a Macro parameter. If your macro is triggered by a hotkey, %TrigerValue% will contain which hotkey triggered it.
Anything within reason -- there's going to be a limit somewhere! If you are passing in a lot data or, especially, many variables munged into a single "blob", it's time to look at Instance variables again.
There is no one true answer -- it's very situational, with a heavy dollop of personal preference. So know that both methods are available and pick whichever works best for you at that point. Above all, document your decision in a comment at the top of the sub-macro so you can quickly find out the parameter format or the Instance variable names required the next time you use it.
But you also have %Trigger% which seems to do the exact same thing, right?
So I would guess it would be "good practice" to use those 2 for different scenarios, just to make it clearer what is being done?
For example if I want to know what tiggered that macro I would use just %Trigger%, so I would immediately see what that token is doing, and when I'm getting a value from another macro then I would use %TriggerValue%.
All of this to say that sometimes I feel that the choices made for certain tokens are not the best ones. For example it would make more sense to me that this would be called %ParameterValue%, which is what it's doing. Then %Trigger% would get what triggered the macro. This would be clearer to me.
And if %TriggerValue% can be used for other things, then each thing should be a specific token, instead of having a "generic" name that tries to do make different things.
My confusion from looking at %TriggerValue% was that I immediately started thinking about the macro trigger and nothing else. That can cause a lot of confusion, imo.
I understand why you're saying this, but honestly, it's never bothered me to pass reasonably large JSON strings using parameters.
@peternlewis Is this something we should even worry about - using instance variables to pass "large" data from one macro to another, instead of using either subroutine parameters or trigger value parameters?
Is that kind of memory consumption something to be bothered about? And it's even possible that if you're using reference-counted strings, it wouldn't add any overhead at all.
But in that case wouldn't it be even better to just use Execute a Subroutine, instead of instance variables?
We will need to have an action to execute another macro anyway, so why not use Execute a Subroutine instead?
Honestly, I've never needed to check for what hotkey triggered a macro, and I only discovered that %TriggerValue% contained the hotkey yesterday, by pure chance.
All that to say that I am not an expert on this.
I 100% completely agree that you should use whatever's specifically designed for what you're trying to do, so %Trigger% is probably the better thing to use. Assuming there is such a thing - I never looked at it before
In programming, there's a concept called self-documenting code, which is a fancy way to say that you should make it as obvious as you can what your code is doing. So by all means, use the token that best helps document your purpose. 6 months from now, you may have no clue how the macro works, and anything that can help jog the memory is a good thing.
Agreed -- but you have to munge multiple variables into JSON, pass the blob, then parse the blob to get them back out. While I like that in theory, in practice there comes a point where it's easy to just use Instance variables.
And that point is probably determined by your tolerance for JSON... <shudder>
Yeah, I don't think I've ever used either one (%Trigger% or %TriggerValue%).
I guess I will see how it goes from now on with what I learned today.
Even though I'm not a developer or anything remotely close to that, I always try to make everything as clear as possible, for that exact reason you mentioned. I want to be able to understand what that means 6 months from now, or even other people who will look at what I created. That's why my variables' names always tend to be very specific, even if I end up with longer names
I use that approach for anything in my life and work (music). I take notes of everything and always have in mind that I will reading it in the future and I need to be able to understand it.
Why? Instead of just referencing your (already defined) Instance variables in your sub-macro, you're now having to put tokens in a bunch of fields in the sub-routine action -- seems like a similar amount of work to me.
And what if you want your sub to run asynchronously? Or to return multiple values to the "parent" without you having to create, and later parse, a blob of data to get them?
My "assumptions" today are really just me trying to figure out how things work and which cases seem to contradict what I think it's obvious, hence my questions.
I'm not saying it "has to be" this way. If something makes sense to me from what I learned today, I like to question if a different approach actually has its pros and cons, which seems to be the case from what you guys are sharing. That's exactly why I ask these questions and bring these "challenges" to the debate.
I appreciate your feedback, because that shows me that different tools are still useful depending on what needs to be done.
