Does anyone know of a third-party haxie (input manager, etc.) that
when loaded into an application hijacks the delegate of NSWindow
instances? ...something that replaces the window's delegate with one
of its own objects that presumable forwards messages onto our
delegate.
We happen to have some debugging related assert code like the
following (in a class method) that validates that the delegate of a
window is of an expected class. These asserts made it into a release
version of our of product and we are getting runtime exception reports
from the field cause by this assert.
NSAssert([[someWindow delegate] isKindOfClass:self], @"incorrect
delegate class");
We are fairly sure that the pointer to the window is valid and that
the window object is still valid because of code before this point
interacts with the window instance without issue.
Basically we are trying to reproduce this issue in house and so far
haven't been able to cause it. It appears to only affect a few
customers and those affected consistently hit the assert (still trying
to contact affected customers).
-Shawn
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
