CompuServe Thread

Darren: I think the example in Think Ref is bad. In main(), item 3 is set to be a userItem with draw procedure UserProc. In UserProc(), the list is built and drawn into the rectangle properly, and then item 3 is set to be a userItem with draw procedure theList (???). But theList is a ListHandle! Your crash is occurring when the dialog is moved or obscured because the Dialog Mgr tries to update it, including calling the userItem procedure, which happens not to be a procedure in this case. Illegal instruction is not a surprise. Instead, when creating the dialog, go ahead and build the list right then, saving the ListHandle in a global, and set the item to userItem with a draw procedure that does nothing but GetDItem() / FrameRect() / LUpdate(). If the item rect is fixed or in a global, you don't even need the GetDItem. The first call to ModalDialog will force the update, and the list will be drawn properly and remain stable. Steve

Darren, Even if the instructions in THINK Reference were correct, it's only half the solution. You need a user draw procedure (the easy part). You also need a dialog filter proc (ther harder part). (The following is a commercial announcement…) The fastest and easiest way to implement a list in a dialog is to use AppMaker. You just point and click to design your dialog with a list, a popup menu, or any of the standard dialog elements. AppMaker creates the appropriate resources, then generates excellent source code to implement your design. You can read the code to learn Mac programming techniques. A demo version of AppMaker is in MacDev, Lib 13, keywords "AppMaker" and "Demo". Spec Bowers Bowers Development (developers of AppMaker)