This sounds great. It sounds like the ability to have a custom property
for variables, or even the ability to have a custom property for custom
properties!
If this feature were implemented, you would have all of the flexibility
of a relational database.
I am really rusty on the syntax (its been years since I took or used
pointers or anything like that), but it sounds a lot like being able to
create a general class (say, "Last Name") then attach increasingly
smaller subclasses ("First Name") or branches where needed. A branched
variable might look something like this:
lastName.firstName.user.address.PO
.city
.state
.zip
.email
.account.status.balance
.logon
Of course, xtalk shouldn't need to have the stiffness of this kind of
structure, but branched variables are very powerful. With this kind of
structure available, xTalk could become the language of choice for
database work!
If none of this makes any sense, please forgive me. It has been *sssooooo
llloooonnnnnggg* since I took any of this back in my college days, and I
haven't had any reason to use it.
But Ruediger, this sounds like a winner of an idea to me!
Regards,
Raymond
Ruediger zu Dohna wrote:
> Greetings!
>
> MetaCard has an elegant and powerful object model, but only for
> prefactured control classes (fields, buttons, etc.). There have been
> several suggestions on this list on how to expand this scheme so you
> can better manage your own i.e. field styles: You can create controls
> of a custom class (that itself is stored in a stack) just as you
> would create any normal control and they would inherit properties
> like colors, border, etc. from that class. This goes beyond what
> template objects do, bacause setting any property of the class would
> change the appearance of all the objects of that class.
>
> The next suggestion was to add scripts to these classes, so they
> could show a common behaviour when a custom property (i.e.
> colorScheme) is set or read as well as when a message is sent.
> Messages should be sent to the object first and then passed to the
> class before it is sent to the card etc.
>
> A group class (aka background class) would even have several objects
> tied together to act as one custom control type. Coming to the
> question of where to store these classes, it may be an option to only
> allow backgrounds to act as custom controls, because there is a way
> to store and still edit them.
>
> What I would like to see much more than all of this, are non-control
> objects and classes. I think it would be nice to say:
>
> get the emailAddress of user "Scott"
>
> These objects could either live temporarily in memory or be stored as
> custom properties et.al.! What does everybody else think?
>
> Regards
> R�diger
> --------------------------------------------------------------------
> | Ruediger zu Dohna GINIT GmbH 0721-96681-63 [EMAIL PROTECTED] |
> | PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E |
> --------------------------------------------------------------------
