LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

mouse over menu bar stops program execution

in CVI 6.0 , if I place my mouse over the menu bar, the program stops until I move the mouse off the menu bar or I switch to another
window with alt-tab
this happens even if menu bar is dimmed..

this does NOT happen in CVI 7.1 using the SAME CODE
- Make Software User Friendly -
0 Kudos
Message 1 of 14
(5,396 Views)
This is a known issue regarding exactly CVI6 and solved with version 7.
Some detail more in this post


Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
Message 2 of 14
(5,387 Views)
But (for my application: sadly) the programm still stops when the menu is opened until a choice is made.
-----------------------
/* Nothing past this point should fail if the code is working as intended */
0 Kudos
Message 3 of 14
(5,356 Views)
UI Timer callbacks do stop firing if the menu item is opened and is being tracked. Try using async timers instead of the UI timer. That should let you keep your UI updated even if the menu items are being tracked.
Bilal Durrani
NI
0 Kudos
Message 4 of 14
(5,339 Views)
The best solution is to install runtime engine 7.1 over your old version of CVI.
You can still continue to create software with your old version of CVI...bug free..this bug anyway..
- Make Software User Friendly -
Message 5 of 14
(5,336 Views)

@bilalD wrote:
UI Timer callbacks do stop firing if the menu item is opened and is being tracked. Try using async timers instead of the UI timer. That should let you keep your UI updated even if the menu items are being tracked.




GetUserEvent() is not returning, too.

Message Edited by CVI-User on 07-01-2005 09:53 AM

-----------------------
/* Nothing past this point should fail if the code is working as intended */
0 Kudos
Message 6 of 14
(5,328 Views)

Actaully I must correct myself. The timer callbacks should not stop firing on account of the menu being tracked. In my test, I had a call to ProcessSystemEvents() in the timer callback. This was the only reason why the timer callbacks stopped firing when I opened up a menu. Here is what the help of ProcessSystemEvent states

Note    When ProcessSystemEvents handles an event that starts a tracking loop, such as the user pulling down a menu, ProcessSystemEvents does not return until the tracking loop completes. In the case of pulling down a menu, the tracking loop does not complete until the user dismisses the menu. Consequently, do not call ProcessSystemEvents in your program if you want to continue executing the subsequent lines of code even during a tracking loop.

Once I remove the call to ProcessSystemEvents(), the timer callback no longer gets held up when I bring up a menu.
This function will wait only if the tracking loop starts while ProcessSystemEvents() is processing messages. For example, if you set the timer callback interval to a large value like 2 seconds, and then play around with menus, you will notice that timer callbacks are no longer being held up. This is because in this case, the call to ProcessSystemEvents() is being nested inside of the tracking loop started by the menu. The tracking loop was already running by the time the call to ProcessSystemEvents occured.
Ofcourse if the timer is running really fast, you have a higher probability that the tracking loop will be started during a call to ProcessSystemEvents() (hence the tracking loop is nested inside of the call to ProcessSystemEvents() ). In this case, ProcessSystemEvents will not return until the tracking loop returns.


This is the same behavior with GetUserEvents(). Here is what the help says

Note    When the User Interface Library handles an event that starts a tracking loop, such as the user pulling down a menu, GetUserEvent does not return until the tracking loop completes, even if you pass 0 as the waitMode parameter. In the case of pulling down a menu, the tracking loop does not complete until the user dismisses the menu. Consequently, do not call GetUserEvent in your program if you want to continue executing the subsequent lines of code even during a tracking loop.


I hope this explains things. This all is unrelated to that CVI menu bug that initially started this thread.

Message Edited by bilalD on 07-06-2005 06:42 PM

Bilal Durrani
NI
0 Kudos
Message 7 of 14
(5,289 Views)
All very interesting, but CVI7.1 does NOT have a "Menu BUG" like CVI6.0 and the HELP for the functions involved are the same !!!
I am VERY upset that I had to discover this MAJOR BUG instead of being notified by NI about the bug..
 
- Make Software User Friendly -
0 Kudos
Message 8 of 14
(5,270 Views)
@bilalD:

One has to create an extra thread for the
ProcessSystemEvent / GetUserEvents then. Either explicitly using CreateThread or implicitly with the async timer.

But then you can't do eg. SetPanelAttribute(Panel, ATTR_TITLE, ...) in a callback because the panel is loaded in a different thread.
That's a problem, which is then solved by (ugly) workarounds.
-----------------------
/* Nothing past this point should fail if the code is working as intended */
0 Kudos
Message 9 of 14
(5,264 Views)

@ror:

At the time CVI 6 came out the bug wasn't known, or they would have fixed it by then, don't you think? The programmer who can give his clients exact descriptions of the still to be discovered bugs in his software will win a nobel prize, because he has found a way to predict the future.

I'm not sure what you should be upset about, you posted a problem, and got an answer. Looks fine to me. That's what these boards are for.

Erwin Timmerman

0 Kudos
Message 10 of 14
(5,238 Views)