prioritization of callbacks

[mzimmers]

Hi, all -

I'm chasing down some final issues with my app. Perhaps a pic will help:

The "PAUSE" button is a toggle button. The "CLEAR" button is a command button.

The purpose of the "CLEAR" button is to erase all plots from the graph. If the app is running, the "CLEAR" button puts it into the paused mode (stored in a global variable) before clearing.

There's no other way to say this: the "CLEAR" button works...most of the time. Sometimes, it shows as depressed, but no action is taken...UNTIL I move the mouse. Then, the clear usually takes place, though sometimes, one plot will sneak through and be shown.

So...this has me wondering about the prioritization of callbacks. I've read the help page on the precedence of callbacks (though I don't really understand it), but I'm wondering more about the interrupt levels of command callbacks. Do they simply execute in the order they're queued, or is there some prioritization behind the scenes? 

A related question, about swallowing events. From the help:

Only user input, such as mouse click and keypress events, and commit events can be swallowed. If swallowed, no more callbacks are called for that event

Does that mean no more callbacks ever? If so, how does one undo a swallow?

Thanks for helping. Sometimes the documentation is just a little bit lacking.

[Wolfgang]

Hi,

1. Depending on your callback duration you might want to consider ProcessDrawEvents (), maybe this helps to solve your 'sometimes' issue
2. Swallowing of course does not mean forever, just for one user action: Imagine that you press one of your buttons, this will result in several calls of the corresponding callback routine, e.g. for COMMIT, LEFT_CLICK, LEFT_CLICK_UP, GOT_FOCUS,... You can nicely watch this in the UI editor (choose the Operate Tool and watch the Status bar).

If your callback routine swallows the events it will be called just once (per user action). You can also investigate this behavior using breakpoints in your callback routine.

Good luck!

[mzimmers]

Hi, Wolfgang -

Regarding the use of ProcessDrawEvents(), here's the code for my clear button CB:

#include <ansi_c.h>
#include <userint.h>

#include "globals.h"
#include "qamscopeii.h"
#include "startbutton.h"

int CVICALLBACK ClearConstCB (int panel, int control, int event,
		void *callbackData, int eventData1, int eventData2)
{
	static	int rc;
	static  int count = 0;
	static	char	str[80];
	switch (event)
	{
		case EVENT_COMMIT:
			// telltale for debugging
			sprintf(str,"Entered ClearConstCB %d.\n", count);
			SetCtrlVal (g_hmainPanel, PANEL_MAIN_OUTPUT_CONSOLE, str);
			count++;
			
			// set the global state variable to PAUSED.
			g_runState = PAUSED;
			
			// set the value of the toggle button to off.
			rc = SetCtrlAttribute (g_hmainPanel, PANEL_MAIN_TOGGLEBUTTON, ATTR_CTRL_VAL, 0);
			
			// clear the graph's plots.
 			rc = DeleteGraphPlot(g_hmainPanel, PANEL_MAIN_CONST_PLOT, (-1), VAL_IMMEDIATE_DRAW);

			break;
		case EVENT_RIGHT_CLICK:

			break;
	}
	return 0;
}

 Does it seem to you as though ProcessDrawEvents() is necessary here? I'm trying to make all my CB routines so short that such a call would be unnecessary. (I'm not trying to make them short for that reason, but it seems like a side benefit.)

So, if I understand swallowing events, the purpose is to eliminate any unneeded further event callbacks once the app has the one it "wants?" Is that correct?

Thanks.

[Wolfgang · Accepted solution]

---

@mzimmers wrote:
 

So, if I understand swallowing events, the purpose is to eliminate any unneeded further event callbacks once the app has the one it "wants?" Is that correct?

---

Yes. A typical application would be waiting for a given key. You then would use a KEYPRESS_EVENT and once the desired key has been pressed processing further keys is not required.

Concerning your callback code I don't see a problem provided that you check rc

[mzimmers]

Thanks, Wolfgang. Just curious: if rc showed an error for either of those library calls, what action would be recommended?

[Wolfgang]

It depends on the error code

What I wanted to suggest is that some error checking can not harm: if ( rc < 0 ) // alert