Welcome, Guest. Please Login
Tinderbox
  News:
IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).
  HomeHelpSearchLogin  
 
Pages: 1
Send Topic Print
Setting Prototype based on KA (Read 1870 times)
Ted Goranson
Full Member
*
Offline



Posts: 141
Virginia Beach VA
Setting Prototype based on KA
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.
Back to top
 
« Last Edit: Jan 03rd, 2015, 12:10am by Ted Goranson »  
WWW TedGoranson   IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Setting Prototype based on KA
Reply #1 - 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;
Back to top
 
« Last Edit: Jan 3rd, 2015, 11:10am by Mark Bernstein »  

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Ted Goranson
Full Member
*
Offline



Posts: 141
Virginia Beach VA
Re: Setting Prototype based on KA
Reply #2 - 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
Back to top
 
« Last Edit: Jan 3rd, 2015, 4:08pm by Ted Goranson »  
WWW TedGoranson   IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Setting Prototype based on KA
Reply #3 - 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.
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Pages: 1
Send Topic Print