Hugh Senior wrote:
>> Buttons can re-use a single image, and be updated as the source
>>image changes.
>>
>> Would it be equally possible for a field to display the text of another
>> field and be automatically updated when the source text is changed? This
>> would be immensely useful to maintain multiple instances of the same text
>> without duplicating the storage.
>>
>> set the sourceField of fld "Address" to fld "Address" of stack
>>"AddressBook"
>>
>> Is this possible, Scott, perhaps as an item on a wish-list?
Scott Raney wrote:
>Sounds like a recipe for spaghetti to me. What happens when the
>source field changes, do all fields that point to it have to be
>live-updated with it? And what if you change the field, does the
>"sourceField" get updated? What happens with fields with sharedText
>set to false, do you have to specify the card? And the biggest
>question: What would this be useful for?
You got your wrist slapped there, Hugh. :) I got a similar response
(not just from Scott) when I once suggested something similar
(although not specifically related to text in fields). In your
example, though, is "live linking" really necessary to save storage?
I don't know the details of your setup, but if you have the address
data in one stack, it is possible to display that data in another
stack without storing it there. As an example, in a user database I
have for a training course, I keep the majority of the user data in
external files, one file per user. In the "database" stack, I keep
one card per user, but only store limited data there (for example,
name, id, and last access date). On the cards, in addition to these
fields, I have another set of fields in a group to display the data
from the external file (detailed test results and so on). The fields
in this group have the sharedText property set to true. The fields
get populated from the appropriate external file in a preOpenCard
handler. In this way, the data in the stack gets kept to a minimum
and helps overcome the RAM issue when handling large quantities of
data. (I keep some basic data in the stack as it makes it possible to
build a summary list of data quickly.)
But you know all this, Hugh, so perhaps I missed the gist of your mail.
The above example doesn't do any "live updating". It relies on the
openCard message to trigger the update. But I think some kind of live
updating is probably possible through setprop handlers (although this
is only a vague idea somewhere at the back of my head).
Anyway, I'm always interested in hearing about strategies for
maintaining "databases" in Metacard. I'd love to hear of other
peoples experiences.
Cheers
Dave Cragg
