jpdrolet

I don't want to get into a philosophical argument either but what you really want is for LLBs to look like directories, feel like directories and behave like directories regarding the OS and other applications... You want them to be no different than directories... In short you want them to be directories... I am not aware of a SCC application that manipulates and controls files within compressed files (ZIP) (correct me if I am wrong). Shell extensions can be made to hook into Windows Explorer and peek into ZIP files and LLBs and display their content as it would belong the the file hierarchy. However, other applications do not use Explorer hooks to access files, they use the file system API where ZIP files and LLBs are simply plain files. It would be a LOT of trouble (for very little gain) to integrate a LLB as a subfile system in the file system. NI distributes most of LabVIEW VIs in LLBs. That is what LLBs are useful for: distribution. I myself distribute my applications VIs packed in executables and LLBs but I develop them as VI files. I'm quite sure NI also develops its VIs as files and packed them in LLBs only when a version is ready for distribution (I'm curious how they handle Open/Create/Replace File.vi...) So you are free to use LLBs but do not expect them to be directories or that further development will be made for LLBs to gain the advantages of using individual files and directories.

Nice tool Michael. My nitpick : In _JKI PBD Controller.vi_ the logic to build the path to _JKI PBD gui.vi_ accounting for Dev/Run-Time is not needed. Simply set the path to the constant _support\JKI PBD gui.vi_ In Development Environment, when _Open VI Reference_ has a relative VI path, the path is completed relative to the calling VI location (the folder/LLB the VI is in) In Run-Time, when _Open VI Reference_ is called the internal LLB is first checked for a VI with a name corresponding to _JKI PBD gui.vi_. The actual path is ignored when the VI is found in the internal LLB. In both situations the VI will be found using the relative path _support\JKI PBD gui.vi_

I've seen this message but in different context. Look into your labview.ini file and see if there is any old file path referring to d:\ It may cause LabVIEW to look for the drive d:\

Just buy a Parallel Port card that you plug in the ISA bus...

The way you used them, executables were no different than LLBs so continue to deploy with LLBs instead of EXEs.

Perl really looks like an explosion in an ASCII factory... (slashdot quote)

It works with _System Exec.vi_ provided you set the command to cmd \c "path\to\any\doc.type" Set Run Minimized to True.

That is the quantum wave equation of the hydrogen atom. And I'm white too... :laugh:

I have not tried the technique but you could try to open TCP connections to NetBIOS ports 139 and 445 of the remote computer to see if it is serving files. If one of the connections open without error then most probably the computer is online for filesharing. You can then close the connection and open the file. When the computer is not online, you have control on the timeout input of _TCP Open Connection_ to set how long is too long to wait. Alternatively, you could call the file function in a VI spawned in parallel to your main code and if the VI doesn't resume with valid data after some delay (shorter than the network timeout) resume the main code letting the spawned VI running until the file function times out.

For the sake of completeness, in LabVIEW 8.2 and probably 8.0 too, the function _Format into String_ accepts relative time formats such as %<%H:%M:%S>t

Michael! I think it's time you put your priorities at the right place... *looks at Barbie Girl video...*** Real G'eeks don't watch retard teenagers videos! *looks some more videos... (humm nice)* LAVA founders don't listen Britney Spears (edit:oops! Aqua) music! What an example to set for weakest members? *watches even more videos...(wow very cool!)* AAArgh!!! I'm addicted too! Look what you've done!

You have to use a loop anyway to gather the next piece of data so what is the problem? Set a large timeout on the Read function so it won't loop wildly. To abort the waiting Read function close the TCP connection and it will stop immediatly with an error.

Once the tcp connexion is opened, the proper function to use is TCP Read. TCP Listen is used to wait incoming connexions from clients.

That is not true. There is a field in the flattened variant string that tells how many variant attributes there are, followed by the flattened attributes.

Definitely you need OpenG Data Tools to manipulate variants. The input will convert to a variant but the output will stay a variant that you will have to convert back to typed data on the calling diagram. On the diagram it will look like that: This OpenG VI parses the elements from an arbitrary cluster and read their values from an INI file and returns the cluster as a variant. The caller converts the data back to the type of the cluster.

You can try the setting "Library Directory" but it also sets the location of vi.lib To create symbolic link directories I successfully used the tool Junction from Sysinternals.

The Wait functions are not interruptible so when you put them in a while loop, the loop will take 10 min to execute. Instead of using a Wait function, create a notifier and use Wait Notification (with timeout) which can be interrupted by sending a notification or destroying the refnum. If the Wait Notification times out with no error, this indicates that the loop can run next iteration. If it doesn't time out (notification received) or output an error (refnum destroyed) the loop can exit.

There is also the VI property FP.State that can be set to Hidden. With a hidden top level window, the executable continues to run. I'm not sure it can prevent the flicker.

I guess that your control is corrupted. If it is a typedef, try opening the control file only. If it crashes LabVIEW, use revert to a backup copy or send it to NI, they may be able to fix it. Is your control HUGE (cluster with hundreds of elements)? That might be the problem

You can take a look at the VI Parse Formula String.vi which analyzes the syntax of a formula string. However, variables names are limited to a single lowercase letter alone of followed with a single digit. You can use Substitute Variables.vi to map your variable names to legal names. The binary operators OR and AND are not supported either so you have to substitue them with valid operators such as + and *. For example, map your formula (VARIABLEA AND VARIABLEC OR VARIABLE B to ((a) * (c) + (b) and the check the syntax using Parse Formula String.vi

I think it is a compressed set of XML documents. You can decompressed the file to get the XML documents or set an option in OOo to save the files uncompressed.

Read the User's Manuals of Printer and Scanner and implement a driver. Sorry, that is the best help we can offer with the information you provided.

From the Wikipaedia article: Dot Countries: Canada(English speaking) Comma Countries: Canada(French Speaking) :headbang: A confused Canadian in Canada...

I agree with that. Reserve a fixed length header in the file. Files are random access, you can rewrite the header every time is is needed.

Well that is a Cylon. The bad guys from Battlestar Galactica. I got hooked by this sci-fi series. No technobabble, no alien/widget of the week. It has good drama and character development. Some will find Cylon Number Six more attractive... but machine/human mating is disgusting...