merlyn@digibd.com (Brian Westley (Merlyn LeRoy)) (10/28/90)
I'm updating ZoomBar to version 1.6, but I've noticed a bug in the cdev part that I can't seem to fix: if you pop up the hiermenu, then switch to another cdev, then back to ZoomBar, the popup menu will eventually cause a crash. It seems to think that the resources for the menu are still loaded and valid, and chokes on invalid data. I DeleteMenu() the popup stuff, and ReleaseResource() the handles, but that doesn't seem to make any difference. I check if GetMenu() is returning a null handle (which it isn't, even before it crashes). I'm using Think C 4.0.3, using their object-oriented cdev starter. Any help will be much appreciated. --- Merlyn LeRoy uunet!digibd!merlyn
resnick@cogsci.uiuc.edu (Pete Resnick) (10/29/90)
merlyn@digibd.com (Brian Westley (Merlyn LeRoy)) writes: >I'm updating ZoomBar to version 1.6, but I've noticed a bug in the cdev >part that I can't seem to fix: if you pop up the hiermenu, then switch to >another cdev, then back to ZoomBar, the popup menu will eventually cause >a crash. It seems to think that the resources for the menu are still loaded >and valid, and chokes on invalid data. I DeleteMenu() the popup stuff, and >ReleaseResource() the handles, but that doesn't seem to make any difference. >I check if GetMenu() is returning a null handle (which it isn't, even before >it crashes). I'm using Think C 4.0.3, using their object-oriented cdev >starter. Any help will be much appreciated. I had exactly the same problems. I did the following which seems to have cured it: 1. Set the "System Heap" attribute on the menu if you are reading it in from a resouce. I happen to have also check "Preload", but that depends on what you do. 2. Lock the MenuHandle before calling PopUpMenuSelect. I don't know why this should help in the least. PopUpMenuSelect should know enough to not move memory while the handle is unlocked, but I have found circumstantial evidence to the contrary. I have tested neither of these moves to see why exactly they work. I just know that my cdev no longer crashes. Anyone seen any method behind this madness? pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
gsm@mitre.org (Gio Marzot) (11/05/90)
(First post to net - please forgive any oddities) I have had a problem recently which is very similar to the one described in this thread.In short I am using the custom MDEF along with the TearOffMenus included with Think Pascal 3.0.1. and am further customizing the MDEF to support a sub-menu for one of its items. In the custom MDEF's ChooseItem routine I attempt to do this by calling PopUpMenuSelect. There is a brief flicker of the desired sub-menu then the dreaded error -108. At this point I tried the tactics outlined by Pete Resnick In article <1990Oct29.003508.8747@ux1.cso.uiuc.edu> resnick@cogsci.uiuc.edu (Pete Resnick) writes: > 1. Set the "System Heap" attribute on the menu if you are reading it > in from a resouce. I happen to have also check "Preload", but that > depends on what you do. > > 2. Lock the MenuHandle before calling PopUpMenuSelect. I don't know > why this should help in the least. PopUpMenuSelect should know enough > to not move memory while the handle is unlocked, but I have found > circumstantial evidence to the contrary. But to no avail. Any further insight by Pete or others is greatly appreciated. Thanks in advance. - GSM Responsibility for the views expressed here belongs only to myself and not to any organization.
merlyn@digibd.com (Brian Westley (Merlyn LeRoy)) (11/05/90)
[ following up my own article.. ] [ heir popup menu in cdev corrupts the menu structure ] resnick@cogsci.uiuc.edu (Pete Resnick) writes: > 1. Set the "System Heap" attribute on the menu if you are reading it > in from a resouce. I happen to have also check "Preload", but that > depends on what you do. > 2. Lock the MenuHandle before calling PopUpMenuSelect. I don't know > why this should help in the least. PopUpMenuSelect should know enough > to not move memory while the handle is unlocked, but I have found > circumstantial evidence to the contrary. I have tried all combinations of system heap/locked/preload, with no success. I looked at moire, which also uses a popup heir menu in a cdev, and noticed that it *didn't use menu resources*. It used strings which were made into menus with NewMenu(). I changed to this method, and the crashes stopped. ZoomBar 1.7 is on AppleLink and I will be submitting it to comp.binaries.mac today. Thanks to everyone. --- Merlyn LeRoy