Menu Sharing Toolkit 4.1
Menu Sharing Toolkit 4.1Yet another version of the Menu Sharing Toolkit. This time no more crashes in client apps if Frontier crashes
by Doug Baron, dougb@chilehead.com
I've just spent two days updating the Menu Sharing component protocol. Fortunately, thanks to Jasik's debugger, I'm confident that we have a new state of the art.
ftp://ftp.scripting.com/userland/menuSharingToolkit4.1.sit.hqxThe fundamental change (and the motivation for the update) is to allow clients to cleanly handle a server (i.e. Frontier) crash. Along the way we got a new feature that you might be interested in. (I know that Rich Siegel wants it for BBEdit.)
The new features are in effect only if the new SDK is used and Frontier 4.1 or greater is running. Here are the changes:
- If the menu sharing server crashes, the SDK will now clean up safely and remove the shared menus.
- There are two new optional callbacks: insertmenus and removemenus. The new calls SetMenusInserterCallback and SetMenusRemoverCallback can be used to provide your own routines. They both take a hdlmenuarray.
- Menus are now allocated in the client's heap zone. I don't know whether or not this makes any difference, but I thought it might avoid potential compatibility issues.
The new SDK is entirely backward compatible with older versions of Frontier. The matching changes in Frontier are entirely backward compatible with older versions of the SDK. I've tested the new SDK with both a 68K and PPC build of MenuSharer, running with both 68K and PPC versions of Frontier, 4.1 and 4.0.1. It works.
Here's what I'd like you to do:
Build the new SDK into an app you're using or otherwise have time to test with. OSA Menu would be a good choice. Verify that nothing is broken; all should be as it ever was.
When the next Frontier beta comes out (4.1b2), again verify that everything still works. Additionally, confirm that you can terminate Frontier unnaturally and have the menu sharing client live to tell the tale.
A war story
Here's a problem I encountered. When forcing Frontier to quit, ExitToShell apparantly leads to the disposal of many (all?) handles allocated in the process. Even though I started creating the hdlmenuarray in the client's heap, even with the client's A5 set, it would be disposed.
The only way I could get the hdlmenuarray to survive a server crash was to have the client make a copy for itself at the appropriate times. (The menu handles hanging off the array may or may not be valid, but all the client needs are the IDs to remove the menus.) Do you know anything about this? It suprised the hell out of me.
Thanks!
Doug
|
This page was last built with Frontier on a Macintosh on Fri, Aug 16, 1996 at 2:56:18 PM. Thanks for checking it out! Dave |