Hello all, I replied last night, but my message got held up because it was too large. If it makes it through, please disregard it. The problem was that my NSWindow was not a property of my class, but rather a method-level variable. It works now. Thanks for all the help! On Dec 31, 2013, at 12:45 AM, Andy Lee <ag...@mac.com> wrote:
> 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 > Have a great day, Alex (msg sent from Mac Mini) mehg...@gmail.com _______________________________________________ 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
