ShaunR

Confirmed. I'll leave it a week or two so to see if anything else crops up then release a bug fix.

Thats pretty much what mine does. Tags are very flexible and you can add more and more as the need arises. Although I found it easier just to define a tag rather than have a fancy interface for managing them.

ISTool is the GUI I use.I haven''t come across any bugs (not saying there aren't any) and it's been around a lot longer than the Inno one (5 years+).

If your thinking about password protecting some or all of your code........I seem to remember reading at one point (it's disappeared since the super-new download section....fantastic by the way ) that uploads to LAVA must include source and must not be protected with a password. Perhaps an admin can carify that?

They are fun until you see things like this: ^(?((Jan(uary)?|Ma(r(ch)?|y)|Jul(y)?|Aug(ust)?|Oct(ober)?|Dec(ember)?)\ 31)|((Jan(uary)?|Ma(r(ch)?|y)|Apr(il)?|Ju((ly?)|(ne?))|Aug(ust)?|Oct(ober)?|(Sept|Nov|Dec)(ember)?)\ (0?[1-9]|([12]\d)|30))|(Feb(ruary)?\ (0?[1-9]|1\d|2[0-8]|(29(?=,\ ((1[6-9]|[2-9]\d)(0[48]|[2468][048]|[13579][26])|((16|[2468][048]|[3579][26])00)))))))\,\ ((1[6-9]|[2-9]\d)\d{2})) Regexlib.com is a great place for 'em. And each one has a test button so you can try it out on your own strings

Sweet. Can't try it because of all the jki stuff. But I get the jist of it. I notice you use a regex to find the labels. Is that because they can be buried in text paragraphs on the BD?

If you can use an RTD then you can use a normal DAQ card and you don't need to worry about CJC .If you have to use a thermocouple, then you can still use a DAQ, but you will ave to provide your own CJC as you already know. That's the hard part

You can only have a tree in column 0. But you can put data in the other columns

Of course. I was just being pedantic. But that does mean that all the VIs have to be in memory and therefore you have to load the whole application which I don't often do until near the end and especially if I'm not working on it at that time. But I'm a great fan of check-lists and its nice to give someone a list and for them to come back with all the boxes ticked which can then go in the system to prove they have been covered (especially for progress meetings). I even print them for myself and pin it to the wall so tat I have a list of stuff I can cross-off. It's more tracking than anything else (like JCarmodys requirements thingy) and it's super easy to do.

Oooh. I've not seen that (or forgotten it). Mine is a bit simpler and targets todos only. But I love the idea for requirements tracking using comments and it's not a great leap (method is the same maybe just need a tag.). I've recently updated mine with a database so you can do queries on different todos so that would make requirements tracking and reporting a breeze. Did you ever upload it?

Yup. But you can't print it out and give it to an underling

I opted for "Todo" comments with some simple keywords (like <ICON>* and <DOC>. I then wrote a VI that would scan the diagrams in a project, directory or memory and extract the ToDo comments giving me a nice categorised check-list of all the outstanding things to do.

It's a mine-field It's difficult enough with so many licenses let alone sub-dividing within your software. If you distribute an app with a particular license, people will assume that it covers all aspects of that software. If you have different components within that software that have a different licenses you're (IMHO) setting them up to breach some of your licensing. Sure they "should" read all the conditions but do you if you see a product that says it's released under the BSD in the CR? Or do you already know the BSD and not bother reading the licensing? You could release it under "other", then have a detailed document provided with the download that explicitly states what parts/modules have what licenses and summarise what they can ad can't do to make it absolutely clear and hope that they read it and the other licenses. However the user has to download and read everything before deciding whether the licensing is appropriate for their use rather than just looking at the software page. Alternatively, you could release them as separate distributions, with their own licensing, and make your app dependent on those "modules". This makes things much clearer to the end user but requires the user to download sub-components to use your app. This isn't a problem with the JKI package manager, but a real bugbear for those that don't use it and might mean they don't download at all. The third alternative, of course, is that you only have 1 license to cover all the software and it's components and not complicate matters. It's only really an issue if you want to sell your software or components. After all, how "FREE" is your software if you have to buy the dependencies?

You can combine UI elements into a typedef. But you cannot have some as controls, whilst others are indicators within the cluster (the cluster is either one OR the other).

So obscure you had to look it up "TWICE"

7zip isn't a compression method. It's really a unifying (and extendible) interface to several methods the default being LZMA. As such, it's really pants to try and wrap it in LV (ever wonder why no-one has written a LV wrapper?) It'd be much easier to compile the separate dlls (zip,LZMA et al) and use those. But the OP only wants one....any one!, As long a it can do >2GB. If the openG implementation can do it then all he needs is the x64 dll and it'll plop straight in.

Name: Fast Trim Submitter: ShaunR Submitted: 03 Jan 2011 File Updated: 16 Jan 2011 Category: *Uncertified* LabVIEW Version: 2009 License Type: BSD (Most common) Just an alternative to the in-built "Trim whitespace.vi" function but much faster (3x?). It's not a direct replacement (although it could be) since it does not allow left and right trim separately. But it does allow trimming of all non-printable characters as well as whitespace if required (default is just whitepace). It's an offshoot from one of my projects that I thought may be of interest to the speed freaks out there. Click here to download this file

I'm not aware of 64 bit support for the OpenG Zip package. (I'm also not aware of a rar implementation at all). There was a discussion here a while back. Might be worth nudging Rolf nicely to see how far he got.

The NI site discusses some work-arounds. Bit it 'aint pretty. I don't know if the OpenG zip implementation is also restricted or not (2GB is a limitation of the original Zip spec, I think). But you could give that a try.

Version 1.3.0 has just been released. It is now hosted on a different server. You can download it at LabVIEW-Tools but I will still support it here as well, since I spend my life here

I would use 2 queues since command-response are instrinsicly ordered. Place your command onto a queue. When a response is received, read an element from the command queue and add it, AND the response onto another (log) queue. Then all you need to do is read the log queue to display the message-response list.

I'm not sure I ant to know what appendages you've embraced. ... Noodly or otherwise Although I'm willing to be converted if the "Halloween Missionaries" want to save me

Ooooh. Yes! and that reminds me of "PERVERT" "REVERT". For those "dead end" moments when you've been owned by the spaghetti

Rolf did some raw socket stuff a while ago that should be worth looking at.