[CR] MemBlock

[vugie]

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

[SuperS_5]

I had a situation where I needed something like this, however, I found a good G code solution. I had a dll call that would spawn a new thread, and return immediately. The spawned process would continuously put data into an array that was provided to the dll by LV. The problem was that LV would de-allocate/reallocate the array memory space after the subVI calling the dll completed. This of course causes memory corruption problems. The solution was to use an uninitialized shifter for the array, prefilled to the desired array size. This allows the memory space to remain open, and no corruption errors.

[vugie]

I just uploaded VIP package for 8.2

[vugie]

I had a situation where I needed something like this, however, I found a good G code solution. I had a dll call that would spawn a new thread, and return immediately. The spawned process would continuously put data into an array that was provided to the dll by LV. The problem was that LV would de-allocate/reallocate the array memory space after the subVI calling the dll completed. This of course causes memory corruption problems. The solution was to use an uninitialized shifter for the array, prefilled to the desired array size. This allows the memory space to remain open, and no corruption errors.

To make things clear - These functions ARE pure G code. Although they use Call External Function Node, as library path they use "LabVIEW" keyword - so they should work regardless of operating system. Of course there is question of "pureness" definition...

[Mark Balla]

Certified 1-2-2011 Placed in General Category