Actually, this came up in a slightly different form just this weekend in the topic "Listing all individual entries in an attribute?" (start reading at post #7.

Started another way you wish to leverage the ease of use of a code-note but you need to be able to pass it a variable. Currently, this is not possible. However, you can do a similar task via a macro. Sadly, macros can't be stored in/called from notes (feature request!), though you could use a code-note to draft the code and copy paste the code to the macro box (Macros tab of attributes palette).

~~~~~~~~

An idea... I've not time to test this right now, but perhaps you could pass a single variable to a code note. Rough idea: with a code code, we call it like eval($Text("My Code note")), but what if we used .replace() and macro-like replacement target strings. Thus instead of a '$1' type placeholder we use an unlikely string, say "ZZZZ". We put this everywhere we want to insert the input variable. Now we call eval($Text("My Code note").replace("ZZZZ","my input")). So first the target note does a delete on it's $Text which is then evaluate Not as flexible as a macro, but something you could try if you've only one input variable.

Before someone moans that the above is 'hard', I'm not suggesting it is simple - but it is something do-able today. Put another way, if someone really needs this now, it won't seem so hard.  

If it's literally just boilerplate text, then you can just call $Text for that note. By contrast, if there is action code in the note the eval() call will give you the action code result of what's in that $Text.

If you get to going the latter route, do an initial test with something simple so you know the basic principle works.  That way, when - as we all do, you dive in with the fiendishly complex code you actually want to use and it fails, you've some point of confidence to lean on.

Quote:


Not long ago I discovered I could place blocks of code in code notes DoThis and DoThat then run the code from this stamp:

action($Text("DoThis"));action($Text("DoThat")).


Assume same approach will work in rules too.

Sorry to be daft on this.

My immediate problem is that I want to call code notes without passing variables.

I have a code note that has a rule that assigns the text of that note to the rule of another.

In that code note, I wish to reference other code notes, so that the text of the Original Code Note contains statements such as:

$Text("secondary note 1");
$Text("secondary note 1");

But of course this does not work, nor does

eval($Text("secondary note 1"));
eval($Text("secondary note 1"));

I also tried putting the code in macros and placing this in the Original Code Note:

do("macro 1");
do("macro 2");

But Sumner's suggestion DOES WORK!

action($Text("secondary note 1"));
action($Text("secondary note 1"));

So there is something at a fundamental level that I am missing.

+++++

My long term problem is that I would like to pass variables.

If I understand it right, a stamp can only be evoked manually and you cannot pass variables.

The do(AMacro[SerialArg1, SerialArg2]); command seems ideal.

and it seems similar to $Text("ANote").replace("DenotedArg1","DenotedArg2");

But when in a passed rule, I suppose it needs to be:

action($Text("ANote").replace("DenotedArg1","ReplacedArg1"));

right?

This thread is getting very complex - we're discussing edge cases for tasks for which operators were likely never envisaged (or tested for such) and at the same time nuances of the context of invoking them ... and then trying to applying certainties.

Meanwhile, Eastgate's engineering efforts are focused heavily on other TB matters right now (stuff people really want too) and so I don't think it useful to make this edge case stuff a priority at this time. I'm sure this will get resolved, but probably not right now.

I'll try and nibble away at some issues, perhaps in more bite size posts.

eval() vs action(). As concisely as I can put it, they do the same but eval() returns something and action() doesn't:

$ReturnValue = eval( [some code] )
action( [some code] )

The temptation comes - and here Im' as guilty as the next person -  of using these as a crowbar to force TB to produce a result for which syntax appears missing.

Let's pick a trivial task, the sum of 2 plus 3 (5).  For eval() use, we'll make the $Text of 'test1': 2 + 3. $ReturnValue is a user String attribute just added to hold the result (such a name sometimes fools learners into thinking it is some built-in feature). Now in note "X", we run this rule:

$ReturnValue = eval($Text("test1"))

The $ReturnValue of  note X [sic] is now "5". Change the rule to

action($Text("test1"))

Nothing happens in either 'X' or in 'test1'. No, the $Text of 'test1' doesn't become "5". Why? We're not evaluating the contents of $Text, we're running is as action code. Although '2 + 3' is valid action code maths addition it doesn't tell us what to do with the result so action() has no outcome.

The pont of the above is that context matters. Avoid using eval() and action() as the tool of last resort without first stopping to consider context.

Why eval() failed and action() worked for Ted I can't say but without more detail or a TBX example it's hard to say why and whether the result is correct or some form of false positive (which is a slight worry bead I have).

What I means by complex was at one and the same time discussing the syntax of operators whose exact design intent is not documented (and can't be unambiguously worked out be the user) at the same time as the context of execution. The second adds a second layer of false positive/negative outcomes in an app that (by design) avoids giving error messages.  It means this aspect of use is definitely really for those with a good degree of TB action code experience under their belt. My little example above was deliberately ludicrously simple so as to give a working base off which to try more real world things.

For me, the confusion around eval() & macros arose in the context of Alex Strick's problem (in the main forum) where we were coercing a list of strings into a string of macros and wanting the (correct) evaluated output. It proved the context of the eval() call makes quite a difference.

I've made a note to cross-reference do() and eval() in aTbref. The info to capture there is that do() returns a string with multiple verbatim substitutions of between and nine input strings for $-placeholders ($1-$9). Any action/export code within the macro or the input is not evaluated. Ergo if you need to insert an evaluation of an input, you must evaluate the input before passing the result to the macro. Wrapping an eval() call around do() will evaluate the whole macro output string. Whether the latter will suffice probably boils down to thinking how many layers of nested evaluation are involved and/or how complex the evaluation is. Judicious addition of parentheses around nested evaluations may help. Until you know so from experience, don't assume eval(do()) will evaluate the way you assume it will; sometimes there's more than one valid answer - depending on your starting assumptions. Also, with more complex tasks, be alive to the possibility of no/single/double quoted strings being handled differently. The two quote type, correctly nested, should parse the same way but this is the area where you may hit an edge case in the app's parsing and you may need to check with support.

I'd agree that for the average users (and for the convenience of expert users as well) some of these constructs would be more accessible if some of the self assembly (correct nesting, etc.) were wrapped up in some new codes. I've already mailed in an idea to let do() use a note name/path as a valid input for the macro name argument. IOW, TB would look at stored macros and if no match is found, then use the $Text of the note cited as its macro code.  If nothing else, that would help me be able to read/structure my macro code more clearly!

[edit - typos]