jpdrolet

Voir le fichier joint pour la description de l'emploi.

Envoyez votre CV à mcgodin@itflabs.com

AffichageITFLabs20111108.pdf

This won't be too detailed, but it should point you in the right direction -

From the Application class properties you can get an array of all open Projects and from there you can get a ref to a specific Project. Then from the Project MyComputer property you can get the TargetItem and from there you can get BuildSpecs. Now you have a reference to the BuildSpecs and you can get a ref to the Children[] of the BuildSpecs and finally from there get a ref to the particular BuildSpec you want. Now, with a ref to the BuildSpec you want to modify, you can modify items inside the XML project file using ProjectItem Set Tag method. So, you do end up editing the project file but you can do it programatically using LabVIEW so the process can be automated.

Mark

It worked. Thanks a lot

I will use the VI BuildTargetBuildSpecification.vi to programmatically build a project but I first need to set some buildspec properties such as the destination folder and version number.

Are there VIs or properties I can use for this? I looked into the Properties and AppBuilder folder and I did not figured anything useful.

The only solution for the moment is to edit the project file (XML).

Any better ideas?

QUOTE (JodyK @ May 20 2009, 11:37 AM)

Yeah, I came to the same conclusion regarding the Config File VIs. Luckily, they are not locked so they could be replaced with an OpenG version. I'm not saying it would be easy, but it would definitely be doable.

Interesting note about the BSD license. I'm so used to the sourceforge and linux worlds where anything under BSD is always open source (or at least I can't think of any exceptions right now). How does the BSD license handle forks and derived works? In other words, if the locked MGI VIs were replaced how would that affect the project? Could it then be integrated into the OpenG toolkits or would MGI still have creative ownership over it?

-Jody

Indeed BSD is an Open Source licence. Redistribution of derived work doesn't require to include the source but the licensed code should definitely be available.

QUOTE (JodyK @ May 19 2009, 07:15 PM)

...or better, improve the performance of the OpenG INI tool.

-Jody

OpenG INI tools are wrapped around vi.lib's Config File VIs. The latter are the real problem for performance on large INI files. Optimizing OpenG INI VIs (like replacing recursion with a stack) would only marginally improve the performance on large INI files. Just try to replace Config Data Registry.vi (the core of Config File VIs) with a do nothing VI and you'll see that the remaining code (OpenG) takes only a smal fraction of the execution time.

I have not used MGI VIs but did take a look at the code. When operating on a file, it only parses the specified section of entries. There is a feature to pay attention for: when writing in a section, the whole section is erased and rewritten so previous existing keys that are not specifically rewritten in the current operation are lost. That allows great speed improvements and the only inconvenience is that you have to structure your data so that you don't write different pieces of data in the same section in multiple write operations.

Another justification:

QUOTE (Cat @ May 6 2009, 09:40 AM)

Still I go (did anyone other than me actually see the last ST in a movie theater? Or see it at all??).

I did see it at the theater too. However I had to drive 20min because it was not scheduled in theaters in my city...

Any clone made of Picard's hair is doomed to fail anyway... Janeway's hair on the other hand...

QUOTE (normandinf @ May 6 2009, 11:42 AM)

:thumbup:

Why the thumb up? 0! is factorial 0 not !0 (logic complement)

QUOTE (David Wisti @ May 6 2009, 11:37 AM)

From the help:

And Array Elements

Returns TRUE if all the elements in Boolean array are TRUE or if Boolean array is empty. Otherwise, the function returns FALSE. This function accepts an array of any size but returns only a single value based on all values in Boolean array.

And Multiply Array Elements returns 1 for empty arrays for the same reason as x^0==1 and 0!==1.

No elements to operate => return neutral element for that operation.

QUOTE (FLAnatic @ Apr 24 2009, 09:21 AM)

I would say that those who posts in threads that they themselves created just to keep the thread alive after everyone else on the board has lost interest are half-cannibals and are at animal level.

That's a broad statement. I'd say 97.7% of them...

QUOTE (newTOlabview @ Apr 30 2009, 08:51 AM)

I have an llb that needs edited in labview 5.0 when double clicking on the file it opens and runs the labview file when double clicking or right clicking in labview it will not allow me to see the data.

How do I do that in 5.0.

8.0 seemed much easier to use than 5.

File>Edit VI Library... Maybe?

I also have File Manager.vi under the Project menu but I don't remember if it is native to LabVIEW

QUOTE (Black Pearl @ Apr 29 2009, 07:48 AM)

Although set to 'top-level' (open front panel when called), it did not show up using the run method. I had to use the FP.Open property in the plugin vi.

That is the expected behavior when opening a VI with VI Server; you have to manage the FP opening explicitely.

About the compatibility issue between LabVIEW versions, whether you use exe or dll, you can't open a VI reference to a VI having a different version in your application instance. However, you can have an executable (7.1) running for example the 7.1 plugins and another 8.6 application invoking them opening first an application reference with the VI Server.

