Transfer of variables

Get help using and writing Nisus Writer Pro macros.
Post Reply
js
Posts: 259
Joined: 2007-04-12 14:59:36

Transfer of variables

Post by js »

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?
User avatar
phspaelti
Posts: 1313
Joined: 2007-02-07 00:58:12
Location: Japan

Re: Transfer of variables

Post by phspaelti »

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.

Code: Select all

$registry = Registry.macroRegistry
$registry.saveValueWithName($date, 'usr.Macro.MakeDateObject.date')
Make Date Object
$my_date = $registry.loadValueWithName('usr.Macro.MakeDateObject.dateObject')
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

# Input from user (via macro registry)
$registry = Registry.macroRegistry
$date = $registry.loadValueWithName('usr.Macro.MakeDateObject.date')
philip
User avatar
phspaelti
Posts: 1313
Joined: 2007-02-07 00:58:12
Location: Japan

Re: Transfer of variables

Post by phspaelti »

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:

Code: Select all

$registry = Registry.…(type)…
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:

Code: Select all

$reg = Registry.macroRegistry
$reg.saveValueWithName(…)
why not simply:

Code: Select all

MacroRegistry.saveValueWithName(…)
or maybe:

Code: Select all

Registry.saveValueWithName('macro', …)
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!
philip
js
Posts: 259
Joined: 2007-04-12 14:59:36

Re: Transfer of variables

Post by js »

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.
User avatar
phspaelti
Posts: 1313
Joined: 2007-02-07 00:58:12
Location: Japan

Re: Transfer of variables

Post by phspaelti »

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.
:P :P :P
philip
User avatar
martin
Official Nisus Person
Posts: 5227
Joined: 2002-07-11 17:14:10
Location: San Diego, CA
Contact:

Re: Transfer of variables

Post by martin »

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.
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.
Post Reply