I have a question:
A macro A creates a variable, f.e. by finding an item in a long list that resides within that macro.
How to call this variable from within a Macro B. Can this be done?
Transfer of variables
Re: Transfer of variables
It is possible using a registry. For example here is the code that I used to pass a date variable from one macro to another.
So in the above code "Make Date Object" is the name of a macro that is being called. A registry object is used to pass $date to that macro, and then the return value is passed back (and then stored in $my_date).
The names 'usr.Macro.MakeDateObject.date', and 'usr.Macro.MakeDateObject.dateObject' are the names of the values as they are stored in the registry, and I have followed a typical template used for such names. But since a macro registry is deleted as soon as the macro finishes, I suspect much simpler names would work too, without having to worry about naming conflicts.
PS: Here is the code inside the Make Date Object macro that reads the incoming $date variable.
Code: Select all
$registry = Registry.macroRegistry
$registry.saveValueWithName($date, 'usr.Macro.MakeDateObject.date')
Make Date Object
$my_date = $registry.loadValueWithName('usr.Macro.MakeDateObject.dateObject')
The names 'usr.Macro.MakeDateObject.date', and 'usr.Macro.MakeDateObject.dateObject' are the names of the values as they are stored in the registry, and I have followed a typical template used for such names. But since a macro registry is deleted as soon as the macro finishes, I suspect much simpler names would work too, without having to worry about naming conflicts.
PS: Here is the code inside the Make Date Object macro that reads the incoming $date variable.
Code: Select all
# Input from user (via macro registry)
$registry = Registry.macroRegistry
$date = $registry.loadValueWithName('usr.Macro.MakeDateObject.date')
philip
Re: Transfer of variables
And at this point I'm going to engage in a little rant
One thing about registries just makes no sense to me. There are actually three 'types': macro, application, and user. This list is in order of permanence; macro is the shortest (just for the duration of the macro) and user the longest (forever).
Here is the thing. In every macro where you want to use one of these, you have to start with a statement like this:
The name $registry is a variable name for a registry object, and it can of course be anything you want, say $arthurDent or $zaphodBeeblebrox, or $whatever. But really this name does nothing whatsoever. It looks like you could create a dozen such registry objects, but that is a complete illusion. The variables you store in there are all going in the same place (if the macro is of the same 'type', that is. Remember, there are three 'types'.) So why couldn't the commands just be written as static commands. So instead of:
why not simply:
or maybe:
Every time you want to use one of those things, you need that extra, pointless object definition line and the even more pointless object name.
Okay, end of rant.
Have a nice day everybody!

One thing about registries just makes no sense to me. There are actually three 'types': macro, application, and user. This list is in order of permanence; macro is the shortest (just for the duration of the macro) and user the longest (forever).
Here is the thing. In every macro where you want to use one of these, you have to start with a statement like this:
Code: Select all
$registry = Registry.…(type)…
Code: Select all
$reg = Registry.macroRegistry
$reg.saveValueWithName(…)
Code: Select all
MacroRegistry.saveValueWithName(…)
Code: Select all
Registry.saveValueWithName('macro', …)
Okay, end of rant.
Have a nice day everybody!
philip
Re: Transfer of variables
Thank you. This helped.
BTW It took me some time to find out that loading a value $myValue from the registry does not mean that it is loaded. This happens only if you assigen $myValue = "" beforehand. Or should that be obvious? I think this whole procedure to make a variable of one macro available to another is not quite what they call user-friendly.
BTW It took me some time to find out that loading a value $myValue from the registry does not mean that it is loaded. This happens only if you assigen $myValue = "" beforehand. Or should that be obvious? I think this whole procedure to make a variable of one macro available to another is not quite what they call user-friendly.
Re: Transfer of variables
js wrote: I think this whole procedure to make a variable of one macro available to another is not quite what they call user-friendly.



philip
- martin
- Official Nisus Person
- Posts: 5230
- Joined: 2002-07-11 17:14:10
- Location: San Diego, CA
- Contact:
Re: Transfer of variables
That is certainly true! We should make it easier to pass arguments between macros. Currently there's not much in the way of facilitating inter-macro communication, and using the Registry like this is brittle and awkward.js wrote:I think this whole procedure to make a variable of one macro available to another is not quite what they call user-friendly.