FB II Compiler
Know what to do if menus don't display correctly
1- Delete Resedit AND the Preference file (maybe corrupted);
2- Reinstall Resedit AND rebuild the desktop (house cleaning);
3- Find your backup resource file !
Forget about fixing your 'damaged' resource file.
Never attempt to copy a MENU or MBAR from your damaged file to a 'clean' file.
...or hell will come loose...
Resedit has a known bug easy to bypass:
NEVER WORK WITH RESEDIT IF THE CLIPBOARD IS EMPTY !!!
Repeat 3 times... ;-)
Everytime you open a resource file, select and copy something to the clipboard.
For example, select icl8 and copy. That's it.
No more crash when trying to open a PICT;
No more trash and junk into my menu bar;
Not much, but I hope it helps.
This can happen if the menu is marked as purgable.
In Resedit, do Get Resource Info and uncheck the "Purgeable" checkbox.
One other thing to check is that the MDEF ID is 0 and not some strange number. In ResEdit, open the menu resource in question, then choose Edit Menu & MDEF ID..., make sure that the MDEF ID is 0.
We've got two possible problems here:
1) Your app is overwriting blocks in the application heap.
2) Your app is overwriting the resource file map.
#1 is more likely, so I'll start there.
Debug 1) Problems usually occur if you overwrite the first two bytes of the handle. This means that the string count is getting set to zero. Use the following steps at a point in your program where you are sure that the STR# handle is OK. I would first try to track it like this:
a. OSErr = FN HLOCK(strHndl&) 'Lock the handle when you're sure it won't change
b. REGISTER(D6) = [strHndl&] 'move it into a register
c. CALL DEBUGGER
When you enter MacsBug, you'll see the first byte of the STR# handle block addressed in register d6. Type that number into the following statement. (ie replace the x's with the hex number.)
A side note: Step Spy (ss) is a very touchy command in MacsBug. You have to turn off the FB debugger and probably most of your extensions to make it work. You computer will run _very_ slow. It can also freeze up. But in the end, it should stop as soon as your program changes the element count.
...and hit hit return until you get a blinking insertion point. Now read from the bottom up, in the right hand column. (You can use the up arrow to scroll back if necessary.) You want to keep moving until you see something that looks like one of your function names. (FN myFn_Name would appear as MYFN.NAME, but you get the idea.) This is the name of the function that changed the count.
Debug 2) You might be able to use FB's debugger to do some tracking. Move the byte count into a global and examine the first string in the array by saving it as a global. It will probably be easier to build a function and to call this repeatedly as your program runs.
Call this function until you narrow down the error. If you put it where you know the STR# is valid, then at the end of the program, the second hit on the debug function will probably show that the STR# is bad. Try moving the two calls closer together until you have the problem down to one line.
LOCAL FN debugStr(strID)
gSTR$ = STR#(strID,1)
gElemCount% = FN countSTR(strID)
REM: at this point, the string count and first element will
REM: be visible in your globals window.
Debug 3) Someone called me last week and said that he spent two days chasing down this kind of bug. He found the problem in a FOR/NEXT loop where he did the following:
sz& = FN GETHANDLESIZE(hndl&)
FOR x& = 0 to sz& : REM _big_ mistake here
The problem here is that the handle has a length of sz& bytes. Since the loop has to start a the [hndl&] + _zero_ bytes, it should have ended at sz&-1 bytes.
sz& = FN GETHANDLESIZE(hndl&)Good Luck,
FOR x& = 0 to sz& - 1 : REM Fixed!