Ok,
I have identified the problem and can see there is a potential source of
confusion in using the monobjc bindings. The root of the problem is that
the borderless windows was not the key window. In objective-c, this can
be achieved by adding:
-(BOOL)canBecomeKeyWindow
{
return YES;
}
to the custom window class i.e. this objective-c message has been
overridden in the subclass of NSWindow.
Now, the monobjc guide to subclassing
(http://www.monobjc.net/index.php?page=subclassing), gives an outline of
using the ObjectiveCMessage attribute for C# methods. However, the
"canBecomeKeyWindow" property is implemented in Monobjc.Cocoa.NSWindow
as a C# virtual property - the ObjectiveCMessage attribute does not
compile with properties.
So, in my original code, my NSWindow subclass had overridden the
CanBecomeKeyWindow property but had not applied any attributes to it. I
believe this was like, in objective-C, having an NSWindow derived class
without the "canBecomeKeyWindow" message overridden - the visible result
is the same.
So, to get my C# code to work, I have added a new method to my C#
NSWindow derived class:
[ObjectiveCMessage("canBecomeKeyWindow")]
public bool CanBecomeKeyWindowMethod()
{
return true;
}
So, this bypasses the CanBecomeKeyWindow property in the base class but
it does work.
Can anyone give me some comments or feedback as to whether I am doing
the right thing here?
Thanks,
Steven
-----Original Message-----
From: Steven Spencer
Sent: 20 December 2010 16:33
To: [email protected]
Subject: RE: [[email protected]] IKImageBrowserView view options
keys
Ok,
After further investigation, I have tracked this down to a problem with
Cocoa, not Monobjc. The problem is that I have a borderless window
(initialised with the NSBorderlessWindowMask style) - this seems to be
causing the issues with the IKImageBrowserView. I have recreated this
using Objective-C and XCode.
Steven