Receiving events of release 8 in CVI release 7

[RobertoBozzolo]

Hi all, I am facing a strange behaviour while editing an old program written in CVI 7.1. On my machine CVI 8.5 is installed, so the active run-time engine is that of the most recent version.

While editing the program in CVI 7 IDE I have found that a table receives events not yet defined in that version. Specifically it receives EVENT_MOUSE_POINTER_MOVE event when the mouse hovers the control; I have noted also some EVENT_LEFT_CLICK_UP event; I haven't made specific tests for other events.

This is quite an annoying problem, with a simple solution: simply adding the line

    if (event > EVENT_MARK_STATE_CHANGE) return 0;

at the very beginning of the function eliminates all possible confusion due to unpredicted events; events are received both in the IDE and in the compiled application.

Having noticed this fact, two questions arise that I'd like somebody can answer:

Q1: is this an expected behaviour? That is, are the events coded inside the runtime engine so that I must consider that my controls will receive the events listed in the running RTE? I wonder if I need to add the filtering-out line on all programs that are likely to be executed on newer RTEs that the version they were built with: that is, the declared compatibility with newer RTEs could lead to some unpredicted behaviour.

Q2: is this behaviour consistent? That is, can I rely on these events being passed to the controls exactly as if the application was developed in the newer IDE?

Message Edited by Roberto Bozzolo on 01-05-2010 12:46 AM

[ebalci]

Hi Roberto,

That's somewhat confusing issue that surprises me first.

However, thinking of the run-time currently in operation it seems like an expected behaviour.

There has been other posts about this RTE version issue lately, and as far as I could follow, the final decision on the best way of handling this was to install the related RTE on the application folder, instead of the system folder.

What happens if you install the version 7 RTE in your application folder? Do you still receive the newer events? 

Message Edited by ebalci on 05-01-2010 03:31 AM

[jr_2005]

Roberto - I'm unclear as to why this is causing a problem. So you have a control callback that is receiving events that it does not wish to handle: well, this is how CVI works and why we use a switch/case statement within the callbacks, to pick out just the ones of interest. It's a bit early in the morning for me (but not nearly as early as ebalci's response!) but I can't spot why you are worried about it.

JR

[RobertoBozzolo]

Well I have found this while hunting a strange table behaviour: having placed a breackpoint exactly on the switch instruction the application was interrupted by a variety of unpredicted events every time the mouse hovered upon the table.

As I already have told, it's not really a big problem, but the situation is really I have a control that is receiving events that it is not expected to receive: I wonder if I have some "default" clause in the events switch statement of some of the dozens of controls in all the application panels that may be fired unexpectedly

On the other hand, some applications of mine could benefit from some new events being introduced in later CVI versions than the development one, and this without the need to pass the entire application in the newer developing environment (and completely retest it!).

[jared · Accepted solution]

Yes, this is expected behavior. I realize that the callback receiving new events when you install a new version of CVI is probably not an obvious side effect, but it is a side effect of CVI's run-time engine architecture. As was noted by jr_2005, this is why it is important to only respond to specific events in your callback. As mentioned by ebalci, you can workaround this by using a local RTE by copying the version of the RTE you want your application to use in the same directory as the executable.

However, if the callback only responds to specific events, this behavior should not present a problem. As you noted, it is only when you have code in a default case, or outside the switch statement, that this can cause unexpected results.