How do you get a key from an EVENT_KEYPRESS ?

[hendra@ngms]

If I do a

QueueUserEvent (EVENT_KEYPRESS, panel, someCtrl);
GetUserEvent (WAIT, &panel, &eventCtrl);

I should get a return from GetUserEvent when either an EVENT_COMMIT or EVENT_KEYPRESS occurs.

Questions:
1. How do I determine which event occurred?

2. How do I find out what key was pressed? There does not seem to be a way to call GetKeyPressEventCharacter (eventData2); because GetUserEvent does not return eventData2.

[Ryykker]

Something like this:

In a callback:
switch (event)
{
case EVENT_KEYPRESS:
if (icon)
{
switch (eventData1)
{
case VAL_UP_ARROW_VKEY:
dy = -1;
break;
case VAL_DOWN_ARROW_VKEY:
dy = 1;
break;
case VAL_LEFT_ARROW_VKEY:
dx = -1;
break;
case VAL_RIGHT_ARROW_VKEY:
dx = 1;
break;
default:
break;
}...............
...................

[MJF]

Is there a particular reason why you are not using a control callback here?

I am a bit confused as to what you are trying to accomplish with this approach.

Determining the event type is simple. The return value for GetUserEvent will be one of the following things:

0 No event.
1 Commit event occurred.
1,000-10,000 Event queued by QueueUserEvent.
Negative values indicate that an error occurred.

Remember that when you press a key, you may get several event notifications for each key stroke. These can include EVENT_VAL_CHANGED and EVENT_COMMIT in addition to EVENT_KEYPRESS

If you get an EVENT_KEYPRESS message, you should be able to use the following functions to determine what the key was:

GetKeyPressEventVirtualKey()
GetKeyPressEventCharacter()
GetKeyPressEventModifiers()

[hendra@ngms]

Rykker, you missed it. This is not a callback situation. It is the wait loop at the end of a modal dialog function. Thus, the GetUserEvent function call.

There is no callback to pass the eventData2 variable, which contains the key.

There appears to be some disconnect between getting the event from GetUserEvent, what the event is, and the key actually pressed.

[MJF]

So my question remains... why not use a control callback?

It will make your life a lot easier than all this chicanery of using a GetUserEvent loop.

Trust me on this one, using the event driven model with callbacks is so much simpler to code. The first virtue of a programmer is laziness. In other words, when there is more than one way to do something, choose the easy way and reuse all the code you can.

[hendra@ngms]

MJF,

In the last little while I've come to understand what QueueUserEvent really does, which is not what I wanted.

You are probably quite right about using callbacks. What I'm doing here, relates to my other thread on resizing message/prompt dialog boxes. In particular this has to do with re-creating the GenericMessagePopup, and providing for the keypress events for the three buttons and the string box. Since the panel is created on the fly, one or more callbacks would have to be installed after the panel was created.

I've done keypress event recognition on panels before, specifically responsding to function key presses, so if I can figure out how to install the callback, the rest should be easy. The remaining issue is routing execution from the callback, back to the end of the popup function, in order to close out the dialog box. That might best be worked using the QueueUserEvent function, by posting a series of 1000+ numbered events, which have the meaning of which key was pressed.

[MJF]

I still think you are better off using the callback model. The way you are going about this just seems like an inordinate amount of trouble to me.

I think that all you really need to do is write a generic callback for each panel and control type you will have on your popup panel. When you create the panel, you call InstallPanelCallback() or InstallCtrlCallback() as needed. It's really quite simple to do this and things will work just like any other callback function you would normally use. You can use the same callback function for more than one control or panel, I do that all the time.

In your callbacks you would examine the panel and control handles to get the context of where the event came from. You would then use a switch statement to determine the event type and process it appropriately.

When you discard the panel, you don't have to do anything to discard the callbacks, CVI will clean that up for you automatically. Remember what I said about laziness, I really do recommend this approach as the easy way to go.