ShaunR

Well. Theres a lengthy form for downloading the sdk and you didn't include the call-back vi (was that supplied by the sdk?) so my input is probably going to be limited......but. What are you expecting it to do? Your while loop is just going to go round until you press the button, thats all you have really asked it to do. Unless there is communication from the call-back event to your VI (via a queue, event or something similar), you aren't going to be able to get any info back from it when it is actioned. A callback is called asynchronously and is a separate process to your VI The first thing I would check is that the call-back is actually being called. You can do that easily just by putting a dialogue prompt in it so that if it is called a dialogue will appear. If that works, then you can uses an event or queue to send whatever information is received (in the callback) back to your main VI.

Artois ?

A macro state is just a single sate that represents other multiple states (an alias if you like). Commonly, this would be things like initialisation/finalisation where (for example) the Init state could be an alias for Load Settings, Clear Display and then Set Window Position etc. But the term isn't limited to SMs , Excel has "Macro recording", for example, which will assign a single command to a number of operations that you do and will"replay" them back when executed (either by hitting a hot-key or explicitly running the macro)

Or when the warrantee period has expired

Just to clarify this a bit which might make thing a bit clearer for you. Labview allocates a fixed number of threads when it starts the environment. As such, you (the programmer) neither create nor destroy threads and labview uses this "pool' to schedule tasks from your program. Again, which tasks are scheduled are up to Labview although you have a small amount of control with the "Execution Subsystem". If you are really worried about the mechanics of threading LV then I would suggest reading Multi-threading In LabVIEW. But for most Labview programmers, it's not a consideration any more than indexing past the end of an array is (you can't ).

I've never had any success with the search either. I use Google to find stuff in here

Try importing this to a diagram. Ooops. REalised you're using 8.x Here's the vi saved to previous

I didn't mean for you to defend the decision (apologies if it came across that way). I as just commenting on the fact that many people use an intermediary DLL which makes it difficult for me to just plop the latest version, pre-compiled library, when there's an update. But I think it's great that you are investigating the x64 since it's prevented me from using the library in the past. LV now comes shipped with zip file support, but it doesn't enable in memory compression which I believe yours does support

I did download and create the zlib from here a while ago (has x32 & x64 object assemblies). Not sure if it will do over 2GB (don't see why it shouldn't). But the issue here is that you use an intermediary DLL lvzip.dll so it's not a simple replace as I assumed originally.l Although I'm not sure why (maybe speed?); I have seen it a lot with labview interfaces to dll's.

Indeed they are different issues .But LV x64 cannot load x32 dll's so even if the 32 bit dll is compiled with u64 pointers; it won't work in LV64 (which I think is why the OP was asking for an x64 dll). Anything that relies on dll's needs to be supplied with both and detect the bitness to work on both platforms (either on install or on the fly). But I did play with the 32bit one when the OP asked, and by replacing all the I32 controls and coercions for u64 (in the write) actually got it to write a 4.3 GB file without complaining (quite surprised, although I can't see how the content would be valid.). The LV file functions are u64 so the coercions were causing it to throw the file error. But then it failed on the finalisation. The result was I could write a 4.3GB invalid file . Since finalisation was a direct call, there wasn't much further I could go without delving into the C source and thought I'd leave it to the expert . Which repository? It's great to hear your looking into x64

Correction of this bug will also have a knock-on effect on SQLite Delete Column.vi and SQLite_Rename Column.vi causing them to fail. In each of these VIs there is a boolean (True) wired to the SQLite_Query-Transaction.vi. This boolean needs to be deleted. The VIS will then work correctly.

Just to clarify the interim fix for this: Locate and open SQLite_Query-Transaction.VI (It is in the "Query" Virtual folder under "Core". Right-click on the case structure (there is only one) Select "Make This Case True" from the popup menu Save the VI It should now work as intended.

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.