Abort Vi Method Will Generate Vi Mouse Events

[PJM_labview]

Hi everyone

I have a main VI that start a spawn which mission is to execute code after a some delay :clock: (ex:2s). The spawn is start when the "VI:Mouse leave" is triggered.

Now, if the user re enter the VI before the delay :clock: expire (ex: before 2s has elapsed), I do no longer wish to execute the code, so I kill my spawn using VI:Abort.VI method.

As long as I do not kill my spawn, everything work like a charm, but as soon as I kill my spawn, "VI:Mouse leave" and "VI:Mouse enter" events are generated (?!?!!?) :thumbdown: and I am entering an infinite loop because in "VI:Mouse leave" I generate the spawn and in "VI:Mouse enter" I kill it which generate VI:Mouse leave ....

If someone could confirm this (or even better prove me wrong) that will be great.

System: Win2k with LV7.0

Attached is some code that will demonstrate the issue

Download File:post-16-1079896891.zip

[Jim Kring]

Hi Philippe,

This seems to be pretty serious. It appears that the VI.Abort method causes some crazy behavior related to mouse-window interaction. Notice how the all the VIs' Front Panels appear to "flash" when the Abort is called. It is like things are being "reset" behind the scenes.

:question: I wonder... What other mouse events the VI.Abort method causes to misfire?

Well, you may have already solved the real problem, which is how to exit the spawned VI. In this case a Notifier works very well. Attached is an example that shows how to do this.

Cheers,

-Jim

Download File:post-16-1079901464.zip

[CraigGraham]

It's not the abort, I think- it's the "Open". The window temporarily loses focus when opening the sub VI, then regains focus. This is what triggers the mouse leave and mouse enter events. I fixed it by only opening the VI once at the start and not autodisposing the reference.

[Jim Kring]

Another last minute thought...

I only use the VI.Abort method in extreme situations, for the same reason that you don't stop a LabVIEW application by pressing the Abort button on the toolbar. You lose a lot of control over how things are stopped. I like to be in control. Usually, I will try to message into the running VI with a Notifier or by setting a Boolean flag to TRUE in a shared data-space (in a GOOP data store, for example). Then, if the VI is still running after some timeout period, I will kill the VI by invoking the VI.Abort method, but this is after all else has failed.

Attached is an image that shows a routine that I commonly use to perform this task.

I have been wanting to write up some documentation on the design pattern of process/daemon/agent spawning, and specifically how it relates to OpenGOOP classes. Expect to see something in the semi-near future...

Cheers,

-Jim

[Jim Kring]

Craig,

It's not the abort, I think- it's the "Open". The window temporarily loses focus when opening the sub VI, then regains focus. This is what triggers the mouse leave and mouse enter events. I fixed it by only opening the VI once at the start and not autodisposing the reference.

Nice fix.

I would think that losing focus should not (in principle) fire the Mouse Enter/Leave events, unless the VI that is opened actually has its front panel opened and it is directly beneath the mouse when it opens. Also, I believe that focus should not (in principle) fire the event, since Mouse Enter/Leave will work even if the VI is not frontmost.

Cheers,

-Jim

[PJM_labview]

It's not the abort, I think- it's the "Open". The window temporarily loses focus when opening the sub VI, then regains focus. This is what triggers the mouse leave and mouse enter events. I fixed it by only opening the VI once at the start and not autodisposing the reference.

Craig,

I am spawing VIs. If I understand what you say, you are opening the reference only once. I need to open a new one for every new spawn.

Well, you may have already solved the real problem, which is how to exit the spawned VI. In this case a Notifier works very well. Attached is an example that shows how to do this.

Jim,

Yes, I had to use a notifier. I did not want to do it because I though that's an overkill for what I want to do, but it has the GREAT advantage of working

Philippe

[PJM_labview]

This bug has been reported and confirmed by NI

Following is part of NI Response:

Thank you for contacting National Instruments.

I looked at the llb you sent me and I was able to reproduce the behavior

you were seeing.  I quickly checked if any such behavior was already

documented and I found that it was recently documented.  This means that

our R&D engineers are already aware of this bug and are working on a fix.

According to the behavior, it looks like the abort VI method generates the

'mouse leave' event.  After executing the 'mouse leave' event, 'mouse

enter' event is executed because the mouse is on the VI (since it never

left the VI in the first place).  Mouse enter event is not generated by the

abort VI method.  The only reason 'mouse enter' is called is because the VI

thinks that mouse had left the VI due to the faulty event caused by the

abort VI method ...

Feroz Patwa

Applications Engineer

National Instruments

[PJM_labview]

The Bug (Abort Vi Method Will Generate Vi Mouse Events) is still present in Labview 7.1

PJM

[X___]

It's a very dead thread but it's the one I found when trying to figure out why a "VI Mouse Leave" event is fired when I open another VI programmatically even when not activating that VI.

Since that has been suggested as being the source of the OP's problem (but then NI suggested it was a bug with the Abort method), I am wondering whether this is expected behavior or a bug (which would then still be alive in 2021 SP1 which I am currently using).

If this is a feature, I am trying to understand the logic: a VI is opened and set to not be inactive, yet the Mouse is supposed to have magically moved to that VI's front panel, even if it is nowhere close to it?

[sam]

Does a OS setting have anything to do with it?  Something like set focus to new windows etc.  even though it may be disabled and not activate, the option isn't 100% disabled.

Mouse events are OS wide and language independent 

[X___]

I think it is actually more trivial: the behavior I was observing is indeed related to an ancillary window opening, but that was triggered by a user-selected menu item. If I programmatically open the window, the "Mouse Leave" event doesn't appear to be fired (as expected).

In fact, going to the menu bar triggers a "Mouse Leave" event. Why not. However, for some reason, the "Mouse Enter" event is not fired if the selected menu item is actually inside the window (which is almost always the case). This is what got me confused (or rather my code).

So I guess my question is thus: why is the Mouse Enter event not fired when the user releases the mouse button after having selected a menu item?

Edited January 8 by X___
clarification