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
Aliases on agent maps, adornments and stamps (Read 1688 times)
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Aliases on agent maps, adornments and stamps
Mar 13th, 2013, 7:26am
 
In [urlhttp://www.eastgate.com/Tinderbox/forum//YaBB.pl?num=1306866276/11#11]this post[/url] @Minty asks:

Quote:
Brings me to a second point, and where I'm stuck.  I'm trying to find commonalities within two hieararchial terminologies.  One way to do these was to create aliases of one whole terminology hierarchy, and arrange them within the second hiearchy using the map view to help arrange the concepts (and using the adornments to add the attributes).  Using aliases preserves the original hierarchy.

I've revised the adornments (they represent an evolving content model) a number of times during this process.

I'm having trouble getting rid of old attributes from aliases (either using the stamp, OR manually deleting them), despite the fact that when I look at the 'original' note, the attribute data is cleared (after manually clearing it).

Any ideas as to what would lead to behaviour like this an how to fix it?
_________________
UPDATE: Restarting Tinderbox seems to have resolved alias / attribute thing.  Apologies.  Comments re: On Add / On remove (or even a way of 'reapplying' OnAdd after a stamp resets attributes) would be welcomed!  Thanks.


I can replicate this, but only for aliases on an agent's map (whose cleanup has been disabled). The problem is not a bug, but a difficult edge case where that result is not as desired in this context.

What's happening? Quite simply, when you use the stamp, the map redraws and as part of this that adornment run their OnAdd. If an alias is not an adornment the 'reset' stamp works. If it is on an adornment, after the stamp code runs, the adornment's $OnAdd appears to revert the change (at least for the attributes set by the adornments).

The same problems don't occur on normal (non-agent map) but of course you need an agent to flatten your outline (hierarchical data) into a single map.

How to avoid this problem? Simply move the item off any adornment (that uses $OnAdd code conflicting with the 'reset' stamp code) before applying the stamp.

Side note, when checking attributes for aliases bear in mind:
  • If viewing the note window of an alias to view ket attributes, you are looking at the text window of its original note.
  • Some attributes are intrinsic to aliases - i.e. the alias can hold its own discrete value. For example, $Height and $Width can differ for an alias.
  • For text window key attributes set to show $Hight and Width, on opening the window from the alias the values shows are for the original, not the alias. Non-intrinsic attributes will be the same for both.
  • To view an aliases intrinsic attribute values, use Info view (Cmd+Opt+i).
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