Many events in event structure

[Nimgaard]

Hello

My GUI application have grown over time and the main event structure now contains upwards 150 GUI triggered events, mainly buttons both standalone and in custom controls.

The performance of the application is no problem but i experience occasional freezes of the application that simply freezes the the GUI and what i suspect most of the code executing in the background. This is cleared by clicking anywhere on the front panel of the application and the same problem occurs both in the development environment and in a built .exe. To clarify, the application does not crash or stop, it simply pauses or freezes and then resumes execution when the mouse click occurs. This happens randomly, and with at least a few minutes between.

I am currently trying to trace the problem but thought id ask here if anyone have any experience of first of all event structures that handle a large number of events, or perhaps have seen the same freeze happen in their application?

[Ray.R]

I have not seen such freezing from an application which has many events in the Event Structure.  I never considered that there would be a performance hit based on the number of events to be handled.

I am wondering if what you are seeing is the Event Handler handling an event triggered by the mouse or something else, that may not be that obvious.  But then, it would not explain why it recovers when you click anywhere with the mouse.  I can see why this would be a tough one to debug.

You have probably tried highlighted execution, right?  And since this occurs randomnly it probably never happens when the execution is highlighted.  A trick (but exhaustive one) would be to place a probe in each event and monitor their timestamp.  When it freezes, check which one as the latest timestamp and investigate that or those events.  Plus look at the timestamp from when you unfreeze using the mouse click.  Be sure to be patient and when it freezes, wait sufficiently long (>1min) to capture any timestamp changes within all the probes.

I can't think of anything else that might help your investigation at this time.  I am curious at what could be causing that issue.

[Bublina]

I had once problem with event structure,

I had a program that was spawning threads (reentrant VIs) for every camera configured in the system. Using IMAQdx, you can register for an image frame acquired, so you get an user event everytime image arrives.

When I had more cameras connected (3+), and all started sending through GIGEVision images to computer, not all these subVIs were getting Image events right away.

These malfunctioning subVIs were like you say freezed (no images coming for like 1 - 3 minutes) and after some time, they woke up (one sooner one later) and sent all these Image events in short timespan. When watching the time property coming from the event structure, the times were OK ?!? like everything was running perfect + the images were still there so the internal IMAQdx buffers kept all.

I tried almost everything, but the problem persisted, and I had no luck in figuring out why was it like this !

I solved this by not using the Frame event and rather used the standard getImage with timeout.

[Nimgaard]

I have considered highlight execution and probes but then again as you say its rather useless unless i get very very lucky, especially with the highlight execution. Its also an application that sits at a customers site, and below the GUI there is a lot of hardware equipment that would be time consuming as is to simulate, not to mention simulate and still be able to do a meaningful trace of the bug. I suspect the event structure but then again it might be something else entirely.

At the moment i have it running off the development environment while having the desktop execution trace toolkit monitor it, hopefully i can catch something useful from the traces. I just thought it would be an idea to see if anyone have any experince of this problem.

As for large numbers of events handled by a single event structure i havent really looked into what any limit would be, but somewhere under the hood some code have to watch those GUI controls. On the other hand i dont have any performance issues so...

[Ray.R]

Just curious, what is the CPU performance while it is frozen?  Is it high? Near zero? Remains constant?

It might provide some clue at what is going on..

[Nimgaard]

As far as i have seen it remains constantly low. Sadly it dont seem to do much, it just pauses and then happily continues when someone press the mouse button. Its not often i ask for bugs that crash my application but in this case i think i would prefer it.

Should probably mention that the application is developed in LV2011.

[Bublina · Accepted solution]

---

@Nimgaard wrote:

As for large numbers of events handled by a single event structure i havent really looked into what any limit would be, but somewhere under the hood some code have to watch those GUI controls. On the other hand i dont have any performance issues so...

---

There is no watchdog, that would keep checking for changes, this is all managed by WinAPI, the application is just getting messages that it is registered to recieve.

The mouse click event or button value change has its chain starting from the interrupt handled by driver running in windows kernell level.

Basically the computer, if there is no user activity, consumes as much PC resource for active window with no events as for active window with many events.

[Nimgaard]

That would mean that unless an event actually happens there is nothing in particular happening that could cause this behaviour. And since the freeze happens while the event structure is passive the number of events shouldnt really matter.

As i wrote, i havent really looked into how LabView handles events but if its based off the WinAPI and do not do anything unless an event is fired then i can probably rule out the number of events in the structure as the problem. I will leave the thread without solution a little while longer to see if anyone have more input but ill probably mark your answer as the solution to the question. Thanks a lot for the input.