Leaderboard

Recently the PDF creating toolkit using ItextSharp by Exaprom has been updated to version 2.0. https://decibel.ni.com/content/docs/DOC-10952 The toolkit is very well put together and I've used it on a couple projects. The example generates the manual for the toolkit, and it is pretty impressive to see all the features of the toolkit demonstrated, by generating the user manual.

Hey all, I've spent a little time here and there working on this and I figured now was the right time to ask for feedback. Typically when making a new UI I'll use something like AMC and have a producer (the event structure) and consumer (a QMH). This is the standard template in AMC (image here) and its also used in, for example, the sample projects. This is ok and has done well for a long time, but there are weak points. (a) the QMH can get clogged. After all you're sending all of your work down there and if something is slow, the consumer will run slow. (b) This pattern seems to always end up with a weird subset of state and functionality shared between the two loops. For example maybe your UI is set up to disable some inputs in state X, except that its your QMH, not your UI loop, which determines that you're in state X. So, maybe you send a message to the QMH, it takes some time and so your user is able to press buttons they shouldn't be able to. You fix this by putting the disable code in your UI loop, but then you need both loops to know that you're in state X. Another example: if you're using some features like right click menus, you need to share state between the UI and the QMH so you can generate the appropriate right click menu. Theres many examples like this. None of them is particularly heartbreaking, but my hope is that this is a better way. At one point a few months ago I was in a conversation with R&D about events and we got onto some of these issues. Aristos and some others pointed out this was basically making two UI threads and suggested pulling everything back into a single loop (just the event handler) but then using async call by ref to take care of all the work that takes more than 200 ms (or whatever you personally consider the cutoff to be). This solves both problems because (a) async call by ref has a pool of VI instances it can use, so the code never blocks and (b) you only have one loop for the UI and associated state information, so there are fewer chances for weird situations. Since the code for doing all that manually is kind of tedious, I put together this prototype library to hopefully make the above design really really easy. Feedback I am looking for: -is this a worthwhile pursuit at all? (ie do you agree with the first couple paragraphs above?) -has this been done before (I searched and searched but I may have missed something) -any thoughts on this first draft at implementation? The code is here and examples are in the project or here. The main example is "example UI get websites" but this example also requires the lovely variant repository. Not for any particular reason, I just like it. There are more details about the code in the readme.

Ooooh, that's a bit sexy-have a like! I think you have just given me have a brain-wave (maybe a brain-fart, difficult to tell at the moment) I've been thinking a bit about the SQLite API for LabVIEW recently because it has been pretty much feature complete for a while now and no-one is requesting any new features and either there are no bugs or no-one is telling me. Your post to that software has given me the embryo of an idea of a possible improvement to the library. It can already export data to CSV and SQL, mainly for archiving purposes, but what about PDF (or HTML for that matter) for report generation?. I think it might be nice to be able to generate reports directly from a DB and squirt them out to, say, PDF. I'll have to have a think on this.Thanks for pointing out that software.

This appears to probably call libtiff and there the function TIFFGetField() for one of the string tags. This would return a pointer to a character string and as such can indeed not be directly configured in the LabVIEW Call Library Node. The libtiff documentation is not clear about if the returned memory should be deallocated explicitedly afterwards or if it is managed by libtiff and properly deallocated when you close the handle. Most likely if it doesn't mention it, the second is true, but definitely something to keep in mind or otherwise you might create deep memory leaks! As to the task of returning the string information in that pointer there are in fact many solutions to the problem. Attached VI snipped shows two of them. "LabVIEW Manager" calls a LabVIEW manager function very much like the ominous MoveBlock() function and has the advantage that it does not require any extra DLL than what is already present in the LabVIEW runtime itself. "Windows API" calls similar Windows API functions instead.