crelf

Firstly, it was "Miller High Life", and secondly, it was in a camo can so people wouldn't know that I was drinking it I like it (not sure why that functionality isn't there in base LabVIEW, although I usually use the Endevo GDS for cloning), but I'm not sure it's intuative. For example, you're opening your tool and cloning a method from one class to another, but I find it difficult to know which method I'm cloning once I'm in the assistant. I guess project explorer integration would help this (eg: right click on a method and choose "Clone", then have a dialog that lets me select the target class <- that's how the Endevo GDS works). This would men breaking up your assitant's functionalites to groups (no longer a monolithic UI), but I think that would be more intuative in the long run. btw: The reason that I'm suggesting changes is that I think that this tool has a real future - as I said, there's some stuff in it that I think should be included in LabVIEW by default, so I think it's probably a good time to start discussing use cases outside of your own, writing down features and planning out medium-term goals for it.

Can you upload the code so we can see it?

Calrifying the name of a phenomena to better describe it is good scientific practise.

Welcome to LAVA! I'm with Shaun - IVI is theoretically awesome, but it falls in practice. I'm not sure if there were things that the IVI Foundation just didn't think through, or if it's that the standard wasn't meant to be as all-encompassing as I'd expected. That said, for what it is, it works well. The interchangability in VISA, for that matter, has gotten me out of some tight spots more than once. On to your issue: your post screams OOP. Sounds like you want a parent class that has some common stuff in it and 2 child classes (one for VISA, one for IVI) that have methods to override the parent methods for opwn, write, read, close, etc. Have you thought of using LVOOP?

Nice job Jon - looks good

What exactly do you want to change? There's a *lot* of stuff you can do with DAQmx property nodes, and you can load in an ncs (or partial hardware prepresentations).

That's certainly odd behaviour: can you please post an example of a project tthat does this?

The config file palette was in 6.x, and I think it uses that library?

True dat.... ...boy howdy

Crikey!

Honestly, the issue you're having could be a lot of things. Upload your code so we can make suggestions.

Please upload an example of your issue - it's a lot easier to make suggestions when we know what we're dealing with.

Personally, I think that XNodes could be the next big thing we push NI to release officially. I mean, look what we did for scripting. We could start by creating more examples that use XNodes, and maybe clean up the documentation a little on the LabVIEWwiki. Anyone with me?

I talked to Jervin: NI had let their package repository license expire so the LabVIEW Tools Network was down for a short while - should be all good now.

Sounds like something for the LabVIEW Idea Exchange.

There you go! That's much better

It's complaning that there's no unadulterated path between the object input and the object output, which you need for dynamic dispatch methods. In the non-broken exaple you have the same object type wired to the object in and out, but in the broken one you don't.

Also, some resigtry keys are in different places between the different OS's - if you're using absolute paths to your keys you ight run in to trouble.

Oooooooooooo - that's nasty! I assume you've already told NI? If so, can you link to the thread or post a CAR #? Idea: can you select the build items in the correct order (Ctrl + click) and then hit build selected? I seem to remeber that working back in the earlier 8.x days...