What does CVI 7.0 do during a tracking loop?

[jr_2005]

I have a CVI 7.0 application with a GUI consisting mainly of a large scrolling Stripchart, covering about 80% of the PC screen. This stripchart is plotted on a Timer callback, with a timer interval set to 0 to get a reasonable display speed. (I include a ProcessSystemEvents() call within this Timer callback to ensure that the GUI does not lock up.) The program receives data for plotting from an external network via TCP callbacks.

It all works just fine. Usually. But just occasionally, when I operate one of the GUI controls (a drop-down menu ring) the application becomes totally unresponsive - even the ring menu selection fails. (Normally I Ctrl-Alt-Del at this point to crash out of the application; however on one occasion I happened to leave it for about 5 minutes and suddenly got full control back again.)

My understanding is that CVI is in a "tracking loop" at this point, with no part of my program executing until the ring menu item is actually confirmed and selected. Certainly I can see the scrolling Stripchart freeze during the time that this control is operated normally. Except when it crashes - in this case the Stripchart continues to scroll (behind the menu ring drop-down) and other GUI items stay active, but the ring control (and thus the whole program) seems to lock up.

Is there anything I can do to prevent this behaviour? If my program is not supposed to be executing at this point it is difficult to see what corrective action I can take. Perhaps I have misunderstood the nature of such "tracking loops".

TIA

JR

[bilalD]

Do you have a sample that you could post to replicate this crash? i have not heard of the menu ring causing crashes before, but I can look into this some more.

Thanks

[jr_2005]

Unfortunately there is way too much code (and hardware dependancies) for me to post it as is. I feel that there must be some clue in the observation that the Stripchart continues to operate when the crash occurs and the ring menu locks up. This indicates that the Timer callback is still continuously active, even though the ring should have taken control? I presume that I cannot trap the EVENT_LEFT_CLICK callback on the ring control *before* CVI enters the tracking loop? Even if I could, what would I change in the code to stop the incident?

JR

[bilalD]

I tried creating a simple (maybe too simple) stripchart app with a ring control and a timer running at full speed plotting data and calling processystemevents. I tried playing around with the ring, but didnt get any crashes. So I'm not sure what might be happening. You could try using the CVI 7.1 RTE ( avaialble here ) and see if you still have the same problem.

The only way i can get the chart to update while the menu is up is if I plot from another thread (using async timers). So Im not sure how you are ending up in that state.
Have you tried using async timers instead of a UI timer?

[jr_2005]

I tried to produce a much simplified application as well, in an attempt to simulate the problem without any hardware connections. The first thing I did was to eliminate the external physical network connection and generate simulated data locally, on the same computer that the suspect application runs on. This way I did not need to recompile the main app just yet. The problem disappeared.

It must be related to the timing of the CVI TCP callback mechanism - presumably every once in a while the network card/Windows TCP handler sub-system generates an interrupt at just the wrong time; maybe at some crucial point during the construction of the ring menu? Then the callbacks/threads/whatever get confused and voila - my original problem.

I am reluctant to make structural changes until I know for sure what is going wrong - the program is fine for 99% of the time and I am running out of time on the project! Any suggestions and/or advice would be welcome, but I am off on holiday now so it will be a while before I can try anything else. I'll try 7.1 when I get back.

Thanks.

JR

[bilalD]

I posted here about the behavior of ProcessSystemEvents and GetUserEvent w.r.t tracking loops. I tried adding tcp callbacks into the equation as well, but I didnt see anything happen. I had a little server/client app running.

Let me know if 7.1 changes anything for you.

[jr_2005]

Just got back off holiday only to find the hardware has been shipped - it will be quite a while before I can get to try 7.1

Thanks for your efforts.

JR

[msaxon]

Are you absolutely sure you need the ProcessSystemEvents() call in the timer callback? Have you tried the code without that call?

The ProcessSystemEvents() may cause a new timer event to be generated and executed whilst you are in the callback. So if you are absolutely sure you need ProcessSystemEvents(), you should code your timer callback in such a way that it is not re-entrant. One way is to use a static variable to indicate whether you are already in the callback, e.g. your timer callback could be structured as follows:

static int inTimerCallback = FALSE;

if (!inTimerCallback)
{
    inTimerCallback = TRUE;
    ... Do stuff here...
    ProcessSystemEvents();
    ... Do more stuff here...
    inTimerCallback = FALSE;
}
return 0;

[jr_2005]

None of the GUI controls will respond without the ProcessSystemEvents() call, so yes, it is absolutely necessary. It is actually quite a neat way of ensuring that the CPU loading stays at 100% (it takes a lot or resources to draw a huge stripchart) while retaining GUI responsiveness at the same time. Fairly unusual, in Windows apps.

I was under the impression that once a timer callback had been triggered, no other timer callbacks could occur until the first one has completed. So it is inherently not re-entrant? (Otherwise I would run out of stack very quickly.)

JR

[bilalD]

Yes, the timer callbacks are not re-entrant, even if you call ProcessSystemEvents() inside of a timer callback.