How do you handle your status string updates?

[nathand]

I use a user event, which is pretty easy to trigger anywhere in the code and requires no polling to update the display when the status changes.

[crossrulz]

I prefer having all of my GUI code in the event structure.  This includes many of the front panel updates.  User events make my life a lot easier.

[Ben]

There have been a lot of high level ideas tossed about in this thread but Hakem's razor has not been mentioned.

---

@for(imstuck) wrote:

...

---

I *think* only the subVI with the property nodes runs in the UI thread but I'm not sure....

---

Provided

the VI with the property node is NOT configured to run in the UI thread

OR

the VI is not set to run same as caller with the caller running in the UI thread

then

Only the property node will execute in the UI thread. If you have multiple property nodes in the diagram then there will be multiple swaps to the UI thread

UNLESS

you have resized the property node such that it has multiple properties

THEN

There should only be one swap to the UI thread to apply all of the properites.

And if that naswer was not convoluted enough...

There was a bug in a recent version of LV where the exception about the re-sized prop node was not applied and there was a UI thread swap for every property.

I supose I should also quote Samuel Clemnts who once wrote "If all you have is a hammer, everything looks like a nail."

KISS

Ben

[User002]

---

@Ben wrote:

There have been a lot of high level ideas tossed about in this thread but Hakem's razor has not been mentioned.

(...)

I supose I should also quote Samuel Clemnts who once wrote "If all you have is a hammer, everything looks like a nail."

KISS

Ben

---

I can cite my dad who used to be a carpenter: "To build a house, you need more than a hammer and nails". 

/Roger

[Ben]

---

@User002 wrote:

...

I can cite my dad who used to be a carpenter: "To build a house, you need more than a hammer and nails". 

/Roger

---

Two fools were putting siding on a house, one on a ladder pounding and the other on the ground picking naisl out of coffee can and handing them to the one on the ladder.

The fool on the ladder watched as the fool on the ground picked the nails out of the can inspected them and discared some.

Fool on Ladder: Why are you throwing some of those nails away?

Fool on ground : Some of these nails have the head on the wrong end!

Fool on ladder: Save them for the other side of the house.

Jokes aside.

Question for the OOPish readers...

From what I have read there seems to be a limit to how far we can extend OOP beyond the under-lying functions (which scream to be re-used) and GUI specific functions and GUI appearence. For those that write a bunch of apps that all look similar there are probably more opertunities to re-use. In my case, my customers do not get together and agree that their apps should all look the same.

So how/where/when do you stop with the formal OOPing and just "get er done" ?

Ben

[User002]

---

@Ben wrote:

So how/where/when do you stop with the formal OOPing and just "get er done" ?

Ben

---

Speaking for myself.

LVOOP is a consequence of the tediousness of having to code excessively.

I view it as the lazy engineers tool to avoid unneccesary boilerplate code.

For example that logger, which I referred earlier in my post, wasn't written by me, but it is clean and it fits right in.

Perfect example of LVOOP gone right.

UI OOP is a bit weird if you ask me, I never got it really. Maybe I am a bit off the curve here?

Perhaps for some really elaborate UI's for some Teststand plugin or whatever. Beats me.

Anyway, when starting to overdesign stuff for the sake of some "bozo architect's" ego.

Then I must bring forward my protest and start to be an annoyance to the revered.

Br,

/Roger

[User002]

---

@User002 wrote:

 UI OOP is a bit weird if you ask me, I never got it really.  (...)

---

@With OOP I of course mean to use the mechanisms of OOP(inheritence overrides, etc), not merely using a glorified cluster, as most tend to create, in their belief, "object oriented programs" with an attitude like "w00t, I'm soo w1cked using LV cl@sses, imma' @rchitect n0w!!!". 

Br,

/Roger

[SteveChandler]

---

@Ben wrote:

There have been a lot of high level ideas tossed about in this thread but Hakem's razor has not been mentioned.

---

@for(imstuck) wrote:

...

---

I *think* only the subVI with the property nodes runs in the UI thread but I'm not sure....

---

Provided

the VI with the property node is NOT configured to run in the UI thread

OR

the VI is not set to run same as caller with the caller running in the UI thread

then

Only the property node will execute in the UI thread. If you have multiple property nodes in the diagram then there will be multiple swaps to the UI thread

UNLESS

you have resized the property node such that it has multiple properties

THEN

There should only be one swap to the UI thread to apply all of the properites.

And if that naswer was not convoluted enough...

There was a bug in a recent version of LV where the exception about the re-sized prop node was not applied and there was a UI thread swap for every property.

I supose I should also quote Samuel Clemnts who once wrote "If all you have is a hammer, everything looks like a nail."

KISS

Ben

---

Ben, this would make an excellent subject for a nugget or blog post.

[SteveChandler]

I don't think I have written a functional global since I discovered the DVR.

[User002]

---

@SteveChandler wrote:

I don't think I have written a functional global since I discovered the DVR.

---

DVR's are neat, but with a bit clunky block diagram representation.

NI should perhaps have "danger, danger" versions that does not force the referencing/dereferencing to be in the same VI.

Hijack/promo status lamp on! 

Check out my neato DVR ring buffer for 1d double, 2d double and waveforms: 

https://decibel.ni.com/content/docs/DOC-20403

Br,

/Roger