multiple EVENT_COMMIT on single click

[mng]

Using CVI 6.0 under XP-Home: When I update any control (set to hot or normal) on my single panel, I get multiple (4) EVENT_COMMIT events, which means the callback fn code runs 4 times.  I have noticed that on the first event, when the control is read it gives the old value.  Is this a clue?  On the 2nd event, the output controls have not updated, but they have on the 3rd.  I have installed the v7.x RTE with no change.  Any ideas, please?

[RobertoBozzolo]

Are you sure that you are trapping EVENT_COMMIT only? It seems that your callback is fired by different events: EVENT_GOT_FOCUS, EVENT_LEFT_CLICK, EVENT_VAL_CHANGED, and finally EVENT_COMMIT: this is consistent with the control having updated on the 3rd execution (EVENT_VAL_CHANGED) and not before.

Check that your callback has the usual switch (event) + case EVENT_COMMIT structure or a simpler if (event != EVENT_COMMIT) return 0; statement.

[mng]

Thanks for the response.  I am almost too embarrassed to admit the cause of the error!  here goes.  I am checking for the COMMIT as I always do when i don't care about others:

int CVICALLBACK buttons (int panel, int control, int event, void *callbackData, int eventData1, int eventData2)
{
 if (event = EVENT_COMMIT) {
  GetCtrlVal (pMain, PANEL_ALT, &alt);
  switch (control) {...

As soon as i pasted my code into this message window, the single = stood out like a sore thumb.  The program in question is tiny, so has presumably always been running 4 times or so on every click without my noticing until I put break pts in.  I blame having to program in other languages concurrently.  The CVI compiler picks up lazy missed semi-colons, but its perfectly happy with the above, of course.  Oh well...

[msaxon]

A little tip I learned ages ago is to put the constant on the left hand side when comparing a variable with a constant. So

if (EVENT_COMMIT == event) ...

is valid, whereas

if (EVENT_COMMIT = event) ...

will cause a compilation error.

Seems trivial, but get in the habit and it helps a lot.

[mvr]

In CVI 6 if you look under Options==>Build Options==>  in the compiler warnings section on the upper right you can select Detect assignments in conditional expressions and CVI will trap this for you.  There are also the common choices to allow the compiler to trap for sign mismatch, unreachable code, and unreferenced variables.

[mng]

Thanks for that - I may have even had it set once, but have had to re-install since.  On that note, is there an easy way to transfer preferences to a new installation?  I will have to re-install shortly when my PC is updated.

[mvr]

If I bring the workspace cws file along, most of my settings also move.  I cannot remember what files in cvi 6 would move the settings not covered by the cws file.

[mng]

Thanks - I will try that.  Martin

[mvr]

The cws file can contain things that are machine spacific (like path names), if they cause problems on the new systrem, just edit the cws file.  It is just an ascii file and can easily be corrected.

[LuisG]

Those preferences that are not saved in a workspace file can be transferred to a new machine by exporting the following registry location:

HKEY_CURRENT_USER\Software\National Instruments\CVI\6.0

(If you're not using CVI 6.0, you would replace "6.0" in this path with the version that you are actually using).

Like mvr said, some of the information there might be machine-specific, the most likely being paths, so you might have to do some fixups.

If you've never exported a piece of the registry before, this is how you do it: run "regedit", the navigate to the path you want to export, right-click on the folder, and select "Export". Take the file that is created for you to your new machine, and double-click on it. It should automatically be merged onto the system registry in that machine.

Luis