On 24-Apr-05, at 7:15 AM, manikandan thangavelu wrote:
With some ways(applescript and systempreference expose pane and
through some bundles )being there for these expose shortcut keys,i can
manage to choose one that suits the need.But rightnow,i was stuck with
some other shortcut keys.
I am using setSystemUIMode for the kiosk like application.I have used
the disable process switch option.But i happened to come across that
the short cut keys Option-F14,Option-F15 etc.are not blocked.Pressing
this shortcuts brings the Dispaly and Sound Panes of system
preferences in front along with the dock and thus breaking my kiosk
like application.Is there way of disabling these shortcut keys.
I tried the Carbon and Cocoa references below and wrote a simple
Cocoa/Java program using NSApplication to intercept my test-app's event
queue. The result was keyboard events for my app's window (the
key-window in Apple's terminology) received keyboard events but did not
receive Expose or volume-control key-presses. What I could do with
Java/NSApplication was hide other app's. although this is trivial to do
with NSApplication it becomes important when you use 'setSystemUIMode'.
Looking at OS X's documentation the next level below Cocoa and Carbon
is the IOKit and device-drivers. OS X's devices are classed into
families; one family is the Human Interface Devices (HID). OS X has a
HID toolkit and some example code that manipulates HID devices:
The example code checks for game-pads (kHIDUsage_GD_GamePad). I changed
this to keyboards (kHIDUsage_GD_Keyboard); the program ran on my
PowerBook and yielded a result. Take a look at the example code; the
function 'MyTestEventInterface'. This function manipulates the keyboard
queue.
What wasn't clear to me was if this keyboard queue was system-wide or
application specific.
IMHO; depending on your needs to produce a kiosk app you may have to
customize OS X on several levels e.g. Java app, HID toolkit etc .. to
gain the control you desire of the OS. setSystemUIMode is a good start
but keyboard-control may require more effort. Given the amount of
documentation involved and the complexities of User Interaction perhaps
a call/e-mail to Apple's developer support would be a good investment?
This problem must have been experienced by others who wanted
kiosk-functionality; maybe a different Apple mail-list could help?
These references cover event handling in Cocoa/Java and Carbon:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
