LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

GUI locking up, why?

I find this discussion thread interesting because you are asking questions that I don't remember ever asking. I've been using the event structure since it was introduced (in 6i I think), and I guess I intuitively understand what's going on. It definitely breaks the dataflow paradigm, but it's just so damn useful. Before the event structure, everyone just set up main loops that polled every 100 or 250ms or so to check every control on the front panel. If a control was changed (you had to check this manually as well), you would trigger some case structure or something to handle the intent. Event structures simplify the code dramatically, and make it much more efficient (almost no need to poll).

 

I think of the event structure as a way of establishing a connection to something that is already running [in the OS?]. Basically, you are just hooking into a background event process that already exists, but the structure allows you to specify actions to take when particular events occur. It's your job to make sure the structure is free to act on the instructions you've given it.

 

Bottom line, you are on the right track with your experiments. Those of us who never had the benefit of formal training programs have always had to develop an understanding of how and why things occur the way they do based on tests. I think the process of building and trying to understand the results of little code experiments is a better way to learn (maybe slower though..).

 

btw, I work for kudos 🙂

Chris

Message 11 of 14
(282 Views)

As mentioned, you're under the misconception that event only happens when handled, when it's rather the opposite - Events always happen, but are solved when they can/are handled.

That's why event structures are generally the outmost loop, or atleast in a structure that guarantees return (as a single loop state machine with a timeout state).

 

In your case the solution is simple, 1 loop with the event and a few Events for the controls that's changed (the tab page is only a visibility factor and is irrelevant).

 

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 12 of 14
(272 Views)

 

           Without that feature you would not be able to write a useful program. What if a button

           is pressed while the previous event has not finished?   What if a button is pressed

          while it is doing an FFT? Should it just ignore the button or should it service it once

          the event is available to be processed?

 

I fully understand these points.  I just thought that it wouldn't start queuing up events until it was executed.  rule #1

does state.    " Event structures begin waiting for events as soon as the VI runs."    So I think I understand it now.

 

altenbach said:

 

     Why the question mark at the end if you tested and verified it yourself?

 

I was thinking this is the reason but not sure, so asking.  I didn't think my verification was complete and through and didn't want to jump to conclusions.

Message 13 of 14
(265 Views)

Well, as I stated earlier today.. " you are not the first person to struggle with event structure usage! "

 

This thread was started by a group of LabVIEW developers bucking for CLD certification.  THEY, event structures, DO break dataflow!!!!! and just like locals can be miss-used.

 

On the Breakpoint board we have threads dedicated to local variable-missue and Rube-Goldberg LabVIEW constructs within LabVIEW

 

Perhaps it is time to start the Event thread

 

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 14 of 14
(242 Views)