ShaunR

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.

I've only ever seen this done with Solidworks. I did play with it once many moons ago. It wasn't easy and didn't work very well since it required the CAD designers to define all the dynamics (which they didn't normally do). I don't know if you could do something with Sketchup. But here's a good place to start.. http://zone.ni.com/devzone/cda/tut/p/id/10592#toc3

Showing your age now Cat Even I don't remember being a Mod

Actually. Reading a little more than a casual scan. They actually refer to bytes. So maybe we should be inputting "\1B\04\00\n\r" A NAK is \15 which you wont see unless the string indicator is also set to either \ codes or hex display and an error is "?" The other thing to check is that you are using a "crossover" rs232 cable (NI part number 182238-02) rather than a "straight through".

+1 for MySQL if its going to be remote (MySQL is the No 1 solution for web-servers and its open source), You can also download Xampp which comes with MySQL and is a complete web-server so you can set up an industrial grade web-server in about 5 mins on your own PC. But the real expertise in databases (as Phillip points out) isn't what type you use (although I'd have to be held at gun-point to use MS Access ). It's how you design the "schema". I've used MySQL Workbench in the past and its pretty sweet (for MySQL).

Well spotted. It says in the manual: "The general protocol for Lightwave lasers consists of sending an ASCII “command string” with the following format: Escape lead-in char, command code, parameter, optional data, End of String." So this is correct. So try "\1B 0 40 \n\r

Not at all. I think it just got missed. Is this the sort of thing your after? (the thing in the for loop is "Interleave 1D array") I'd post the VI but don't have LV 7,1

I really appreciate the time your putting in on this. Especially as you already have an implementation. Wish I had come across that article sooner. I could have used the get_table and exec functions as well as the get_column_blob. If I get time at the end of this I might look into it further, but I don't think the possible improvements would be hugely different. I'd rather concentrate on other OSs and the feature-list for now. True. But I don't really see this API being used for internet or remote web-based applications (famous last words ). It would be far easier for people with malicious intent just to delete the file. That's not to say I haven't thought about it. It's something I will look more closely at once I have a more complete feature-list (vtables springs to mind ) The API comes shipped with an X64 dll. you didn't need to create one, just load the project. I've put in the cpability for different OSs. The issue I have is that I don't have Labview on Linux or Mac (well. don't even have a Mac ). But I have got VMWare versions of the OSs although never really used them much. The upshot is that I can't test on those platforms therefore only windows x64 and x32 are supported. I did however include the Linux x32 .so which has been reported as working. But I tend to be an all or nothing kind-a-guy. So if I say it works on Linux (for example) it bloody well better I'm using code:blocks with the MinGW x32 and x64compilers. They were easy to set up and worked pretty much out of the box. But as for setting up for Linux or Mac. I've no idea of the compiler/linker settings to cross compile. If I could get it set up for Mac, I could download the MAC trial from the NI website and test. But the Linux version seems like rocking-horse droppings Something must have changed. The 350 / 90 I quoted earlier was on LV 2009 x64 on Win7. LV 2009 x32 (Win7 x32) is about 350 / 110. Moving to 2010x64 and in-lining it goes down to ~300 / 70. But who are we kidding Bloody fast either way . I'm just happy it isn't 4 seconds any more I don't mind if its just shy of a gnats wisker! (goes down to 60ms with your earlier suggestion about the "step" ) Are you using "shared cache"? I open shared cache by default so that I can have multiple fast asynchronous readers. If your not, then you won't see it. But if you go through my API and set re-entrant willy-nilly you will run into it if you run multiple readers and writers asynchronously. Makes sense. This is particularly pertinent to embedded XP PCs, many of which come with SSD drives or SD cards. You can't use an in-memory DB with the standard high level API components, by the way, since they open and close the DB on each call (Well. You can, but there is no benefit). That's why I included the low level VIs so that if anyone wanted to use an in-memory DB they could roll their own.

This by maybe of use. I've never used it but would be worth a try.

Be careful with this. For in-lining all the in-lined vis must be re-entrant. This can cause "database locked" errors when running concurrently even with shared cache. Choose which ones are in-lined very carefully. (You'll get about another 10 ms by doing this and LV2010 is about 10 ms faster than LV2009 too ) As an aside. I'd love to see the result from using SQLite on an SD drive. I'm very impressed with SQLite and will be using it a lot in future.