SDietrich

The current release includes the following DLLs: libpq.dll (the actual driver) libintl.dll libeay32.dll ssleay32.dll According to Dependency Walker these are the only external dependencies. Everything else is Windows stuff and the Visual C++ runtime, of course. But I think, this might even be bundled with Windows itself, so no problem here.

I don't use Global Variables, because the NSA can read them.

Hi all, one way to avoid rotating the buffer and still be able to use the Array Subset Node is the following: allocate a buffer twice the size the user requested apply writes to buffer also to buffer[usersize + i] use Array Subset Node to return any contiguous part of the buffer very efficiently as a contiguous subarray Another interesting possibilty is to calculate certain figures like average or standard deviation directly when inserting/deleting elements instead of fetching the whole buffer everytime you need that figure. Regards, Sebastian

Hi Barlaw, it is possible in LabVIEW and you do not have to use OO (LabVIEW is not really good at OO). The keyword here is asynchronously calling VIs. It does exactly what you do in your JAVA example: You create a worker class (a LabVIEW VI that does the actual work, e.g. calculations). You start one or more instances of this worker-VI from you main VI (or even from the worker VI itself). I use this technology to let my users choose, how many heavy-duty-threads a program should start: only one if they are actively using their computer or up to 8 if they run the program during their lunch break or a meeting and they don't need the computer. In your JAVA-example, you use the call-and-forget strategy, e.g. the workers do not return anything. In LabVIEW you can also use the call-and-collect strategy. Here every worker returns values that you can receive via the wait-on-asynchronous-call node. This node can be placed anywhere in your program, it does not have to be in the VI that started the worker-VI. Regards, Sebastian

Name: ShapeLib Submitter: SDietrich Submitted: 14 Aug 2014 Category: *Uncertified* LabVIEW Version: 2009 License Type: MIT This is a package containing LabVIEW bindings to the library ShapeLib for working with shapefiles. The DLL as of version 1.3.0 is included in the package. This DLL is compiled with Microsoft Visual Studio 2010 Express, so you need the corresponding runtime. But chances are you already have it because other programs on your computer need it, too. So just give it a try. The library is thread safe, but the objects are not. E.g. you can open two different files in different threads, but you can not operate on the same file from two different threads at the same time. As of the moment the DLL is 32bit only. Click here to download this file

Hi ShaunR, thanks for your feedback. I added the DLL, which was hiding somwhere deep in the System32-directory (actually SysWOW64, as I use a 64bit Windows). Now it is part of the package and is installed right with the VIs to userspace, so there is no need to run VIPM as administrator and the VIs always use the DLL that they were tested with. I also added notes about the thread-safety and the supported versions.

Even simpler: Create a file or modify a file. Your LabVIEW program can check regularly on the 'last modified' timestamp. But as always, you have to know what you are doing. E.g. a FAT32-filesystem has a timestamp resolution of 2 seconds(!). Sending simulated keystrokes is fine until Windows or some other application decides pop up some window. If you are lucky, you just miss an event (or rather all events from there on that is). If you are unlucky, you spend the night reinstalling your system because your script accidentally hit the OK button in a box asking to format your harddisk...

Name: libpq Submitter: SDietrich Submitted: 01 Mar 2014 Category: Database & File IO LabVIEW Version: 2009License Type: Other (included with download) This is a package containing LabVIEW bindings to the client library of the PostgreSQL database server (libpq). The DLL version 9.3.2 and its dependencies are included in the package. This DLLs are taken out of a binary distribution from the Postgres-Website and are thread-safe (e.g. the call to PQisthreadsafe() returns 1). As of the moment the DLLs are 32bit only. The VIs are saved in LabVIEW 2009. So this package works out of the box if you have a 32bit LabVIEW 2009 or higher on any supported Windows operating system. Because this obviously is a derived work from PostgreSQL it is licensed by the PostgreSQL license. A few words regarding the documentation: This package is meant for developers who know how to use the libpq. You have to read and understand the excellent documentation for the library. Nonetheless all VIs contain extracts of that documentation as their help text. What's coming next? - adding support for 64bit - adding support for Linux (anybody out there to volunteer for testing?) - adding support for MAC (anybody out there to volunteer for testing?) Click here to download this file

Hi Darren, I think you used the private application property App.UnattendedMode. This affects the whole application. Would the private VI property DoNotShowSaveChangesDialog do the same thing, but only for the VI in question? E.g. you don't have to remember to set it to FALSE after you closed the VI? See this (password protected) VI (for LV 2010): NoSaveDialog.vi. And of course: Don't let the QA guys catch you using this VI in production code!

Hi, I think you mistake the attributes of a variant for the elements of a cluster. These are two completely different things. As hooovahh pointed out above, you set (or define) the attributes yourself. So you first have to define an attribute, before reading the attribute names and values makes any sense. I believe you are looking for a way to inspect a variant and - if it is a cluster - access its elements. This is most easily done by using the appropriate OpenG functions. Regards, S.

Hi all, I just wanted to let you know the solution to my problem is no blocker anymore as I found a workaround. I can now simulate the environment for GenerateCode and thus find out which wires need to be broken right in AdaptToInputs. This information is then saved into the State and used in GetTerms4. So there is no need to have GenerateCode reply with "UpdateTerms". The key to this simulation is the (private) method "Create Constant" of the "TopLevelDiagram" class. It is used to create constants of the same datatypes as the wires connected to the XNode. It might still be interesting if there are other limitations as to what ability can answer what reply. Regards, Sebastian

Hello my fellow XNode scripters, I recently ran into an issue developing my latest XNode. I want to break certain wires connected to my xnode, based on the results of the "GenerateCode" ability. Basicially I generate the code, check certain wires in that code and if they are broken, I want to break the corresponding wires to my XNode. But LabVIEW keeps ignoring my "UpdateTerms"-reply in the GenerateCode ability. Has anyone else had a similar problem and probably solved it? Interesting fact: the reply "UpdateImageAndBounds" is also ignored, whereas the reply "UpdateImage" is processed correctly... Merry X-mas, Sebastian PS: The XNode I am working on is basically a wrapper around the FormatIntoString() node, that accepts (nested) clusters and simply unbundles them (recursively). See attached screenshot. When this and some other minor issues are solved, I will publish the XNode here @LAVA.

Patch to allow the loading of extensions, e.g. SPATIALite Hi all, my current project demands a lightweight spatial database and so SQLite and SPATIALite came to my mind. Thanks to the excellent work of drjdpowell SQLite integrates smoothly in LabVIEW and with the attachedl VI loading extensions like SPATIALite becomes possible, too. Simply execute it with "on/off = true" and then run a query like SELECT load_extension('lib-spatialite-2.dll')[/CODE] and you have your extension running. So James, please include it in the next release. Thanks! Sebastian Enable Load Extension.vi