Zoolib actually got its start for exactly this kind of thing -- I was
writing plugins for HyperCard and Director, as well as Mac control
panels. In each case the window was created and owned by the host
application and events passed to the plugin via some main entry point.
This is quite different from the normal application model of polling for
events.
You'll notice that ZWindow inherits not only from ZMessageLooper but
also from ZFakeWindow. You'll further notice that none of the pane
classes reference ZWindow -- they only know about ZFakeWindow.
ZFakeWindow's API has a number of methods. Some of them *must* be
overridden (GetWindowLock, GetWindowOrigin, GetWindowSize, etc etc). If
you provide implementations of these methods then any ZSubPane (or
descendant) instance will be able to work.
The trickiest thing to manage is ensuring that coordinate systems are
handled correctly, there is the notion of 'window' coordinates vs
coordinates handled by any particular pane. Window coordinates are (0,0)
at what the ZFakeWindow and and ZDCCanvas it returns consider to be
(0,0). If you look at ZWindoidPane and ZWindoid, the latter which
implements the ZOSWindow interface by mapping it on to the
ZSubPane/ZFakeWindow interface, you can see how GetOrigin for a
particular ZWindoid does not return (0,0) -- it returns the origin of
the windoid within the ZWindoidPane mapped to the real window, thus
taking in to account any scrolling that may have occurred. Similarly
GetWindowVisibleContentRegion, InvalidateWindowRegion etc all operate in
the window coordinate system. In the simplest cases there won't be
anything to worry about. But if you wanted to put ZooLib panes inside
(say) dialog manager user controls then the window origin would have to
take account of the user control's location if it were to use a tweaked
override of ZDCCanvas_QD to do its drawing.
Anyway -- ZFakeWindow provides the API that panes require to be able to
do their thing. Injecting events into panes is pretty straightforward,
mostly a matter of calling the same methods that
ZWindow::DispatchMessage calls.
It's late, so this is very cursory, but in summary ZooLib retains the
design features I put in place to support use in plugins. It's possible
that there are some gotchas, but probably not if you restruct yourself
to operating within a single window. If you need to be able to spawn new
windows there may be issues in their interation with the hosting
environment.
It would also be possible to make this work by implementing the
ZOSWindow interface, but I'd probably avoid it -- it brings in issues of
message queues and so forth that shouldn't be needed.
A+
--
Andrew Green mailto:ag...@em...
Electric Magic Co. Vox/Fax: +1 (408) 907 2101
|
