Hi,
Can anyone help me out how to programatically handle the keystroke alt+ctrl+del in QNX?
Basically, I have to spwan a GUI application on this key press. Thanks in advance.
To get a key press like this, you need a widget that collects raw keyboard events. When you get the del you will have to check for alt and ctrl shifts. Since there are more than one alt key and more than one ctrl key, you will have to check for either unless you want a specific ctrl and alt.
Now there are some keys combinations that may be grabbed by the window manager first, so you may have to look closely at the docs as to how to handle this.
Thank you Maschoen for the solution. But, is there any way to handle the same with out Photon.
Also, my problem is increased because of the below scenario 
.
I have a main GUI application running on the Host PC . The alt+ctrl+del key press, needs to be handled by an application which is running in the background. As the keyboard is attached to the active application, please suggest an approach how to sniff the alt+ctrl+del key press from a background application.
Note: The main GUI application needs to be independent from other applications.
Anvesh,
Just how independent do these apps have to be?
The ideal way would be for the GUI app to send a message to the background app when the CTRL-ALT-DEL keypress is detected.
In fact that may be the only way you can do it as its possible (I don’t know for sure) that 2 apps can’t both get keystrokes.
Tim
Tim,
The problem is that I should be able to detect alt+ctrl+del key press even if my main GUI application is crashed/not running. That is the reason I’m looing for an independent application.
I’m looking atleast for a key board sniffer which would read key strokes what ever is the active application. This would be something like a Windows Security window popping up on WinXP.
.
What do you mean without Photon? Do you mean from a non-Photon program running inside of Photon, or a non-Photon program running in a system without Photon? The first kind of makes no sense, but the 2nd is not way you are saying below. I’ll elaborate.
If you want a “non-photon” program to collect CTRL-ALT-DELETE while photon is running, you still need a GUI program. A background invisible program can still be a GUI program. There’s nothing that says it has to show a window or even have one. It will need a region to collect the raw event.
If you want to collect CTRL-ALT-DELETE when Photon is not running, you will have to do some research. I’ve done this in QNX 2 and QNX 4, but I’ve not had a need in QNX 6. I believe the code that you want to focus on is devc-con, the console driver. There maybe something in the documentation about this too. Normally you get keys directly from the keyboard by reading stdin from a process running on the console. Since these are just bytes you will not be able to detect CTRL-ALT-DELETE. There may be an ioctl call or other feature that allows you to get more information. Let us know what you find out.
The keyboard is not actually exactly attached to the active application, though it may seem that way. You should read the architecture manual for Photon, but here’s the gist of it. A keyboard event is emitted by the keyboard driver. It travels through Photon space away from you. It doesn’t have an X,Y location initially, or alternatively it is everywhere. What gives it a location is called focus. This is where the idea of an active application comes in. Once that happens it has a location.
To do what you want, you can put a large region between the emitter and all windows. This region should be sensitive to keyboard events but transparent to them. The process that owns this region will get the events. It will have to check each one and ignore the ones that are not CTRL-ALT-DELETE, but respond if it is.
Sure they can. They’re not keystrokes, they’re key press events.
I wanted to say something about a “crashed” process. If a process is in a loop, you can setup a method to detect this and kill it. If a process dies, the creating process can be informed. In any event, you can restart it. This only becomes untenable if the conditions that caused the process to loop or crash still exist, but this should not be the case with a GUI program.