Weather Problem

[altenbach]

Good question! Without it, the event structure would just sit there for 10 seconds or until one button has been pressed. Before that, the indicator just displays whatever was there before the run (empty string, result from previous run, whatever you typed in there in edit mode, ...). The zero timeout ensures that the indicator immediately updates and displays a defined result right after running, even if no button is pressed.

[Hooovahh]

---

@Gregory

Why start with a timeout of zero?

This is so that the timeout is ran immediately, sorta like a First Call function but triggers the timeout the first time, then waits 10s to run again.  My first reaction would have been to do something like a value signaling change on Hot right away, and just leave the timeout to -1 or remove it, but functionally it is basically the same.

[paul.r]

It doesnt matter in this application, but I was curious so I tested and that is not a guarantee that the timeout will fire first, if anyone else didn't know that. (Again, I wasnt sure how the events got queued up if value changes occured before the event structure was run.)

[altenbach]

---

@paul.r wrote:

It doesnt really matter in this application, but I was curious so I tested and that is not a guarantee that the timeout will fire first, FYI.

---

Which problem are you talking about and what did you test? In my code, The SR initialization with zero guarantees that the timeout will trigger first. (If you e.g. don't initialize the shift register, it would wait on the second run and not update right away).

[paul.r]

---

@altenbach wrote:

---

@paul.r wrote:

It doesnt really matter in this application, but I was curious so I tested and that is not a guarantee that the timeout will fire first, FYI.

---

Which problem are you talking about and what did you test? In my code, The SR initialization with zero guarantees that the timeout will trigger first. (If you e.g. don't initialize the shift register, it would wait on the second run and not update right away).

---

My comment wasn't really clear - I was speaking generally about event structures, not this specific implementation - wiring a 0 timeout doesnt always guarantee that the timeout event will fire first. 

[altenbach]

---

@paul.r wrote:
My comment wasn't really clear - I was speaking generally about event structures, not this specific implementation - wiring a 0 timeout doesnt always guarantee that the timeout event will fire first. 

---

Yes it will, but only if best practices are followed. Of course if you hide your event structure in a case structure or otherwise delay it by dataflow constraints, many other events could get queued up before the event structure is even reachable and can start executing. In this case, all queued up event will execute first of course.

This is more an architectural problem. Can you show a legitimate case where your statement is still true?

There are alternatives where certain events are queued up via val(sgnl) properties as suggested by Hooovahh above, but then you would not do my zero timeout init anyway. Note that there is also this idea, but read my long comment.

[paul.r]

---

@altenbach wrote:

---

@paul.r wrote:
My comment wasn't really clear - I was speaking generally about event structures, not this specific implementation - wiring a 0 timeout doesnt always guarantee that the timeout event will fire first. 

---

Yes it will, but only if best practices are followed. Of course if you hide your event structure in a case structure or otherwise delay it by dataflow constraints, many other events could get queued up before the event structure is even reachable and can start executing. In this case, all queued up event will execute first of course.

This is more an architectural problem. Can you show a legitimate case where your statement is still true?

There are alternatives where certain events are queued up via val(sgnl) properties as suggested by Hooovahh above, but then you would not do my zero timeout init anyway. Note that there is also this idea, but read my long comment.

---

Any time you generate user events (or value changes) in a parallel loop? 

I read Hoovahs comment assuming he meant that wiring a 0 to the timeout would always guarantee that event would fire first. I thought to myself, that cant be right, is it? Im sure he knows thats not the case, but I figured I would post in case anyone else jumped to that conclusion as well. 

[Hooovahh]

Sorry if I wasn't clear.  Wiring a 0 to the timeout doesn't guarantee that the timeout event will be generated next.  I was explaining what the purpose of the timeout being 0 the first time was in this example, and what it accomplished.  In this case wiring a 0 to the timeout does mean the timeout will occur first, only if no events are waiting in the event structure to be handled, and on first run of this VI, the likelihood you will generate an event before entering the timeout of the event structure is essentially zero since nothing is generating those events except UI interactions in this case.