>The long-defunct WinPlus (which morphed into OMO) had a class of entities
>called "Software Slot Functions", "Software Slot Commands", and "Software
>Slot Objects" that allowed developers to define a more elaborate interface
>than XCMDs and XFCNs have.
Hi,
is this similar to the MOX APIs?
>Though I don't have the documentation here (I'm
>on vacation and on the road) and in addition I may no longer have ANY
>documentation left in my possession, I recall that parameters to
>user-defined SWSFs and SWFCs were binary and could be 'by reference'. That
>is, one could send the names of xTalk containers to be accessed or filled
>with data (as opposed to sending only the contents). I don't remember
>whether there was any type-checking built in.
I think it'd be useful to have a look at it. Although OMO pretty much
kludged together its Macintosh Handles to work on Mac, the API may contain
things worth salvaging.
>In addition, one could define new 'objects' that (if I remember correctly)
>might or might not have a visual representation. These objects could have
>contents and properties (like xTalk objects or XML entities) as well as
>handling messages via their own scripts or their C internals. In other
>words, like a hybrid between xTalk objects and C++ classes.
I think this would be enough support for custom objects needed for
anything. Have the darn thing be notified of events like mouse clicks or
withins, let it draw itself, let it have properties. Sounds like a nice
minimal spec for an object extension API to me.
Of course, e.g. the drawing code would be platform-specific, but at least
a programmer having to program the same XCMD for several platforms would
only have to learn the XCMD specs once, save for maybe naming differences
in calls like XGetPartPort() and XGetPartDC(). But such consistent naming
would already make it worth devising such an API.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
The future of programming: http://freecard.sourceforge.net
