Need help with Dynamic Events

[MarcDub · Accepted solution]

You are missing the generate user event call, that I had put in the "Case1:Value Change" event case (see below).

Notice that I am not sure what you are trying to accomplish. I have just answered your specific questions about user events.

[rhodesengr]

Got it. Thanks so much. I have it working both ways now but the Generate event method is better and would allow event cases to cascade one after another. 

[Ben]

---

@rhodesengr wrote:

Got it. Thanks so much. I have it working both ways now but the Generate event method is better and would allow event cases to cascade one after another. 

---

Watch out for an avalanche!

Ben

[crossrulz]

---

@Ben wrote:

---

@rhodesengr wrote:

Got it. Thanks so much. I have it working both ways now but the Generate event method is better and would allow event cases to cascade one after another. 

---

Watch out for an avalanche!

---

Agree with Ben here.  You have to be VERY careful when you have cascading events due to an Event case causing another event.  You might be better off using a Queued Message Handler and then the event case just queues up all of the things the QMH is supposed to do.

[rhodesengr]

---

---

Agree with Ben here.  You have to be VERY careful when you have cascading events due to an Event case causing another event.  You might be better off using a Queued Message Handler and then the event case just queues up all of the things the QMH is supposed to do

---

What is the downside of one case triggering another?

[crossrulz]

---

@rhodesengr wrote:

---

---

Agree with Ben here.  You have to be VERY careful when you have cascading events due to an Event case causing another event.  You might be better off using a Queued Message Handler and then the event case just queues up all of the things the QMH is supposed to do

---

What is the downside of one case triggering another?

---

It is very easy to create a circular string of Events that you cannot break (A to B to C to A, etc), along the same lines as to why we state to not let a Queued Message Handler queue up tasks for itself.

Plus, it becomes hard to follow.  Case A to Case B to Case C is a lot of clicking to see the full chain.  Where if you used a QMH, the single case queues up all of the tasks to be done and you have a simple high level of what is being done right there in a single case.  You can dive into the QMH if you want to see more details.

[Ben]

---

@rhodesengr wrote:

---

---

Agree with Ben here.  You have to be VERY careful when you have cascading events due to an Event case causing another event.  You might be better off using a Queued Message Handler and then the event case just queues up all of the things the QMH is supposed to do

---

What is the downside of one case triggering another?

---

Adding to what Tim already wrote...

Chaos

Seldom a good thing in software.

I still want to urge that the cod you want to put in each of theses events should be in sub-VI's. One for each event. When you find you need to implement some type of sequence, you string the sub-VIs together and sequence the operations using data flow. Doing it that way makes it obvious to the reader of your code (could be you someday!) what order is being implemented. After all this is LabVIEW not HPVee.

Ben