on-screen keyboard help

Posts: 1
Joined: 2010.07
Post: #1
Hi everyone. I am developing an OpenGL game for the iPhone and iPad and need to pop up an onscreen keyboard to get some input from the user. I have several years of experience with C++ and OpenGL but almost none with Objective C and/or Cocoa, so I am having more difficulty with this than I probably should Smile

After looking around on the forums and at the Crash Landing example I see that I need to create a UITextField object and use some delegate within the program to get events from it.

My question concerns the right way to get access to this stuff. In the crash landing demo the whole game is practically inside the main app delegate. In my case though, the main app delegate only has pointers to the window and glView. The glView then has a pointer to an ES2Renderer, which has a pointer to my actual C++ game class which contains all of my other game objects. It is deep inside there that I need to get input from the keyboard.

Is there a clean way to do this? The UITextField object seems to need a window and delegate during setup but I am far removed from having this information where I need it. It seems dumb to have to pass that info throughout the program or somehow pass my request for keyboard input back up the chain of objects. I don't suppose there's any way to do something like this with no other info?

string text = getKeyboardInput( );

Thanks for any suggestions.
Quote this message in a reply
Posts: 1,563
Joined: 2003.10
Post: #2
I've done something very similar, and it sounds like you're headed toward the same approach I took. Having a text field owned by the app delegate and communicating between the app delegate and game code to request showing the keyboard and pass key events down was the best way I could find to do it. It's imperfect, because unless you want to have UITextField actually display the text the user is typing, you have to tell it you're rejecting all input (by returning NO from -textField:shouldChangeCharactersInRange:replacementString: and -textFieldShouldReturn:), which makes the shift button behave differently than in other parts of the OS (since it doesn't think you inputted a character, shift doesn't get auto-canceled), but other than this quirk, it seems to work pretty well.
Quote this message in a reply
Post Reply