Working with subsidiaries to non-Namesakable items

Ways of getting BrainStorm to do unexpected or interesting things

Moderators: david, OG, Galen

Post Reply
alx
Insider
Posts: 46
Joined: Sun Oct 23, 2005 9:24 pm

Working with subsidiaries to non-Namesakable items

Post by alx » Sun Feb 05, 2006 12:30 pm

Brainstorm has a rather non-obvious logic when dealing with information subsidiary to non-Namesakable entries, i.e. entries with Namesake Off; here's an example to demonstrate it:

- Create a new Brainstorm model
- Type an entry, say [David Tebbutt]; let's refer to this entry as Entry1
- Promote the entry (make it a heading) and enter some information on David
- Demote the entry (go up one level)
- Now press Ctrl+N (Namesakes Off) over Entry1
- As we can see, though non-Namesake-able anymore, Entry1 maintains its subsidiary info; fine.
- Press Ctrl+N over Entry1, to make it Namesake-able once more

- Now, type another identical entry, i.e. [David Tebbutt] again; let's refer to this as Entry2
- Brainstorm will rightly recognise these as Namesakes and make the information under Entry1 available to Entry 2 as well.
- Now press Ctrl+N (Namesakes Off) over Entry1 again
- You will now notice that the original information under Entry1 has disappeared and remained as subsidiary of Entry2

Brainstorm apparently prefers to allocate ownership of subsidiary info to those identical entries that maintain "Namesake potentiality" rather than to isolated ones, even if they are the original headings of that info.

What if you want the subsidiary info to remain with a Non-namesakable entry? The simple workaround is to enter that info after you make the heading Namesake ignorant.

In fact, you can have as many identical entries as you wish with different subsidiary info, as long as you turn Namesakes Off for those entries before adding any info.

alx

david
Staff
Posts: 329
Joined: Sun Oct 23, 2005 7:08 am
Location: London, England
Contact:

Post by david » Thu Feb 09, 2006 8:24 am

To throw a little light on our thinking:

If a bunch of entries share attributes (descendants) then the removal of an entry from that bunch (by non-namesaking) shouldn't deprive the rest of their shared ownership.
David Tebbutt

Fionvarin
Registered member
Posts: 1
Joined: Thu Oct 27, 2005 1:48 am

useful to know

Post by Fionvarin » Thu Feb 16, 2006 2:23 am

This is very useful to know. The namesake function has great charm but it's nice to know how to control it.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest