I finally solved the problem. Since I still don't understand, I post
the solution with the hope that someone can explain.
Since the problem appeared to occur with the close or quit menu item,
I checked the EnableMenuItems events.
In one of them, in a class, I had:
MsgBox "A" 'To debug
EditFindNext.Enabled=MyCurrentSearch<>nil and Searchable
#if TargetMacOS then
EditAddressBookExport.Enabled=SelectionCount>0
#endif
MsgBox "9" 'To debug
When I "debugged" the application, I only saw the first message (even
when there was no freeze, the "9" never appeared, like if the
execution flow stopped in the middle).
I changed "#if TargetMacOS then" to "#if TargetCarbon then", since
the freeze didn't appear in the carbon build and it works for classic
too. Amazing!
(EditAddressBookExport is just a regular menu item).
Often, I see the symptom described here: the method is not executed
through its end, magically, without return or if statement.
I don't understand why. I assume it's a compiler bug, right?
Le 15 juil. 06 à 04:29 Matin, Andy Dent a écrit:
On 15/07/2006, at 8:53 AM, Arnaud Nicolet wrote:
When the "window(0).close" method is called, the computer freezes
(well, at least classic freezes)....
Window(0).close
MsgBox "Test"
and I actually get the "Test" message, so the problem is after the
window has successfully closed and no code remains to be executed,
confusing!
Your destructors all remain to be executed, for any members of the
window or static variables.
Try putting breakpoints or system.debuglog messages in all your
destructors and adding destructors to contain these if you don't
have any, so you get to break at the point where member variables
are being destroyed.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
