Difference between AZ and DS?

[nmalik]

I have been writing a DLL for a while now and hadn't put much thought into it, but what is the difference between the AZ and DS prefixes on some methods? Here are my few assumptions on what they mean.. hopefully someone can expand/correct these statements.

"Application Zone" would be AZ, I think, which implies that the methods manipulate memory that is available in the application (the DLL I am writing in my case).

I have no idea about DS, but it's what I have been using, exclusivly. I just wanted to make it clear in my mind what it is and if it is truely what I should be using.

Thanks for you help.

Naveen.

[Greg_McKaskle2]

> I have been writing a DLL for a while now and hadn't put much thought
> into it, but what is the difference between the AZ and DS prefixes on
> some methods? Here are my few assumptions on what they mean..
> hopefully someone can expand/correct these statements.
>
> "Application Zone" would be AZ, I think, which implies that the
> methods manipulate memory that is available in the application (the
> DLL I am writing in my case).
>
> I have no idea about DS, but it's what I have been using, exclusivly.
> I just wanted to make it clear in my mind what it is and if it is
> truely what I should be using.

>


DS stands for Data Space. Almost all of the data that a VI allocates
and resizes during execution is DS.

Greg McKaskle

[nmalik]

Does this mean that I should use DS methods for data that will be passed from the DLL to LabVIEW? I have been having problems recently after upgrading to LV 6.1. Any time I execute a VI that gets data from the DLL it will crash LV when I exit LV. This isn't a huge problem, since it only happens when you're trying to close LV anyway (or any built executable) but I would like to know why. I am concerned that I am not using the correct methods and that LV is attempting to dealloc some memory that is not longer allocated for some reason.

Thanks
Naveen.

[Greg_McKaskle2]

> Does this mean that I should use DS methods for data that will be
> passed from the DLL to LabVIEW? I have been having problems recently
> after upgrading to LV 6.1. Any time I execute a VI that gets data
> from the DLL it will crash LV when I exit LV. This isn't a huge
> problem, since it only happens when you're trying to close LV anyway
> (or any built executable) but I would like to know why. I am
> concerned that I am not using the correct methods and that LV is
> attempting to dealloc some memory that is not longer allocated for
> some reason.
>


In general, yes. The best thing to do is to use the SetCINArraySize
function for arrays as it will take care of this for you. If using the
lower level functions, everything that LV al
locates is a DS handle
expect possibly paths, which at least at one time were AZ. If you
allocate something on your own, then you can use either one as long as
you use it consistently.


Using the wrong function shouldn't lead to corruptions, but to MgErr's
being returned fromt the call you are making. If LV crashes when
unloading your VIs, then more likely, it is because of a corruption to
an element in the VI's dataspace. Check to see that your handles are
sized to match the data written into them, and make sure to set the
string or array sizes into the handle as well. Also make sure that you
are dereferencing the array or string the correct number of times before
writing into it or you will write in the wrong location and corrupt things.

Greg McKaskle

[nmalik]

I gave up trying to use SetCINArraySize a while ago and I can't remember exactly why now. There are 4 methods I use now: DSNewHandle, DSNewPtr, DSDisposeHandle, and DSDisposePtr. They have worked well throughout development in 6.0, but when I moved to 6.1 I started getting those crashes. I have narrowed it down to one specific data structure but haven't been able figure out why it doesn't work and other more complex structures do. It is a cluster with an int32 followed by three strings. It works fine, but if that structure is passed back from the DLL any time during execution LV crashes when it is attempting to exit. If you have any more ideas I would appriciate the help.

Naveen.

[Greg_McKaskle2]

> I gave up trying to use SetCINArraySize a while ago and I can't
> remember exactly why now. There are 4 methods I use now:
> DSNewHandle, DSNewPtr, DSDisposeHandle, and DSDisposePtr. They have
> worked well throughout development in 6.0, but when I moved to 6.1 I
> started getting those crashes. I have narrowed it down to one
> specific data structure but haven't been able figure out why it
> doesn't work and other more complex structures do. It is a cluster
> with an int32 followed by three strings. It works fine, but if that
> structure is passed back from the DLL any time during execution LV
> crashes when it is attempting to exit. If you have any more ideas I
> would appriciate the help.
>


If you are used to usi
ng the lower level functions, then you don't have
to stop, SetCINArraySize is just a little more safe.

A cluster with an int32 and three strings should come in as a pointer to
a struct followed by three handles to strings. You will need to use
DSSetHandleSize on the string handles anytime you change their size.
Not seeing your code, I would recommend that you make a struct of int32,
LStrHandle, LStrHandle, LStrHandle. Cast the pointer to your cluster as
a pointer to this struct. Now you can access your string handles by
name, resize the handle, copy data into them, and set the string size.
Use the LHStrBuf and LHStrLen, macros if they help you out.

Greg McKaskle