03-12-2008 09:55 PM
Can I ask one question? Are you a "seasoned" text-based programmer?
Just curious 😉
03-12-2008 10:19 PM
03-13-2008 08:33 AM
LOL!! 😄 You've answered my question. And are probably on the right track... 😉
I didn't realize it, but we all seem to try to program Labview as if it was a text based language.. But it's not. The approach is (how to say this) "completely" different.. Although "completely" is a bit harsh..
You have to think in terms of dataflow. And the variable is the wire. Forget all you know about Globals & Locals, which were your friends and are now your enemy. Forget about the sequence (and especially the Sequence Structures (Stacked) ). The execution is based on available data. The flow is based on data availability on the wire. Any portion of code will execute as soon as all the data it requires (to execute) is available. So race conditions become an important issue.
A good place to see a lot of common mistakes is to visit the Rube Goldberg thread in the Breakpoint forum.. but don't forget to laugh... we've all been there.. 😄
03-13-2008 09:07 AM
Oh, how I wish that weren't so true, me included! The number of times I've looked at my own code and said "What the heck was I thinking?!?!?!"
@JoeLabView wrote:
but don't forget to laugh... we've all been there.. 😄
03-13-2008 09:50 AM
As mentioned, the key here is the difference between the data and the control - since controls and indicators can also double as function parameters and return values, this might be a bit confusing.
First, it is important to understand that a wire passes only data of its type - it has no meta data which relates to the control it came from (that's not actually correct, but we won't go into that), so you can wire any two controls and indicators as long as their data types are compatible.
All front panel objects must be allocated in the vi that owns the front panel and they only exist in that panel.
Objects that are "passed" as indicators(outputs) of the parent into the control (input) of the subvi(child) are not pointers but cause a memcopy into a new instance of the object.
03-13-2008 11:24 AM
03-13-2008 01:18 PM
03-13-2008 02:13 PM
That's correct, as long as you replace "an object" with "an object of the Control class or any of its inherited classes". As Ray mentioned, the property and invoke nodes are also used for accessing other class hierarchies.
Clueless1 wrote:
So, the bottom line is that an object, comprised of three kinds of data - 1.properties, 2. methods and 3. wirable data (which is also available as a property) can only exist in the context of it's owning vi front panel.
03-13-2008 02:24 PM
You can also get an image of the graph and then draw it in a picture indicator. Would look the same. (But you cannot interact with it in the same way, of course)
tst wrote:
...One example would be XControls, which are custom controls which have code behind them. Another would be using subpanels, .... Another (which JLV mentioned) is using VI templates. Another would be using a subVI to set the properties of the control and calling it in both VIs, etc.
03-13-2008 06:16 PM
You can also get an image of the graph and then draw it in a picture indicator. Would look the same. (But you cannot interact with it in the same way, of course)
Well, this would solve the problem i just encountered whereby you cannot have an array of graphs. I assume it would be OK to have an array of pictures of graphs. Yes?