QUOTE (jdunham @ Apr 16 2009, 06:19 PM)

No worries! That's one of the reasons this forum exists. :thumbup:

To feel stupid???

QUOTE (Ton @ Apr 13 2009, 01:02 PM)

Or you could add an undocumented feature/backdoor, where a special key-combo openend the BD.

Ton

Did you try that? The debugged application is running in a Run-Time environment, where the BDWin.Open property is not supported.

QUOTE (asbo @ Apr 14 2009, 02:02 PM)

Since when has linux used UNC paths?

I didn't dare to put a unix path on a windows command line....

Ironically, using -pref /dev/null the application still creates the ini file.

QUOTE (Cat @ Apr 14 2009, 01:14 PM)

I'm working in the Windows world... is it possible to forbid *creation* of files in a folder?? I know I can make a folder read-only, but that's a different thing, and I need to be able to edit the couple ini's I do use in that folder.

As for your last suggestion, I agree with what Ben said...!

You can forbid creation of files in a folder by some or all users in the advanced Access Control Settings:

http://lavag.org/old_files/monthly_04_2009/post-447-1239730795.png' target="_blank">

However it is not very convenient if you use/modify some of the ini files.

The second option may be more useful. If the application users start the applications using shortcuts anyway, modify the command line to use a pref file from an inexistent location. The switch -pref \\DEV\NULL was a wink to linux but -pref nofile would also prevent the creation of the file because it is an unusable relative path; nofile is not a special keyword. Of course, the third option was a joke.

Indeed the file is created as application exits

I can only see some workarounds:

• Change folder access properties to forbid creation of files
  
• Start the application specifying the -pref switch to some inexistent location e.g. myapp.exe -pref \\DEV\NULL (requires a shortcut)
  
• Put the line CreateThisFile=FALSE in myapp.ini
  

QUOTE (gmart @ Apr 8 2009, 09:37 AM)

You shouldn't need to update the server version. What is needed is the later version of the P4SCC plugin.

I did and P4SCC did request a server version 2004.2 or later (from LabVIEW or P4Win). P4SCC 2008.1 does support our server version, P4SCC 2008.2 doesn't.

QUOTE (gmart @ Apr 8 2009, 09:37 AM)

Well LabVIEW can invoke the Revision Graph feature with our server and P4SCC 2008.1 while P4Win does request server version 2004.2 or later. Incentive to upgrade, maybe?

Thanks for replying.

Unfortunately, our Perforce server version is 2002.2 and the latest client supporting it is 2008.1 . Changing the SCC from Perforce SCM to Perforce Command Line prevents the popups. However we lose the neat Revision Graph feature.

That begs another question: using Perforce SCM why can LabVIEW invoke Perforce's Revision Graph feature (or close relative) while P4Win can't (or doesn't allow)? :ninja:

Display the hierarchy window and shift double-click the main VI icon.

When I build an application (LabVIEW 8.6) I get popups from Perforce (Perforce SCM version 2004.2) saying:

p4 fstat -P {1 files}

Path 'x:\Projets\BUILDS\internal.llb' is not under client's root 'c:\'.

Indeed the destination is not under the Perforce root as I don't keep executables under source control. The popups pause the build until I click OK. That is rather annoying since the second popup appears under the build status window so I have to check the windows bar (preventing me of doing other useful tasks).

It looks like a bug since internal.llb is a temporary file and there is no need to check its SCC status.

QUOTE (neB @ Jan 15 2009, 12:37 PM)

The Recursive File List handles that situation by check the "shortcut" output.

Ben

Thanks. One more reason to upgrade to 8.6...

Still do you think the behavior is appropriate?

QUOTE (neB @ Jan 15 2009, 12:37 PM)

The Recursive File List handles that situation by check the "shortcut" output.

Ben

Thanks. One more reason to upgrade to 8.6...

Still do you think the behavior is appropriate?

On Windows, the primitive File/Directory info returns info about the target file/directory when used on shortcuts, Open File on a shortcut opens the target and so on...

Do you think it is the appropriate behavior? For the OS itself, shortcuts are files.

If a VI lists a directory (as a shortcut C:\Folder1.lnk) and build a path with a listed file name, the result is wrong and unusable (e.g. C:\Folder1.lnk\file.txt").

One can check for the lnk extension but a file/directory can have this extension without being a shortcut... So how to be sure we deal with an actual file/dir instead of a shortcut?

On Windows, the primitive File/Directory info returns info about the target file/directory when used on shortcuts, Open File on a shortcut opens the target and so on...

Do you think it is the appropriate behavior? For the OS itself, shortcuts are files.

If a VI lists a directory (as a shortcut C:\Folder1.lnk) and build a path with a listed file name, the result is wrong and unusable (e.g. C:\Folder1.lnk\file.txt").

One can check for the lnk extension but a file/directory can have this extension without being a shortcut... So how to be sure we deal with an actual file/dir instead of a shortcut?