jpdrolet

Voir le fichier joint pour la description de l'emploi. Envoyez votre CV à mcgodin@itflabs.com AffichageITFLabs20111108.pdf

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) 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) 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) 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) Why the thumb up? 0! is factorial 0 not !0 (logic complement)

QUOTE (David Wisti @ May 6 2009, 11:37 AM) 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) That's a broad statement. I'd say 97.7% of them...

QUOTE (newTOlabview @ Apr 30 2009, 08:51 AM) 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) 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) To feel stupid???

QUOTE (Ton @ Apr 13 2009, 01:02 PM) 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) 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) 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) 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) As far as the revision graph feature, Perforce SCM is Perforce's implementation of IDE SCC integration. So they expose whatever features they choose. I checked my P4Win (which is 2008.2) and it does have the Revision Graph option. I'm not sure if support for this is tied to the version of the server you are running. 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) 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) 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?