From: Andrew G. <ag...@em...> - 2002-09-16 17:49:22
|
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 |