Re: NSWindow keyWindow problem (HELP)
Re: NSWindow keyWindow problem (HELP)
- Subject: Re: NSWindow keyWindow problem (HELP)
- From: Thierry Passeron <email@hidden>
- Date: Sat, 14 Jan 2006 22:48:51 +0100
Ok thanks for the tips Joar, but in fact I cannot make ANY kind of
window programmatically a keyWindow ordered front.
Here is an other example:
#include <AppKit/AppKit.h>
#include <Foundation/Foundation.h>
@interface MyWindow: NSWindow
{
}
- (BOOL)canBecomeKeyWindow;
- (void)keyDown:(NSEvent *)e;
@end
@implementation MyWindow
- (BOOL)canBecomeKeyWindow
{
return YES;
}
- (void)keyDown:(NSEvent *)e
{
NSLog(@"Keydown");
}
@end
int main()
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
[NSApplication sharedApplication];
NSRect windowShape = NSMakeRect(0,0,200,200);
MyWindow * w = [[[MyWindow alloc] initWithContentRect:windowShape
styleMask: //NSBorderlessWindowMask
NSTitledWindowMask
|NSClosableWindowMask
|NSMiniaturizableWindowMask
backing: NSBackingStoreBuffered
defer: NO] autorelease];
[w makeKeyAndOrderFront: w];
//[NSApp runModalForWindow:w];
[NSApp run];
[NSApp release];
[pool release];
exit(0);
}
It seams that makeKeyAndOrderFront: doesn't work at all... Even after
clicking into the window, keyboard events are not intercepted by the
Custom NSWindow object.
Even if you replace MyWindow by NSWindow in the main() so that you
will instanciate an NSWindow genuin object, ... well it doesn't work
either.
I'm depressed ! :(
Can anyone tell me how to make an NSWindow (without IB and Nib files)
keyWindow and ordered Front. So that the window will intercept
keyboard events.
For the moment I don't even think about the NSBorderlessWindowMask. I
just try to get it work with standard windows.
Best regards,
Thierry.
Le 12 janv. 06 à 22:31, j o a r a écrit :
On 12 jan 2006, at 22.15, Thierry Passeron wrote:
// Give keyborad focus to the window
[w setInitialFirstResponder:v];
You're not giving the window keyboard focus here, you're setting
the content view of the window to be the first responder in the
window. Seems a bit redundant.
// Set the responder chain to include the controller
[v setNextResponder: [[[MyController alloc]init]autorelease]];
To me there are two problems here. The first is a proper bug -
you're creating an autoreleased controller that will just be
deallocated at the end of the event loop. It's not inserted into
the view hierarchy, so there is nothing holding on to it. The
second problem, IMO, is that it's backwards to set a subview to be
the next responder of a parent view. In general, the responder
chain starts with some control in the window, and goes up through
the view hierarchy to the window, window delegate, et.c.
Another suggestion: Start out with regular controls. Don't add a
custom content view, and use a regular text field in the window.
Once you've verified that it works, switch out the regular controls
to your custom ones one by one. Much easier to spot your errors
that way.
j o a r
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden