Should All Property Nodes go through UI thread?

[David_B]

Hi All,

I'm downloading this now and I'll take a look.  Let me know what you find as well.  (Just a quick update).

[Ben]

Thank you for the prompt response David.

Pleae let us know what you determine.

Ben

[David_B]

Alright, so I've verified the behavior in 8.5.1 and 8.6 as well.  The property node processes them all at once in versions 8.0.1 and 8.2.1.

I've filed a Corrective Action Request (CAR) with R&D and they'll be taking a look.  The CAR number is 125593 in case you'd like to check in on the progress of their work.

This may end up being something that was changed to its current behavior for a particular reason, but I'll post any news I hear back from R&D if that's the case.  Perhaps I could persuade a list from the end-users about Pros and Cons of both 'versions' to be posted?

[Pnt]

This has a very significant performance hit. (i can not think of any Pros)

If it is not a bug, it is VERY ANNOYING that NI changed the way property nodes execute, and there was no documentation, no briefing ! (as far as i know)

[Ben]

Thanks for the update David.

I thought something was funny with my LV 8.5.1 app but could not put my finger on it previously. 

I regularly develop apps with hundreds of controls and indicators that need updated very often through property nodes (you really don't want to see a VI that updates 100 plus indicators where all of the updates are done in the top level VI! We left that mess behind with LV 6.0). With muliple switch to the UI for multiple property manipulations this bug multiplies the UI hit by a factor of how many propries I am hitting.

So please switch it back and LV the lean-mean-machine it should be.

Ben

[Pnt]

Does someone knows what happened with this issue ?

Where can i find the progress of CAR 125593 ?

I could not find it in "known issues"

[David_B]

I've just checked into the status of this CAR.  It's been given an increased priority and it appears to be a hopeful addition to the next maintenance release.  Of course, there is not guarantee that it will make it in by then, but from the notes on the CAR, it is apparent that R&D is actively working on it.

Thanks,

[R_Beauchaine]

Rolf mentioned that not all property nodes cause a switch to UI thread. Does anyone know:

1. How to tell what thread a VI is running in or if it is switching to UI thread?

2. Which nodes cause a switch to UI thread, if not all do?

For example, if you have a VI that updates value property of controls in another VI, but not on its own FP, which VI is switching to UI thread?

Thanks, Rick

[LiciaP]

In general, I think that all property nodes run in UI thread. Anyway, there is no list available of everything that is handled by UI thread: surely, anything that has to do with front panel items, VI references etc.

The only thing you can know is that a property node requires the loading of the front panel into memory (just have a look at the help for the property node).

Also, it's not possible to know which thread a VI is running in, as it is an issue that is handled by LabVIEW and that the user cannot control. You can only control and set a preferred execution system for your VI (in VI properties).

Bye.

Licia 

[LabBEAN]

---

David_B wrote:

I've filed a Corrective Action Request (CAR) with R&D and they'll be taking a look.  The CAR number is 125593 in case you'd like to check in on the progress of their work.

---

Was this ever corrected?  I don't see the CAR number listed with the LabVIEW 8.6.1, 2009, or 2009 SP1 bug fixes.