How can i get the pointer location of a control value?

[Samuel_James]

Hi Friends

I just want to know the pointer location where the control value is stored. For example I'm having a string control in a vi with the value "HELLO" i want to know in which memory location the value "HELLO" is located.

My requirement is to pass a pointer loaction of a string to a dll. Don't worry about which dll i'm calling I have to use this in many places.

It may done by writing a c code and called by "code interface node". I'm not familier with this.

If anybody tried this please help me at the earliest. Waiting for your esteemed response..

Thanks & Regards

Samuel J 

[smercurio_fc]

You cannot fiddle with LabVIEW memory in that way. What do you intend to do with the string? Have you looked at the shipping examples on passing strings to a DLL? Open the Example Finder and search for "dll".

[F._Schubert]

This should not be too complicated, because of the following:

* There are no pointers at all in LabVIEW. This is really wonderful! So Strings are, well just strings.

* In the C or Pascal world String are allways pointers. They just differ in there construction, C Pointers are terminated with ascii 0x00.

So, when you pass a string to a dll via call library node, you just have the choice between C and Pascal type of string pointers. (and allso the parameter order stdcall or C).

But: if the dll now performs operations on that string (so passing the string as a variable), it will be much more tricky to get it back to LV (LV is making a copy of the data, and the pointer to that data is given to the dll). If you need this, please give more details...

Felix

[Ujjval Shah]

There is a toolkit called Desktop Trace Execution Toolkit which shows all the memory allocations done by LabVIEW during runtime. Using that you see at what memory location the control was stored and how many bytes were allocated to it.

Hope this helps.

Regards,

Ujjval Shah

[smercurio_fc]

While that may provide you the information, I'll say it again: you should not fiddle with LabVIEW memory as if it were C. It doesn't work the same way, and if you're lucky the only thing that will happen is that the program will crash.

[Samuel_James]

I don't want to pass the string value to the dll. That dll excepts the pointer location of string value the input is unsigned 32bit integer and not a string.

hope you got my point. 

Regards

Sam 

[Norbert_B]

Sam,

smercurio already pointed to the examples shipped with LabVIEW. Please take a look into them as well as the documentation available for the Call Library Function Node (CLFN).

There are also several online documentation available such as this, this and this. 

hope this helps,

Norbert 

[F._Schubert]

Just try to write the string, although the dll is telling you something about the pointers. LV should take care about it.

Warning: Save your work before as LV might crash.

When interfacing dll's with pointers I normally try around with 'wrong' parameters until it works.

Felix 

[smercurio_fc]

---

samuel James wrote:

I don't want to pass the string value to the dll. That dll excepts the pointer location of string value the input is unsigned 32bit integer and not a string.

hope you got my point.

---

I got your point - I don't think you're getting mine. What is the function doing with the string pointer it expects? Is it doing something simple like capitaling words or reversing the string? These operations would be OK. However, if it's doing something like appending characters by allocating new memory, then that's a no-no.

[Ben]

---

samuel James wrote:

I don't want to pass the string value to the dll. That dll excepts the pointer location of string value the input is unsigned 32bit integer and not a string.

hope you got my point. 

Regards

Sam 

---

Hi Sam,

many of the people that have already replied are old-time C programmers and understand you want to pass the address where the string is located so the dll can work in that memory space.

LV does not readily expose that value (I am sooo happy it does not put me through that !).

Please chase down the previously posed links to see how to handle this situation.

Ben

(an Ex-C programmer myslef)