menu bar causes program to stop

[cjp1]

I'm running in a loop and monitoring an input and when the menu bar is clicked on and held the loop stops.

and after my buffer fills the program crashes. Is there some whay to prevent this?

Thanks

[RobertoBozzolo · Accepted solution]

I remember an old problem similar to the one you are reporting, back in CVI6 age or so. I don't know whether it has been fixed in more recent releases of the system: the problem was that opening a menu will cause ProcessSystemEvents and GetUserEvent to stop until the menu is left open.

Not knowing exactly which version of CVI you are using, I would suggest a definitive workaround for this situation: hide or dim the menu bar immediately before starting the loop.

An alternative approach, better in design but more difficult to achieve on an already developed application, would be to spearate the loop function in a different thread, thus leaving the main thread free to process user actions on the interface.

In every case, you must decide wether the operator can actually be permitted to operate on te user interface during the loop, and which operations must be left active in this case and which are to be excluded.

[ISITEC_RIEPER]

Hi,

in some cases i used SetSystemAttribute() with the attribute
ATTR_ALLOW_UNSAFE_TIMER_EVENTS.
Just take a look at the explanation for this attribute in the help file.

Greetins from Bremerhaven, Germany

Norbert

[cjp1]

Hi, Thanks for the replies.

I tried both suggestions and the multithreading one worked.

Thanks.

CJP

[Espoo]

CVI 8.5, multi threads. PopMenu result program stock still! Same issue still exist

[Kurt-P]

Hey Espoo, 

Thank you for letting us know this is still an issue in 8.5. This is an older thread so can you create a new one with the exact description of the problem along with a simple example that reproduces the error. In the mean time, I would suggest trying the work around suggested by RobertoBozzolo. 

Regards,

-KP

[Espoo]

Issue:

1> Installed ComCallback was blocked when pop menu show up, and block the whole process.

2> ProcessSystemEvents() can only track pop menu and no other even event for Com callback. // see CVI help for this funciton

3> the thead which stucked in popmenu are waiting for comcallback to finish to get expect data

So, both thread are locked. It's strange that in this situation, CVI will block GUI update even still calls ProcessSystemEvents() periodical.

Solution:

fire a aync timer, which periodic check com port input queue also.

If there are data, it trigger/call ComCallback directly, regardless the InstallComCallback.

In simple, beside trigger by Com event, also trigger by timer to work around.

in conclusion, ProcessSystemEvents shall handle GUI better. this is system limits. it takes me 2 days to fingure out why and 1 day to find this workaound. 

Hope help others. BTW, preivious soution are not very clear, but still help.