Re: NSView subclass does not seem to start
Re: NSView subclass does not seem to start
- Subject: Re: NSView subclass does not seem to start
- From: Alex Hall <email@hidden>
- Date: Tue, 31 Dec 2013 09:13:56 -0500
On Dec 31, 2013, at 12:45 AM, Andy Lee <email@hidden> wrote:
> On Dec 30, 2013, at 5:34 PM, Alex Hall <email@hidden> wrote:
>> Anyway, the problem remains that I need to capture keystrokes (and eventually mouse movements) in a subclass of NSView, but nothing seems to happen. Since this is an audio game, there is no need for any UI controls to be drawn - I need only the keyboard/mouse event handler. Therefore, my view has no UI controls, it is merely a rectangle, or should be, with an origin of (0,0). Below, and I apologize in advance for how long this will be, I have laid out the path taken to get the view on the screen. Where I feel it is necessary, I have given source code. Note that I still have the main XIB file Xcode generated. Perhaps I should remove it, I don't know yet.
>
> I would advise against removing it. Even if you choose to create everything else in code, your app should have a main menu so that it can provide standard menu items like "About" and "Quit". Also, MainMenu.xib connects your app delegate to the application object. I can think of no good reason to remove it, even if you never use nibs elsewhere.
Okay, it will remain then. I just was not sure if something might have been conflicting.
>
>> 1. My app runs, and the AppDelegate's applicationDidFinishLaunching method is called automatically. In here I create an AITGameController object,, which does the lion's share of the work. I then call this object's initGame and startLoop methods, the first to set up the game and the second to begin the game loop that will drive the app.
>
> I'm a little concerned about this game loop. Cocoa already provides something called a run loop that is entered after your application launches and initializes. You *generally* don't create a loop of your own to process events. Rather, as you have done, you override methods like mouseDown:, keyDown:, and keyUp:. Those messages will be sent to the appropriate object as they occur -- be it the first responder or something else. So I wonder if, because you are entering your own loop, you are never entering the run loop, which would explain why events never get logged.
Sorry, I should have specified - I'm so used to seeing it I didn't even think. The loop is based on an NSTimer and is used to process sound position updates. Basically, I use it to pan sounds and draw updates. I'm not putting key management in there. Here's the setup for it:
> [self setGameTimer:[NSTimer scheduledTimerWithTimeInterval:1.0/30 target:self selector:@selector(gameLoop:) userInfo:nil repeats:YES]];
The docs indicate that this automatically adds itself to the app's mainLoop, so I should be okay here, unless I've misunderstood something (a distinct possibility).
>> 2. The AITGameController's init method sets up the AITViewController, whose source is below. It then sets up the AITAudioMenu (my NSView subclass, which is supposed to be logging keystrokes). Now we get into the fun part, so here's the code I am using:
>>
>> //from AITGameController > init
>>
>> [self setViewManager:[[AITViewController alloc] init]];
>> NSRect windowSize=NSMakeRect(0.0, 0.0, 200.0, 150.0);
>> NSWindow* mainWindow=[viewManager makeWindowWithRect:&windowSize style:NSTitledWindowMask|NSMiniaturizableWindowMask];
>
> I notice makeWindowWithRect:style: takes an NSRect as its first argument, so you should be passing windowSize and not &windowSize. Unless this is a typo in your email, I would have expected a compiler error.
I have no idea how that got in there. :) In the code I'm working with, there is no &. It must have been left over from when I had it in my head that NSRect needed to be passed by reference and was using asterisks all over the place. I'm not doing that anymore, don't worry.
>
>> I hope all this makes some sense. I think what is tripping me up is trying to manage windows like this while IB is still being used, but I really don't know. Thanks for any help, and if anyone from Apple is on here: anytime you guys can make IB fully accessible, I and other budding developers would very much appreciate it. Yes, bug reports have been filed. :)
>
> I think it is not only okay to keep the main nib in the project, but as I said I would advise against removing it. However, something else occurred to me that might be coming from MainMenu.xib. The standard main nib provided by Xcode has a window in it, which is pointed to by a property of the app delegate. I wonder if that window is made the key window *after* your window is, and is therefore stealing your keyboard events. I wouldn't *think* so, but just to remove the possibility I would get rid of that window altogether. In your case the simplest way to do that is to set the app delegate's window property to nil. That is, in applicationDidFinishLaunching: you could add as the first line:
>
> self.window = nil;
Good thought, that did not seem to fix the problem. I call [self setWindow:nil] as my first line, but the keyboard events still fail to be logged.
>
> One more suggestion. After the program has launched, you might want to see if everything is what you think it is. Maybe you could add an action method in the app delegate that prints out (using NSLog) the current key window, and its first responder. Then connect a menu item to that method. Launch the program and try to invoke the menu item. If your problem is the "loop" thing I wondered about earlier, you won't be able to invoke the menu item. If not, you should get either a sanity check that you have set up the window and view correctly, or a possible indication of where the bug is.
I'll have to re-visit Charles' sample code to be sure I can do this one right as I've never done this before. Perhaps a button would work just as well? It seems less prone to errors from me while setting up. It is a great idea though, and will let me be sure my view is getting drawn in the first place. Thanks for your response.
>
> --Andy
>
Have a great day,
Alex (msg sent from Mac Mini)
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden