Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
http://www.eastgate.com/Tinderbox/forum//YaBB.cgi
Tinderbox Users >> Questions and Answers >> Program language question
http://www.eastgate.com/Tinderbox/forum//YaBB.cgi?num=1429764234

Message started by Barbara Snyder on Apr 23rd, 2015, 12:43am

Title: Program language question
Post by Barbara Snyder on Apr 23rd, 2015, 12:43am

Hello --

Is there any form of case or switch statement available, to avoid a long set of if else if else if else statements? So once a condition is met, the next conditions are not evaluated?

Thanks -- Barbara


Title: Re: Program language question
Post by Mark Anderson on Apr 23rd, 2015, 3:39am

In short, no. Action code is an internal macro code that has developed ad hoc over the life of the program. It wasn't designed as a scripting language and it is an assumption of it being one that tends to lead to presumption of scripting features like elseIf, case/switch and ternary operators.

For repeated, exclusive tests, nest your if() statements. For large sets of tests, the code note approach can help.

If you're needing many many hard-coded if() tests in a single action, history shows that can normally be avoided by improving the overall workflow design in the document.

Title: Re: Program language question
Post by Barbara Snyder on Apr 24th, 2015, 5:04pm

Thanks, makes sense. I am indeed using the code note option - very happy to have discovered it!

I am just wanting to auto-set one field's value ($user_category) based on another ($Name). So in this case, only a bunch of if statements fill the bill.

Since the category is a set and can take multiple values, I don't need to resort to nested if statements, which I desperately want to avoid.

Thanks -- Barbara


Title: Re: Program language question
Post by Mark Bernstein on Apr 25th, 2015, 7:44pm

The next release will likely have a new way to address this problem.

Title: Re: Program language question
Post by james a. foster on Sep 23rd, 2016, 3:15pm

So, does the current version address this limitation?

Title: Re: Program language question
Post by Mark Bernstein on Sep 24th, 2016, 12:26pm

Yes, the current release supports lookup tables to address exactly this scenario.

Let's suppose we have have a bunch of items and prices. When we name a note "lobster", we want its $Price to be the price of lobster. When we name a note "shrimp", we want its $Price to be the price of shrimp.

In some handy place, we store a list of names and prices. It looks like this:

    lobster:19; shrimp:7.5; halibut:13; mackerel: 12;

Let's put this list in our example in the $Text of a note named PriceList.  Top get the price of (say) lobster, we use the at() operator

    $Text(/PriceList).at("lobster")

To get the price of the item in this note's name:

    $Text(/PriceList).at($Name)


Title: Re: Program language question
Post by Mark Anderson on Sep 24th, 2016, 1:19pm

More on look-up tables.

Title: Re: Program language question
Post by james a. foster on Sep 30th, 2016, 1:38pm

WONDERFUL! I look forward to playing with this! Thank you!

Title: Re: Program language question
Post by james a. foster on Sep 30th, 2016, 2:39pm

ok, so right off the bat, I'm stymied. or confused. I'm trying to set $KeyAttributes on notes according to the value of another field. So I want something like this:

$KeyAttributes=$flag.at($KeyFlag)

Where presumably $flag = "optionA: keys; optionB: otherkeys;" and, let's say, $KeyFlag="optionA"

But with KeyAttributes, the values are sets! So I would need the value for look-up key "optionA" to be something like "Color;Color2;Text;flag"

BUT...surely this is invalid syntax (or is it??):

   $flag="optionA:Color;Color2;Text;flag; optionB: otherkeys;"

Also, my ACTUAL problem is that the $KeyFlag field is actually a set (it is the set of classes in which the note belongs). So I really want something like:

   $flag="optionA|optionC:Color;Color2;Text;flag; optionB: otherkeys;"

and $KeyFlags="optionC;optionD"

would $KeyAttributes = $flag.at($KeyFlags) work in that case??

Title: Re: Program language question
Post by Mark Anderson on Sep 30th, 2016, 5:13pm

So you want to store lists (semi-colon concatenated strings) in a look-up list.  I don't know for certain but I don't think that was an envisaged use case and so at best is lightly tested. Rather than push against the stream, I'd look for an alternate approach.  How many classes (with discrete KA lists) are there.  Why not, for instance, use a prototype for each class and set the KAs there?

It's hard to be too specific as we don't have visibility of the whole document environment.

Title: Re: Program language question
Post by james a. foster on Oct 3rd, 2016, 12:31pm

no more than a dozen classes (in my case, these are the sections of a CV). I like the idea of prototypes, especially prototypes that are children of a master prototype, where the children specialize in setting the $KeyValues.

I had also thought of adding multiple code notes, where the code does nothing but set the $KeyValues, but that seems like overkill

Thanks, I think I can solve my problem now. (well, the one involving Tinderbox anyway)

Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.