On Thu, 2 Dec 1999, Kevin Miller wrote:
> On 1/12/99 10:00 pm, Scott Raney <[EMAIL PROTECTED]> 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?
> >
> > 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?
>
> The more I think about it, the more this idea appeals to me. Like button
> icons, it seems that it would be useful to be able to use the same text
> "store" somewhere to display text in multiple different places. A bit like
> placing groups onto multiple stacks. Whilst placing groups onto multiple
> stacks would go a long way to solving the problem that Hugh is trying to
> solve, it wouldn't be ideal because the fields inside each group would have
> to be in the same place, size, shape. I'm thinking along the lines of using
> MetaCard to create something like Filemaker's ability to view the same
> information through multiple different interfaces. Sure, it can be
> scripted, but if someone is doing this on a heavy-duty basis, it would be a
> most considerable shortcut just to set a property.
Maybe, but I'm not sure that it's worth all the trouble just to
eliminate a couple of lines of script. Is moving text from one field
to another really all that difficult?
> I'm not sure about the "sourceField" proposal for implementation though. I
> think this might conflict with sharedText. Instead, how about allowing
> sharedText to contain the long id of a field or button, and also any custom
> property on an object somewhere. This proposal would make the data transfer
> bi-directional, exactly as sharedText is now.
So you couldn't transfer text from fields or button contents, just
from custom properties? And this still doesn't really address the
updating issue: what happens when the user changes the text in a
field, does the source get changed after each keystroke (could be very
expensive for a lot of text). And when you change the source
property, would all fields displaying that property have to be live
updated?
> In short, imagine, for example, being able to open a card and make all the
> fields in the card point to specific custom properties that correspond to
> the current "record" being viewed? (Setting the property on a field would
> cause it to take the information *from* the container you set it to share
> with.)
I'm all for reuse, but it seems to me that sharing groups across
stacks gets you most of this with about 10% of the work and a small
fraction of the potential spaghetti factor (imaging trying to debug
something with lots of links like this! At least with scripts you can
see what they're doing...)
Regards,
Scott
> Regards,
>
> Kevin
>
> > Regards,
> > Scott
> >
> >> /H
> >> Hugh Senior
> >>
> >> The Flexible Learning Company
> >> Consultant Programming & Software Solutions
> >> Fax/Voice: +44 (0)1483.27 87 27
> >> Email: [EMAIL PROTECTED]
> >> Web: www.flexibleLearning.com
> >>
> >
> > ********************************************************
> > Scott Raney [EMAIL PROTECTED] http://www.metacard.com
> > MetaCard: You know, there's an easier way to do that...
>
> Kevin Miller <[EMAIL PROTECTED]> <http://www.xworlds.com/>
> Cross Worlds Computing, MetaCard Distributors, Custom Development.
> Tel: +44 (0)131 672 2909. Fax: +44 (0)1639 830 707.
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
