On Jul 21, 2006, at 11:46 PM, Andy Dent wrote:
On 22/07/2006, at 9:10 AM, Thomas Cunningham wrote:
Interesting. This seems to clearly show that the crash is an Apple
problem
in Foundation framework, not Rb's.
no it doesn't, unless you're vastly better at interpreting logs
than I (something I humbly admit is possible ;-).
What is far more likely is a bug in RB code similar to that
described in the following, which took me all of bout 30 seconds
curiosity looking at the logfile and Googling
NSColorPanel crash
http://wilshipley.com/blog/2005/07/self-stupid-init.html
"...if you allocate a second NSColorPanel, you've done wrong. Your
code is not correct. FURTHER, if you just blithely go on with your
init method after the superclass has returned a different object,
you are likely to leak objects at best and crash at worst...."
REALbasic uses the Carbon APIs currently. This means we don't
directly use NSColorPanel.
or, plausibly
http://www.abisource.com/changelogs/2.2.6.phtml
"Fix" crash to do with NSColorPanel not noticing its target has
vanished (MacOSX, bug 8637)"
Same here.
or, talking about Carbon and Cocoa integration:
http://www.archivesat.com/wxWidgets_Developers/thread252392.htm
"...Also, we need to be sure to NEVER EVER call a
GetColor routine (along with PickColor or NPickColor) or it will crash
the app."
Again, we don't use any Cocoa calls. We only call GetColor.
Are there haxies on these machines experiencing the crashes? I know
many haxies are written utilizing the Cocoa frameworks. Perhaps
there's something like that going on. Or, perhaps there are plugins
that might be working with Cocoa.
HTH,
Jon
--
Jonathan Johnson
[EMAIL PROTECTED]
REAL Software, Inc.
_______________________________________________
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>
