01-19-2011 02:42 PM
In running my app on my device, I have observed a peculiar and very unexpected behavior:
Keypad.getHardwareLayout() on the Torch returns a different value depending on whether the keyboard slider is extended. I don't yet have the actual value returned when it's closed as I won't be near a debugger for a few hours - and I don't think I see the behavior on the Torch - , but it's *not* Keypad.HW_LAYOUT_39-- the value returned when keyboard is extended.
The 6.0 documentation specifically says it returns the device hardware layout - not "current layout".
I was wondering if anyone else can confirm seeing similar behavior?
01-19-2011 02:51 PM - edited 01-19-2011 02:52 PM
That makes sense to me. I noticed on the simulator my keyboard hotkeys stopped working when I close the keypad. i.e. typing keys on the PC keyboard only work when the keypad is extended. I wasn't worried about it as you can't type on it when it not extended anyway.
In either case, I trap the send and end keys by keycode and that works regardless. I also use keycode to trp the space bar and that stops working when you close the keypad. So it seems they just ignore the kaypad keys when it's closed.
Now what about this Blackberry 9105? What a bizare bit of hardware. Totally unique kaypad. Totally useless for apps.
01-19-2011 11:00 PM
The problem is that I make a lot of custom key-mappings available based on the actual hardware layout. This finding (confirmed in the debugger - when closed it returns one of the virtual keyboard consts) Ultimately this means that I'm going to make the mappings available incorrectly and/or set up the wrong mappings based on whether the keyboard is open or closed. Since this API can't be relied upon to return the actual hardware information, I'm in a bit of a quandary. There's no method available by which I can determine the actual, physical hardware on the device.
The closest I can think of is to check DeviceCapability.isPhysicalKeyboardAvaible if I receive a touchscreen const from getHWLayout -- but even if that returns "true", I have no way of knowing what that layout the physical hardware is. I can make an assumption tha **bleep**'s 39 key - -but that's really only guaranteed for this one device. Who know what they'll release tomorrow...
For the 9105 ITUT layout (introduced in 5.0 but we didn't get a const until 6.0.. oddly...) I've just made it so that every key on the keypad can be mapped to a custom function.