Force "Wait on Occurrence" function to stop waiting

[gerh]

Hi all,

is it possible to interrupt the "Wait on Occurrence" function, so that it stops waiting?

That's my situation:

In my VI, I'm using occurrences to get event messages from the windows API. See here: http://www.ni.com/example/29394/en/ for an example code. One part is a DLL which takes the reference of the occurrence and sets an occurrence each times an event happens (e.g. mouse down, etc.). In the case, the VI is closed it's necessary to abort waiting to the occurrence immediately, otherwise the application becomes idle until any event happens.

[nathand]

Not that I know of. If you have the ability to do so, consider rewriting the DLL (I think they provide source code) to use PostLVUserEvent instead, which fires a user event that you can catch in an event structure. That library was originally written for LabVIEW 5, before the event structure existed (I think), so it used the tools that were available at the time.

[gerh]

I'd prefer not to touch the DLL in short term. This will be the last option if nothing else works.

So it would be great, if there is any trick to come around the blocking "Wait on Occurrence".

[tst · Accepted solution]

I haven't looked at the code in years, so I don't really remembers what it looks like, but what's preventing you from splitting the occurence wire to the point where you know the VI stops and setting the occurence there? Obviously, this will cause your code to think that an event occured, so you might need to add another mechanism to mark that this is not the case, but it should be doable.

Another alternative is to use the timeout. Obviously, this will make it poll, with all the implications of that, so that's up to you.

A third option is to add a layer between the occurence and your actual code, which is basically what Nathan suggested, but this suggestion is for doing it on the LV side instead of in the DLL. This doesn't solve the issue you're having (you would still need to write the code to handle it) and it makes the system more complicated, but it can make the API that your final code sees more clean (e.g. using two events). Depending on what the code looks like, this might require some daemons, etc., so you might not want this.

[nathand]

If you do decide to modify the DLL, Rolf posted here that he'd started working on this change, but never followed up on whether he finished it. Wouldn't hurt to ask in that thread, even though it's a few years old.

[gerh]

Thank You for the suggestions.

@tst

the solution, I took, is a mix of Your option 1 and 3.

The intermediate layer is an API that mimics the behavior of notifiers, but with occurences in the background. To achive this, I abused a queue of 1 element size which carries an occurrence refnum. To make the occurrences sotp waiting, an occurrence is set and the queue destroyed. The modified wait cathces this case and fails with error 1122. All succeeding waits will fail because of the missing refnum. -> A clean shutdown is possible (because the wrapper returns an error).

Obviously this works only because the dll sets but not waits on an occurrence.

[gerh]

Oooh... forgot the attachment. Here it is.

Please use notifiers if your code doesn't strongly rely on the reference of an occurrence instead of these VIs.

And the official part:

No license terms, no warranty. See the example VI for further details.