PostDeferredCall: any documentation on which control-type/event-type combinations requires it?

[Jumper_Bones]

Before there is any misunderstanding, let me first explain that I know how to use PostDeferredCall, and I also understand *why* I need to use it.

So my question is two-fold:

A.) is there any documentation on which control-type/event-type combinations require it (to avoid having to always figure it out empirically, that is)?

or

B.) is there a way to always get around it, either right now in existing versions of CVI, or with some internal tweak inside a future release of the CVI libraries?

For example, in a table control, if I set up its callback to use GetActiveTableCell in one or more of the event-branches, I would need to pair the PostDeferredCall function along with it for an EVENT_KEYPRESS, but not for EVENT_ACTIVE_CELL_CHANGE, in order to get the actual active cell that I really want to operate on. Similarly, EVENT_COMMIT doesn't need it but EVENT_LEFT_CLICK does.

I can infer that this event-handling discrepancy has to do with the control's focus (am I correct?), but is there any way to permanently over-ride this? If so, think of the coding and debugging time we could all save, especially for the complex controls like tables and trees...

For example (as a possible answer to my question "B" above), could we say that if you force the control to have focus when you mouse-hover over it (using the new CVI 8 "EVENT_MOUSE_POINTER_MOVE" event in the control's callback) before you mouse-click or keypress any succeeding event into it, that you can therefore disregard the need to use PostDeferredCall in your callback?

(Yes, I'm sniffing for tricks from CVI power-users again!)

In a similar topic, it seems to me that is not always obvious which control-events are "swallowable" unless you dig through the CVI help. But I do admit I can usually find this info if I really look hard enough.

I searched the CVI help and forums already looking for the answers to these. Maybe what we all need is a look-up table in the CVI Help that collects all this event/control info in one place. Just a thought...

Thanks in advance if you can pass along what you know...

JB

[Guillaume Dargaud]

> Before there is any misunderstanding, let me first explain that I know how
> to use
> PostDeferredCall, and I also understand *why* I need to use it.

A place where it's needed that I discovered recently is in a VISA interrupt
handler:
static ViStatus _VI_FUNCH UsbHandler(ViSession instr, ViEventType etype,
ViEvent usbEvent, ViAddr userhandle) {...}
You cannot use SetPanelAttribute or it will lockup the program (at least if
you change the panel title).
--
Guillaume Dargaud
http://www.gdargaud.net/
"If it works, leave it alone - there's no need to understand it. If it
fails, try to fix it - there's no time to understand it." - Bill Pfeifer.

[LuisG]

There is no hard and fast rule for when you need to use PostDeferredCall. It really depends on which action you are trying to perform when you receive the event, so it's not feasible to document this in the form of a table, or a list.

The most generic statement I can make is that low-level mouse and keyboard events are typically sent to your callback before the control receives those events -- this is so that you can decide whether or not to swallow the event. So if, for example, in an EVENT_KEYPRESS you want to perform an action in a tree that depends on the tree having been notified of the keystroke's existence, you'll have to use a PostDeferredCall so that you can wait for the tree to process the keystroke first. It isn't really because the tree doesn't have the focus, although the reason that the tree doesn't have the focus is the same: the tree doesn't know about the keystroke, so it hasn't grabbed the focus yet. So, to answer your hypothetical workaround: no, finding a way to give it the focus inside the callback would not work. Yes, you can give it the focus, but that won't result in the active row changing (for example) until you leave the callback function.

I know this can be a bit confusing. Please feel free to ask further, if I didn't make any sense.

Luis