Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
http://www.eastgate.com/Tinderbox/forum//YaBB.cgi
Tinderbox Users >> Agent, Actions, Rules & Automation >> Setting Prototype based on KA
http://www.eastgate.com/Tinderbox/forum//YaBB.cgi?num=1420261764

Message started by Ted Goranson on Jan 3rd, 2015, 12:09am

Title: Setting Prototype based on KA
Post by Ted Goranson on Jan 3rd, 2015, 12:09am

v5

I have notes whose default prototype is p_parenthetical

Each has a key attribute $ParentheticalType

A typical type is "Incidental"

The desired behavior is that when the "Incidental" KA is selected, the $Prototype should change to p_parenthetical_incidental

Here is what I have.

p_parenthetical_incidental is a prototype inherited from p_parenthetical

p_parenthetical contains a rule:

$Prototype = "p_parenthetical_" + $ParentheticalType.lowercase;

This does not work.

Whether the rule is included or not, I cannot manually select p_parenthetical_incidental from the rename dialog as it is greyed out, together with all other prototypes inheriting from p_parenthetical

So the two questions:

Is the assignment above syntactically fine?

What causes prototypes to be unelectable?

Thanks.

Title: Re: Setting Prototype based on KA
Post by Mark Anderson on Jan 3rd, 2015, 7:28am

Odd. I can't be 100% sure without seeing the file but I think it is circular referencing. Let's assume you have 3 prototypes A, B, C and D. Further, A is set to use B as its prototype, whilst B uses A as its prototype (circular reference!). Normally, when you select C and open the pop-up list of prototype s, the only unavailable prototype is the current one, i.e. A B and D would be available and C greyed out (all 4 would be available to any non prototype note). But, due to the circular reference now only D is available. Why? C is the current (prototype) note so unavailable as per normal. A and B are unavailable because of the circular reference we created.  TB5 has no error messages but this is - I presume - a subtle way of letting you assign prototypes that can't work.

So, I'd review all the new prototypes you've made re parentheticals and check for correct assignments. Tip: it may help to make a quick new doc and a map  with an icon for each of the prototype names; then drag links for your proposed inheritance - look for circular paths.

Assuming that resolves the 'missing' prototypes and you action still doesn't work, try progressively adding in parentheses:

$Prototype = "p_parenthetical_" + ($ParentheticalType.lowercase);

$Prototype = ("p_parenthetical_" + ($ParentheticalType.lowercase));

That may help guide TB to parse the code as per your intent. I've also a vague memory that this may be an edge case where you may need to cache the assembled value before use, i.e.:

$MyString = "p_parenthetical_" + $ParentheticalType.lowercase; $Prototype = $MyString;

Title: Re: Setting Prototype based on KA
Post by Ted Goranson on Jan 3rd, 2015, 4:06pm

This will have to be a mystery for now.

For what it is worth, I started over from scratch, carefully creating not dirty prototypes. (I suspected that some experiments may have stuck in the wrong way.)

I can successfully create the intermediate attribute with the desired prototype's name.

But

$Prototype = $ThatName

creates havoc. So for now I will do it the other way I suppose, selecting the prototype from a KA and setting the type attribute automatically. (I have some code that uses it.)

Reminder: this is v5

Title: Re: Setting Prototype based on KA
Post by Mark Anderson on Jan 3rd, 2015, 5:55pm

[Understood this is v5 (and, off camera, rationale behind that)]

Great, that's a primary cause eliminated (looping refs).

Using a simple test doc (my starter TBX) and storing a valid prototype name in $MyString, I tried this rule:

$Prototype = $MyString;

For me, it does work. What is the 'havoc' to which you refer? The nature of the latter may help elucidate things. A hunch is there's a cascade of unintended actions resulting from a code error or bug/edge case. However, it is the case the $Prototype can be set to the value of another attribute via rule.

I think you've more moving parts in the mix; you may need to break the process down some more to trap the point where the process goes amiss. I probably need to see the file that shows this 'error' in action.

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.