crelf

This is all really old info, but if might work.

Try http://forums.lavag....tions-t122.html and http://forums.ni.com...p/469196/page/2 and the following from The Engineering Handbook:

Application Building (Creating executables)

Often left to the last minute in application development, building stand-alone executable code may not be as straightforward as one might expect. External code libraries, target operating systems, engines, and licenses must be considered before attempting to build an application.

The Run Time Engine (RTE)

Built executables require elements of the LabVIEW RTE to execute. The RTE should be distributed with your applications, as the target PC may not have it installed, and your applications will therefore fail to execute. The location of the RTE installed on a LabVIEW development PC is:

..\National Instruments\Shared\LabVIEW Run-Time\Version\

and a re-distributable version is located on the LabVIEW installation CD-ROM:

..\LVRunTimeEng\

Although manual distribution of the RTE is possible, it can be automated when distributing your built software, using an installer as detailed below. In some cases, the installation of the RTE is not necessary[1]. If an executable is a simple one, it may not need the RTE to be installed on the target machine at all - all one needs to do is include some of the engine's files with the exe for it to work. To test if this method will work with a particular built executable, copy the following files & folders into the folder containing the exe:

..\National Instruments\shared\nicontdt.dll

..\National Instruments\shared\nicont.dll

..\National Instruments\shared\LabVIEW Run-Time\ver\* (including all sub-directories)

Using the LabVIEW 6.1 development system as an example, the exe's directory would look something like:

..\AppDirectory\MyApp.exe

..\AppDirectory\MyApp.ini

..\AppDirectory\My_Apps_DLLs (if_any)

..\AppDirectory\nicontdt.dll

..\AppDirectory\nicont.dll

..\AppDirectory\lvapp.rsc

..\AppDirectory\lvjpeg.dll

..\AppDirectory\lvpng.dll

..\AppDirectory\lvrt.dll

..\AppDirectory\mesa.dll

..\AppDirectory\serpdrv

..\AppDirectory\models\*

..\AppDirectory\errors\*

..\AppDirectory\script\*

When the executable is launched on a PC without the RTE installed, it should find all of the RTE files it requires in the application’s root directory, and execute normally. This method can be particularly useful when distributing autorun presentations on CD-ROMs.

As built executables have a similar structure to VI libraries, it is possible to extract and use the diagramless VIs within. Simply change the extension of the executable file to llb, and open the library within LabVIEW. One should be careful when designing the architecture of a commercial application, as this G executable characteristic can allow users to reverse engineer an executable, effectively accessing the functionality of the SubVIs within the executable.

[1] This method is not authorised or supported by NI and does not support DataSocket, NI-Reports, or 3D Graphs.

I'm guessing that your answer might be in the TWAIN spec. I don't know how to do it, but I'd love to hear what you come up with

Odd - I've used PayPal for years and never had any issues.

Did you remove its front panel?

I think Station Globals are fine - if you need to have something share across projects (which, I must admit, is very rare).

Chris Relf... a man whose wisdom runs so deep he quotes himself!

My wisdom is both reentrant and reentrant.

Maybe a dropbox of all VIs in the Class would have made more sense too? You could clone multiple methods at once, but that is not my usually use case.

Yeah, that's a very rare use case for me. It's more of a clone class than a clone method.

I could make it a separate Tools Menu action that operates on the Active VI - that might make more sense?

I guess, but I ultimately want Project Explorer integration - so I can right click on a method and clone it <- make it happen.

Public Service Announcement

You're welcome.

This feature was sponsored by:

Where drinking from a camouflaged can... ...makes you look tough.

Firstly, it was "Miller High Life", and secondly, it was in a camo can so people wouldn't know that I was drinking it

Feature Request: Clone a Method VI

I have updated the repository with a new version - you can now easily clone a method using this tool.

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.

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.

My current solution is to use one VISA session, one IVI session and an enum which lets the sub-VIs know which one to use. But it would be much nicer if I could somehow create a "wrapper" session...

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?

This is old....

....school

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.

i am not able to get the vertical scroll bar to show the last updated data.

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.

For the record (with properly named terminals!):

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.