Tinderbox Forum

Some How-To Questions - MapView locking, Identifying Agents, Locating Orphan Attribute Values

Hi all,

Deep in an active project, and had 3 questions:

  1. MapView Locking - re-positioning root-level Containers and Notes in Outline View causes those objects to re-locate randomly in Map View. Not usually a problem for me - but on this project, it is. Any idea how I can lock down the containers, other than recording and re-feeding the Xpos/Ypos Values to those root-level Notes/Containers?

  2. Quick way to identify Agents? I’m looking for something like ‘$IsAgent==true’. For now I’m going with $AgentQuery!="" and/or $AgentAction!="" - but this seems kludgy; furthermore, it’s vulnerable to downstream changes.

  3. Usually I’m good at ensuring that a Note copied over from some other project already has matching Attributes setup in the destination project… but sometimes I miss a few. Then I’ll get the “this Attribute does not exist, would you like to create it?” message, but in my haste I’ll already have closed that pane. How do I get that warning pane back?

Thanks!

  1. Repositioning notes in outline will only change their map position if (a) they are part of a composite, or (b) you move them to a new container.

  2. $AgentQuery!="" is what you want. I don’t anticipate a change that would invalidate this test.

  3. I believe if you edit Displayed Attributes again, you’ll get the warning again.

1 Like

1 - Repositionings - Maybe I’m doing something weird/wrong, but am certain that this repositioning has been taking place in projects where composites are off and also no moving into other containers occurred. When I have some time I’ll test and take a screen recording, in case it is useful.

2 - $AgentQuery!="" - OK thanks!

3 - Warnings - I tried that, and also tried closing/reopening the project. I also tried adding back that Attribute via the DisplayedAttributes pop-up, no luck there. Will report if it pops up again.

I’ve created a prototype for my agents. This addresses both the issue you raise and also configures the displayed attributes. I’ve also been assigned the agent prototype the action prototype so that I can write action code in the text, which helps me write my queries, among other things.

2 Likes

When you’re bringing notes over from another file and you don’t heed the warning, just delete the first note and copy it again. The delete the note again and re-copy it so all the data from the note in the other file makes it over to the file.

Oh wait…!!! I didn’t even realize you could do that… Brill!!!

1 Like

That’s what I’ve been doing since the past few months. But clearly I (probably operating on fumes one night) overlooked my due diligence, and this warning popped up weeks after. No way I can re-trace where the offending Note even came from; it was most likely one of my temporary ‘pop-up’ Tinderbox project files lol.

I think most is covered but a couple of extra observations.

Issue #1
Consider ‘locking’ the affected notes.containers that must not move. Lock state is stored in $Lock, which is easily set via the Properties Inspector’s More tab or via a stamp.

When a note is locked the following cannot be altered:

  • map position ($Xpos, $Ypos)
  • size ($Height, $Width)

It is still possible to alter colour, shape, etc., just not the above. For locked containers (note or agent) in addition:

  • title bar height is fixed ($TitleHeight) , i.e. title area vs. viewport area split
  • you can’t drag the child map within the viewport.
  • you can’t drag items out of the viewport (i.e. promote the to the current map)—though you can drop items onto the viewport and they are moved to the child map.

Important note: locked items don’t show re-size handles (duh - they can’t be re-sized) but this can confuse as they are perhaps the most obvious indication of selected items in map view. :wink:

Dragging a locked item causes the whole map to move, i.e. as if click-dragging the background map.

Issue #3
Aside from the “how do you re-trigger…?” aspect, a few notes. An undefined attribute name in $DisplayedAttributes will cause that name to be used in the Displayed Attributes table (and Get Info) in light grey:

How to find these, or to check if any have crept in unnoticed? IOW, as a periodic check. Well, we know they will be in the Displayed Attributes of (some) notes. So (tested in v9.1.0, FWIW):

$MyDAList == values("DisplayedAttributes");

Give us all attributes (defined or not) in use via Displayed Attributes. We can also check for an attribute’s category (i.e. group) like so:

$MyString = attribute("MyList")["category"];

… returns sandbox. An undefined attribute’s name returns nothing. So we can do this:

$MyList=;
values("DisplayedAttributes").each(anAttr){
   if(attribute(anAttr)["category"]==""){
      $MyList += anAttr;
   }
};

$MyList now contains the names of any undefined Displayed Attributes. By chaining .each() to the output of values() (which we know returns a Set-type list) we avoid needing another attribute or variable in the code. Here I used a List for the result; it arrives as a Set, though here the difference does not matter. However, we do know the result may be more than one item plus we need it in an attribute so we can do things with it, like use $MyList’s value(s) to:

  • find notes using that
  • use the Inspector to define a suitable user attribute

In which order you do the two probably depends on the whether the (undefined) attribute name(s) indicate their purpose or not. If not, looking at the notes via which they arrived might help.

3 Likes

Here is an example of action code in the agent:

When I preview the agent it gives me a glossary of terms in an article with a link to all the notes that are using the term.

This method allows for a self-contained agent/action code/template note. Most people may not need this, but in my larger book that relies on a fairly intricate template, it is necessary. As they say, necessity is the mother of all inversion.

As always, kudos to @mwra for his help. This time around I got about 90% there before calling uncle and asking for help (previously I’d call uncle as <50%, so progress. :slight_smile:

3 Likes

Great stuff!! Thanks so much for the insights, I’m going to pore over these and may have questions Saturday! :smiley: