Leaderboard

Name: MemBlock Submitter: vugie Submitted: 26 Nov 2010 File Updated: 03 Jan 2011 Category: General LabVIEW Version: 8.2 License Type: BSD (Most common) Author: Wojciech Golebiowski (w_golebiowski (at) tlen dot pl) Name: MemBlock Type: library LabVIEW version: 8.2 Description MemBlock is easy to use interface for internal LabVIEW memory manager functions (namely AZNewPtr, AZDisposePtr and MoveBlock from LabVIEW.dll). It allows for convenient work with continuous nonreallocatable blocks of memory) - allocating and dealocating blocks and write and read data to and from them. It is usable everywhere you deal with external DLL and you have to provide pointer to some data or read data from received pointer. Typical usage case is dealing with complex C structs containing pointers to arrays or strings. Installation Preferred way to install library is to use VIP package and VI Package Manager. Alternatively library may be used after unpacking it anywhere on disk. However, it is most convenient to copy entire MemBlock directory to the directory \user.lib. After refreshing palletes (or LV restart), in the User Libraries, sub-palette "MemBlock" will appear. Documentation Descriptions of all VIs are available through the LabVIEW context help. Support If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the "MemBlock" support page. Version History 1.0.0: Initial release of the code. License (BSD) Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Click here to download this file

I just uploaded VIP package for 8.2

I thought about this a while back. Labview has no concept of "NULL" string. We can neither create it nor check for it. If we put a string control / constant down, we can only have an empty string (and any of our VIs that accept a string will have a string control). So the choice becomes do we allow a write to a NOT NULL field to always succeed (which is what will happen with your suggestion) or do we define an empty string in LV as being the equivalent to a NULL string. I think the latter is more useful. Good job I cannot take back the rep point eh?