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: users@lists.monobjc.net
Subject: RE: [us...@lists.monobjc.net] 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




Reply via email to