Northern European CLD Summits

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.
Highlighted

About the "Separating the UI from the decision making code" presentation

Hi,

In regards to this presentation, I was thingking about what was said and I came up with the following question:

If I use a property node to modify the status of a FP Control in my decision making code am I turning that thread into a UI thread?

0 Kudos
Message 1 of 5
(3,699 Views)
4 REPLIES

Re: About the "Separating the UI from the decision making code" presentation

I was interested in the answer too as I was pretty sure that was the case and seems like I am correct.


"Property nodes for controls always run in the UI thread" -- true

Anything under the "VI Server" category will always run in the UI thread. This includes VI references, Application references and all panel/diagram object references. If you are making a lot of these calls, you might consider moving them to a subVI that can be set to run in the UI thread. Other categories, like VISA, will use any thread. ActiveX has its own rules for which objects can be accessed from which threads. (If you don't have to know about apartments, trust me you don't want to.)

Quote from here: http://lavag.org/topic/15147-do-subvi-property-nodes-force-the-fp-into-memory/

0 Kudos
Message 2 of 5
(2,806 Views)

Re: About the "Separating the UI from the decision making code" presentation

Hi Sam,

Thank you for that, I was pretty sure that that was the case, but I wanted to double check.

What you have posted it also interesting for what it says about the VISA and the ActiveX categories, I wasn't aware of that.

At this moment the solution I am using sounds similar to what they suggest which is to separate the UI in a SubVI.

Thank you

0 Kudos
Message 3 of 5
(2,806 Views)

Re: About the "Separating the UI from the decision making code" presentation

Yes - I usually do the same.

In most of my applications, the top-level VI handles all of the user interface and I have SubVIs that run as modules/daemons to do the high speed stuff like DAQ/controlling tests etc. Of course - another common approach I've seen is to use a launcher and have your UI run as a seperate SubVI - this makes it easier when you want to have different user interfaces but usually this isn't needed in my applications.

0 Kudos
Message 4 of 5
(2,806 Views)

Re: About the "Separating the UI from the decision making code" presentation

Sam_Sharp wrote:

another common approach I've seen is to use a launcher and have your UI run as a seperate SubVI - this makes it easier when you want to have different user interfaces but usually this isn't needed in my applications.

Yeah, that sounds pretty much like mine!!

0 Kudos
Message 5 of 5
(2,806 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.