Reply to topic  [ 6 posts ] 
Transfer of variables 
Author Message

Joined: 2007-04-12 14:59:36
Posts: 229
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?


2014-05-14 05:05:00
Profile
User avatar

Joined: 2007-02-07 00:58:12
Posts: 876
Location: Japan
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:
$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:
# Input from user (via macro registry)
$registry = Registry.macroRegistry
$date = $registry.loadValueWithName('usr.Macro.MakeDateObject.date')

_________________
philip


2014-05-14 06:25:17
Profile
User avatar

Joined: 2007-02-07 00:58:12
Posts: 876
Location: Japan
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:
$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:
$reg = Registry.macroRegistry
$reg.saveValueWithName(…)

why not simply:
Code:
MacroRegistry.saveValueWithName(…)

or maybe:
Code:
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


2014-05-14 06:49:33
Profile

Joined: 2007-04-12 14:59:36
Posts: 229
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.


2014-05-14 12:45:26
Profile
User avatar

Joined: 2007-02-07 00:58:12
Posts: 876
Location: Japan
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


2014-05-14 15:17:47
Profile
Official Nisus Person
User avatar

Joined: 2002-07-11 17:14:10
Posts: 4251
Location: San Diego, CA
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.


2014-05-16 19:13:31
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 6 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software