Some help streamlining my new tool

[jed]

I need some help figuring out how to streamline a new tool.

I wrote a tool that is invoked by my SCC server; when a change is submitted, the server scans any submitted VIs and controls for revision changes and records them into the SCC's change spec. This allows me to track changes at a very atomic level.

But here's the trouble... the code for reading the history WITHOUT opening up VI dependencies only runs in the development environment. So the original EXE script that I wrote to do this doesn't work.

OK. I'll just invoke Labview with a command line argument to launch the VI I want and pass in the relevant SCC info. No dice. If LV is already running, the command line arguments are the ORIGINAL ones, not the ones used to call it the second time.

So what I have is a LV EXE that is invoked by the SCC. It calls my revision tool via VI server. This works, as long as LV is running. (I suppose I could start and stop LV, but I don't want to deal with that latency every time I submit- which can be often).

So now I have LV running 24/7 on my windows machine (windows 7 pro, no server). Is there a way to run the Dev environment as a service so that it's not running in the UI?

Any other ideas?

Thanks!

[texasaggie97]

I need some help figuring out how to streamline a new tool.

...

OK. I'll just invoke Labview with a command line argument to launch the VI I want and pass in the relevant SCC info. No dice. If LV is already running, the command line arguments are the ORIGINAL ones, not the ones used to call it the second time.

...

Any other ideas?

One thing you can do is make a copy of labview.exe and invoke that one with your new command line arguments. That way it doesn't matter if you have LabVIEW running or not. This will have the overhead of LabVIEW starting up each time, however.

[jed]

One thing you can do is make a copy of labview.exe and invoke that one with your new command line arguments. That way it doesn't matter if you have LabVIEW running or not. This will have the overhead of LabVIEW starting up each time, however.

I thought about that. It may come to that!

[Yair]

Options:

1. Don't use the revision history at all. That's what the SCC is for. Of course, that means you have to remember all the changes you made in order to log them.
2. Try using an older version of LV (such as 7.0) to read the data from the VI, as it will load faster. My guess is that this will probably not work, as it will fail when trying to open a reference to the VI.
3. There's apparently an option of activating scripting support in an EXE. This might be enough to allow the EXE to also read the revision history property. See here - http://decibel.ni.com/content/message/10063#10063

[Ton Plomp]

What SCC are you using?

If you use the integrated SCC provided by LabVIEW you can alter those VIs (vi.lib/sourcecontrol/providers) to actually store the parameters, however there is a small glitch: the LabVIEW SCC interface doesn't know which LabVIEW instance is actually running...

Ton