Front panel freezes when control is edited

[rodmar]

Hi, I have an application with 6 parallel loops, two of them with event structures. (Each loop takes care of a specific task group and has a different pooling rate at "Wait ms" function). Each time I try to change a value of a control, the front panel freezes. I can't scroll the FP and even the Ctrl+E shortcut do not work. This happens even with controls with no event attached to it. The software is running, though. I set probes in error clusters in all loops and all of them are executing, with no errors. I searched the forum and found that event structures, but I've set the option to lock the front panel false in all event structures and still the FP freezes. Any ideas? Cheers, Mariana.

[Ben]

If you are certain that you have unchecked "Lock FP panel..." then I would suspect you have some code that is dominating the UI thread (Single threaded, used to service update GUI).

DLL calls can do this if configured to run in tht UI thread.

There is also a possibilty that your app stuck in Kernal mode due to attempts to allocate large amounts of memory, or your code is written such that it is compute bound and the freeze up is due to how the code is written.

Post some images or the code in question if you want others to look and comment.

There are simply toooooo many things that could result in a GUI lock-up to attempt to cover all  of the possibilities with the lmited info in your post.

Ben

[SteveChandler]

I have heard that multiple event structures can cause problems although I have never tried it and don't know what those problems might be. Why two? I cannot think of a reason you would need more than one.

[Ben]

---

@Steve Chandler wrote:
I have heard that multiple event structures can cause problems although I have never tried it and don't know what those problems might be. Why two? I cannot think of a reason you would need more than one.

---

I have used multiples becuase the the associated functions were completely independent and combining them would have imposed an artificial complication to what should be unique and sepearte operations.

example:

Two booleans,

one initiates transfer of set-up to a widget and diables the associated controls when pressed.

The second when pressed shows a sub-panel.

either button can be clicked at any time and they have no interaction.

Why would I put them both in the same event structure?

Using two I can have the transfer taking place (with lock FP dispabled of course) and show the pop-up at the same time.

Putting them both in the same loop would force one event to wait for the oher (customer: Why does the app pause after I push the transfer button before displaying my pop-up?) or I would be forced to implement a more complicated architecture to transfer the work to other loops.

Mutliple event structures help Keep It Simple Sir.

All of the issues I have read about regarding multiple events introducing problems were all due to mis-use or a possible bug (which I do not think was ever settled).

Just my 2 cents,

Ben

[rodmar]

Hi Steve, I'm using two event structures because of multiple user screens. What I did was instead of creating multiple VIs, I created each screen in a tab of a tab control. In the end it became a rather complex software, and I don't believe I'll ever do this again :) I have a event structure for each of the screens (when messing with parameters, I've got more than 40 because of my client's requisites). Anyway, what was happening is that the software was trying to trigger an event from an already closed screen. Thank you all for the suggestions, Mariana.

[Ben]

Ading to my previous... for no good reason...

Desigining and implementing an application using LV (and most cmputoer languages) is a lot like being an animal trainer. If you are familiar with the nature of the critters you are working with, the show goes as planned. Use the wrong critters for the wrong tricks and you can loose your head. Trying to get an elephant to jump through a hoop is a no-go and would be earth shaking if you pulled it off.

Let the elephants carry the heavy loads and use the tigars for what they are built for.

Sure you could train monkeys to do all of the tricks but that would require even more work to get them to work together.

Using sepearte Event structures is legitimate and can simply code that looks like 3 ring circus to look more bevy of swans.

These comments are not directed at anyone in particular. I am just in a rambling mood this morning.

Ben

[Norbert_B]

@Ben:

I don't like your analogy to critter training. Esp. your sentence "Let the elephants carry the heavy loads and use the tigars for what they are built for." is something i would take in the wrong way...

Why?

Imho, critters are not build for doing ANYTHING for mankind. Not even close. We abuse them.

Well, maybe, on the other hand, programming is however indeed comparable *ponder*

But i like your sentence "If you are familiar with the nature of the critters you are working with, the show goes as planned. Use the wrong critters for the wrong tricks and you can loose your head.".

@Marianna: You are running into the issue, that event structures are still enqueueing events even if the structure itself is not in running code (so e.g. in case of a case structure execution another case not including the event structure).

This is a well-known caveat of event structures and one reason to not use several event structures in a single VI.

But as Ben stated correctly: If you know what you are doing (and what is happening behind the scenes), using several event structures could also give you great opportunities and open new solutions.

But unless you know what you are doing, keep your fingers from it 😉

Norbert 

[SteveChandler]

Thanks Ben.

I did some looking around to try and find out why I thought that multiple event structures is a bad thing. I think it came from the help file Avoid Placing Two Event Structures In One Loop in Caveats and Recommendations When Using Events in LabVIEW.

After reading it again I don't think that it is necessarily a bad thing. It just warns that the user interface can become unresponsive depending on how it is used. So I now believe that this is not inherantly bad or wrong but just requires caution.

I think it is a common misconception that you should not have multiple event structures and the link above is probably the source.

But I will probably stick with just one because in my mind it is simpler because of what I am used to.

Mariana, so you got it working?

[billko]

---

@Ben wrote:

Ading to my previous... for no good reason...

Sure you could train monkeys to do all of the tricks but that would require even more work to get them to work together.

Ben

---

I thought that was the job of the team leader.  😄

[Ben]

---

@Norbert_B wrote:

@Ben:

I don't like your analogy to critter training. Esp. your sentence "Let the elephants carry the heavy loads and use the tigars for what they are built for." is something i would take in the wrong way...

Why?

Imho, critters are not build for doing ANYTHING for mankind. Not even close. We abuse them.

Well, maybe, on the other hand, programming is however indeed comparable *ponder*

...

Norbert 

---

So what do you think about dogs?

All you have to do is work one project for a group of reserachers that know their science but nothing about computers to feel like an elephant trainer directing the beast to do the work they need.

Ben