Leaderboard

Do you want the crappy solution that works? Attached is a VI that will compress a folder into a zip file an it preserves characters like the one you posted in your post. It uses 7-Zip (woot!). It's just a command line call to add an archive. 7-Zip also provides a DLL but this was the quickest way to give you a solution. I embedded the 7zip EXE in the VI (a little shady I know) just so it is self contained. At one point I thought about wrapping all of the 7-zip commands into LabVIEW VIs but how do I need the added functionality that the LabVIEW native solution or the OpenG solution doesn't have. 7-Zip Zip Folder.vi

Just to give an update on this: We are in contact with NI, the standard cables are not halogen free, there are several costumers interested in halogen free cables, NI is exploring the possibility of manufacturing those provided the quantities requested are large enough. We are still exploring here, we have already spent several k Euros on cables, replacing them with other cables will mean in the end ~15 k Euros for cables ... this is definitly too much. Cheers, flintstone

Apologies for the late response. I've been neck deep in real life stuff (like keeping customers happy so I can pay the bills) and haven't been on LAVA much the past several months. Interrupts don't exist in labview, or as near as I can tell, in any data flow language. However, modern event driven user interfaces require some sort of mechanism for interrupting a process the user wants to cancel. All solutions essentially boil down to the same thing... Basic Sequence Loop 1. Execute a functional step. 2. If user requested interrupt, exit. 3. Else, goto 1. The one exception is Shaun's method, which pretty much just executes (in the criminal justice sense, not the computer science sense) the running vi when it's no longer needed. Depending on what your process is doing, that may not be a safe thing to do. Also, assuming you only need one instance of the process, dynamic launching and using VI server (Control Value:Set) to interrupt execution doesn't buy you anything over just setting up a parallel loop in the original vi. It's still using an execute-check loop. All you're doing is add complexity and latency. There are lots of way you can implement the basic sequence loop. If you look you can see the example you linked to on the other thread and ned's example are just different implementations of the basic sequence loop. The details are different but conceptually they are the same. In general, the process I use for interruptable sequences plays out something like this: 1. User clicks button to execute sequence ABCD. 2. Controller receives message from UI to start sequence ABCD. 3. Controller sends "Do A" message to execution loop. 4. Execution engine does step A and sends "A complete" message to controller. 5. Controller sends "Do B" message to execution loop. 6. Execution engine does step B and sends "B complete" message to controller. 7. Controller sends "Do C" message to execution loop. 8. Execution loop starts doing step C. 9. Controller receives "User Interrupted" message from UI. 10. Execution loop finishes and sends "C complete" message to controller. 11. Controller, understanding that the user interrupt takes precendence over the remainder of the sequence, doesn't send the "Do D" message, effectively interrupting the sequence. The responsiveness of the application to the user's interrupt is directly related to how fine-grained each functional step is. If you have a functional step that takes 5 seconds to execute, then the use might have to wait 5 seconds after hitting the cancel button before control is returned to him. Usually I have several levels of abstraction between the UI and the steps that are executed. That allows me to keep the high level code coarsely grained without imposing extended waits on cancel operations. [Edit] BTW, I don't *think* I've said I wouldn't ever use a QSM... at least not since '08 or whenever I first started ranting about QSMs. The QSM design is exceptionally good at one thing in particular: time to implement. If you want to test some sort of functionality while spending as little time on it as possible, the QSM is probably your guy. I just make it very clear to the customer that this is prototype code and it will be thrown away when the prototype is complete. It is not the start of the application and we will not be adding new features to it.

Why not. This will help you access the same object even if you branch the HAL Wire. Also it helps you locking the resource. Memory Wise, I think it could be an advantage, if the Aggregated Object Contains Huge amount of data. By replacing that with a 4byte DVR reference value, the HAL-Wire don't become so heavy. So e.g. if you branch the Hal-wire, or when you go into many SubVIs, those SubVIs has to allocate memory for this Huge amount of data. But should you ever branch a ByValue Wire? If you want to run things in parallel and accessing one object, you have to go with the Actor approach, or...just use ObjectByReference. //Mike

The simple answer is that the 'correct' way to handle this message is indeed with the Application Instance Close? event. I can pump this message directly to a LV executable and it fires the event every time (so far). There is a bit of a goof in your top image, the code for WM_CLOSE is 0x10 or 16, either change the radix of your Case Structure (yes) or change the value. Unless for some reason you have registered and are looking for WM_ENABLE. Is this an intermittent problem? By that I especially mean does it happen to some executables all of the time, all executables some of the time, or some executables some of the time? And how exactly are you triggering the shutdown that fails to kill the process? Perhaps it is not sending the message you expect. Of course while testing I notice several Chrome processes running on my machine with the browser closed so perhaps it is not so uncommon.

I found a hack to remove the time limit to edit your posts, see here

That's a reference to the LVOOP implementation of the Command Pattern in LabVIEW, and its portly codebase. As a codebase grows, two other things grow greater-than-linearly: cognitive overhead required to understand a program, and the liability of a codebase owner. (And length of tea time, waiting for your build. But we like tea time.) "Programs must be written for people to read, and only incidentally for machines to execute." --Abelson & Sussman, SICP, preface to the first edition Another quote (that even Google cannot produce right now) says something about object-oriented and functional programming being roughly orthogonal, and the sweet spot of productivity for your language du jour comes by acknowledging the syntax and constructs of your language. It's just an opinion, but Command Pattern and subclassing every message is a beautiful and pure concept, but too close to the OO extrema to be practical. Syntactically and logistically burdensome. [Crouching, waiting for tomatoes to be thrown]