On Dec 30, 2013, at 5:34 PM, Alex Hall <mehg...@gmail.com> 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. > 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. > 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 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; 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. --Andy _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
