ShaunR

Yup. Jacks fault

Hyperbole

Nope. they live in the same dimension only aren't married

If you get rid of the imaqUSB.llb (usb is has been supported in MAX since V2009) you can just include the MAX configuration in the installer. USB Camera Error

Yes it does. It's just not what you think

There are many examples shipped with labview. Take a look at "charts.vi"

In fact. "classic" labview isn't that far removed from "lvoop". If you consider that controls are "setters", indicators are "getters" and inheritance is "create sub vi"

Indeed. Whats missing is that a generic refnum should have the option to "adapt-to-type" instead of being coerced. Properties and methods can already do this, so if the control refnum could also adapt, all the properties and methods inside your VI would follow suit. In effect, you would have a polymorphic VI without having to declare all the sub-vis (for these types of VIs at least).

Indeed. That's why I said it would be nice earlier. Although. If you think about it. When you open up the VI with the control ref. What should it display? The VI itself doesn't know what it's connected to; only the owning VI. The way "Classic" labvVew gets round this is the owning VI selects a VI with a compatible terminal and the only way you can tell it what VIs to select from is by defining a polymorphic VI. The fall-back is to coerce it, then a broken wire. Furthermore. If you think about classes (static ones). The owning VI is selecting the child class which you have previously defined. So in this instance there is no difference between a polymorphic VI and a Class (well. There maybe some but I can't think of any). After all. If you defined the "Boolean" class such that it wasn't a child (equivalent to a VI not attached to a polymorphic instance). You wouldn't be able to connect it either and Labview wouldn't even try to coerce it..

Yes. Because it is coerced!

Well. I read "I think what is wanted is that there is not a coercion dot, because the coercion never happens." to mean that even though there was a coercion dot, it wasn't being coerced. The comparison example was just to show that even in OOP, if you coerce (yes you have to do it manually) then the result is the same.

Agreed. It would be nice. But it kind-a indicates that coercion does happen. The VI's cannot statically change the control refnum without using polymorphism so it has no choice but to either give a broken wire or coerce the data on the wire to a compatible type. It gets even worse if you pop-up the right click menu on the boolean control ref and select "Include Data Type". You won't even be able to connect it to a standard boolean control ref. You will have to convert it to Bool(Strict) first.

I see what you mean. But your "Class" example isn't exactly analogous to the VI example (just being picky ). If you inspect your middle VI, you will see there is a coercion dot. So the equivalent class implementation would be As you can see. this also has the same issue. The class example is really analogous to creating a polymorphic VI

Try this.

Easiest way is to "map" a network drive and use different credentials. Then you wil end up with X:, Y:,Z: mapped to the different accounts either to the same remote dir or different ones.

I'm not sure what your asking here. Type information? If you mean the controls class (e.g boolean, string etc) then it is propagated (if you inspect the class name you will see it). If you mean you cannot connect a parent class refnum to a child class refnum and have it automagically choose the appropriate refnum then no. Because "classic" Labview doesn't support run-time polymorphism. You have to go to OOP and use dynamic despatch (which wouldn't be much different from creating your polymorphic VI). The only way I know of that you could achieve a similar behaviour in classic LV is to make all your refnums variants and coerce to the specific class within each VI. But then you can connect anything to anything so it wouldn't flag up (for example) that you had connected a real control rather than a refnum until you ran it.

Have you tried using the .NET TreeView control.? You have access to all TreeView functions and you can add callbacks (if you need them). You can even do things like embed other controls. Not that you need to, but it just demonstrates the huge feature set. It should be a lot faster for your purposes. I'm not a fan of .NET. But "The needs must as the Devil drives"

Try here

Another method is you can overlay a boolean array (flat square classic buttons work best) where the booleans are transparent except for the true state border colour. Then you just use the number to boolean array primitive to set one or more booleans "True" for the value or values you want to highlight in the main array. This will create a border around the value. But if you move it behind your array and make your array transparent, you can also make the boolean array "True" state bg coloured and it will look like you changed the background.

I suggest you re-read my response on your other thread asking exactly the same question. http://lavag.org/topic/13269-how-to-upload-image-into-labview/page__pid__79462#entry79462

Well. I can only talk about Solidworks. But it wasn't an image. It was a VRML file and you wrote a VI that solidworks could interact with. As such, you created a Solidworks plug-in. If you just want to get the image on the front panel, you can just download a jpg or png and use the "Import Image To Clipboard" and paste it on the front panel. . You could overlay Labview controls like dial gauges etc which you could use to simulate the controls with programming. But I don't think you will be able to define everything in the 3D package and just "import" to get a working simulation.

Sorry That must have been on LAVA 1.0 then

I use "phpMyAdmin". But of course it needs to be part of a web-server.