Sounds like you're the type that solves your problems as you talk (or type)
about them. :-)
... or at least I think I do ... Usually I'm wrong.
Do you plan to have pre-existing stacks for each of the
tree levels before reading data?
Yes. The stacks will pre-exist and all fields that appear in the data
will appear in the stacks.
Creating these as you go, and trying to
lay out card formats on the fly could get very tricky. And then there's
the problem of needing a licensed home stack to create objects from within
a script.
Only some objects require a license. Creating cards is ok.
If you know the format of your data, it's probably best to
include a sub-stack with a 'template' card for each of the possible levels.
When you think about the scripting needed to provide the data links, this
becomes even more of a concern.
As for maintaining the links to lower levels, the easiest method is
probably to just name cards to indicate the data that they contain, as is
done in the MetaCard help stack. For instance, a click on the text "Pima
County" in the Counties field of the States stack would cause the display
of the card "Pima County" in the Counties stack. Umm, I believe that this
handler in the Counties field would do the trick. (But I think the text
would have to be grouped).
on mouseUp
go to card the clickText of stack "Counties"
end mouseUp
Where would you store data that isn't immediately placed on cards? I guess
you could stuff it into globals. Maybe it could all be stored in a hidden
field on the first card of its corresponding stack.
Or even a hidden field on every card. Example: there is a "City"
field, there is also a "(links) City" field.
The dictonary is an
interesting idea. I guess you'd have to include an entry to indicate
whether a card had been created for the data in question.
... or just use the "if there is a card X" phrase.
Thanks for the prompts. I'm getting a better feel already.
-Pothier-