LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Execute order of an event trigged by other event

Solved!
Go to solution

I think mcduff cracked the code for me!   *Now* I think I understand what the complaint is.  I read through the whole thread a couple times and I honestly couldn't *quite* get a handle on exactly what the issue was.

 

I don't think I'm introducing any new ideas here, but maybe I can pull them together in a way that makes sense to the OP.

 

We need a clear distinction between an "event" and the "action to take in response to the event".  Going back to the original post, you have 2 boolean controls on your GUI, labeled as A and B.  LabVIEW provides an Event Structure as a mechanism to catch events from the GUI (and custom user-defined ones too but no need to explore that now).  You can make event cases to "handle" events caused by GUI actions such as a user toggling the states of the A and B booleans.

 

The code inside a given event case defines the "action to take in response to the event."

 

With mcduff's help at interpreting, I believe you have the following desire:

1. upon event A, perform action A

2. upon event B, first perform action A, *then* perform action B

 

A mostly trivial way to accomplish this is just to think of "action A" and "action B" as function calls.  In LabVIEW, you would make a separate "sub-vi" out of the code involved for each action.  Then the event case that handles event A would simply call the "action A" sub-vi.  And the event case that handles event B would first call "action A" and then call "action B".   (First suggested by RavensFan back in msg #5.)

 

It seems to me that you're trying to rely way to much on events as a way to structure the sequence of code execution.  As though any time you want some code to execute, the way to do it is to fire an event (after having previously created an event case to "catch" and handle that event).  But a simple function call (aka "sub-vi" call) might be all you need.

 

In LabVIEW, firing an event is a very different kind of thing than making a function call.  It seems you may be treating them as though they're nearly interchangeable.  In LabVIEW, the part of the code that fires the event has no knowledge or control over when (or even *if*!) that event gets caught and handled.  That stuff happens *asynchronously*.   But a sub-vi call happens *synchronously*, and the code doing the calling can both know and control *when* (with no question of "if").

 

Moving beyond sub-vis, there are also quite a few different ways to defer action A or action B rather than trying to build their code directly into an event structure.  (see also mcduff in msg #12 and johntrich1971 in msg #17)

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 21 of 63
(1,378 Views)

@Kelvin_Price:

"A mostly trivial way to accomplish this is just to think of "action A" and "action B" as function calls.  In LabVIEW, you would make a separate "sub-vi" out of the code involved for each action.  Then the event case that handles event A would simply call the "action A" sub-vi.  And the event case that handles event B would first call "action A" and then call "action B".   (First suggested by RavensFan back in msg #5.)"

 

It's already been discussed. Please read message #4, #6 and #20 (case 2)

John4191

0 Kudos
Message 22 of 63
(1,363 Views)

out

*sigh*

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 23 of 63
(1,357 Views)

I'm guessing you have never wanted to learn and program in LabVIEW.  That someone is requiring you to code in LabVIEW and you want to resist it every step of the way.

Message 24 of 63
(1,345 Views)

I think it's clear at this point, you're either just a troll or just not willing to learn.

Or a dunning-kruger candidate. I called it first. Smiley LOL

0 Kudos
Message 25 of 63
(1,324 Views)

The OP has been shown that there are plenty of ways to easily following good coding practice accomplish his task, but he insists that LabVIEW is weak because it won't let him use his bad coding practice to accomplish the task. He is obviously a troll who never wanted to learn LabVIEW and didn't want a solution to the question he asked, which was "Is there a way?"

0 Kudos
Message 26 of 63
(1,332 Views)

@johntrich1971 wrote:

The OP has been shown that there are plenty of ways to easily following good coding practice accomplish his task, but he insists that LabVIEW is weak because it won't let him use his bad coding practice to accomplish the task. He is obviously a troll who never wanted to learn LabVIEW and didn't want a solution to the question he asked, which was "Is there a way?"


Guess who that is on the leftGuess who that is on the left

0 Kudos
Message 27 of 63
(1,330 Views)

@Intaris wrote:

@johntrich1971 wrote:

The OP has been shown that there are plenty of ways to easily following good coding practice accomplish his task, but he insists that LabVIEW is weak because it won't let him use his bad coding practice to accomplish the task. He is obviously a troll who never wanted to learn LabVIEW and didn't want a solution to the question he asked, which was "Is there a way?"


Guess who that is on the leftGuess who that is on the left


Notice the guy in the middle is left-handed (well, left-footed, at least)?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 28 of 63
(1,320 Views)

Just found out another LV logic weakpoint! even firing an event outside the loop, its execution order always LAST! . Again, have to modify the code according to Labview's logic and NOT user's logic...

All have to accept the truth 🙂

0 Kudos
Message 29 of 63
(1,293 Views)

But LabVIEW logic >> Your logic! (In my case, the two "logics" always agree :D)

 


@John4191 wrote:

... even firing an event outside the loop, its execution order always LAST! . Again, have to modify the code according to Labview's logic and NOT user's logic...


It is impossible to imagine what you are talking about unless you show us some simplified code. As I already mentioned, you can have events execute in parallel if programmed correctly (e.g. with two event structures, each in a different toplevel while loop, and both ready to fire.). LAbVIEW can be highly parallel, so "last" is a poorly defined word anyway.

 

I think you are still digging yourself deeper into a hole by taking overall flawed misconceived code and patching it with flawed workarounds instead of re-architecting it in the spirit of LabVIEW from scratch.

 

The solution is hidden in the old Apple ad campaign: Think Different!

 

TD.png

 

0 Kudos
Message 30 of 63
(1,287 Views)