Depricated C API Macro ? NIPrivatePtr() vs PrivateP()

[Umbagoger]

I am looking for the source of a C macro called "PrivateP()", used in the source code for a DLL I am trying to build (LabPython).  I suspect it dates back to LV 7.1, and that it has been replaced by "NIPrivatePtr()".

The project file included with the LabPython source is for VC++ 6. The project file settings implies it was built againt LV 7.1 and Python 2.5.

I am attempting to build the DLL with VC++ 2012 (on Win 7 64b) with LV 2011 32-bit.

I do not have LV 7.1 or VC 6.

I can not find 'PrivateP()' in 'LV 2011.../cintools'.

I can not find it defined by Python 2.5.

I found 'NIPrivatePtr()' macro in 'LV 2011.../cintools/fundtypes.h'.  Based on contect, is seems like an appropriate macro()

I have substituted NIPrivatePtr() for PrivateP(). (source code snippet below), and the project compiles and links successfully.

Can anyone confirm that 'PrivateP' was a LabVIEW C API macro?

If so, is 'NIPrivateP()' the replacement?

And, best of all, what was the definition of 'PrivateP()'?

Thanks,

Peter

P.S. Apologies in advance if this is not technically a Measurement Studio quesiton, but there is no 'C API' forum, this is not a .NET question, and main LV forum seemed light on C API questions.

// The following macro ( "PrivateP()" ) can not be found when compiling in VC 2012 (on Win 7 64b) against LV 2011 and Python 2.5.
//PrivateP(lvsnInstance);

// This macro is in 'LV 2011.../cintolls/fundtypes.h'
#define NIPrivatePtr(x) typedef struct x ## _t { void *p; } *x

// This compiles and links just fine
NIPrivatePtr(lvsnInstance);

[KeaneSenses]

The last reply on this forum seems to discuss this a bit:

https://lavag.org/topic/16863-problem-with-labpython-and-numpy/

[Umbagogger]

Thanks Michael.

1. Good to know my guessing skills are still sharp.

2. Small world. Read this LAVA thread a month ago due to LabPython/Numpy content. How could I have missed this?

3. My bad. Before posting, I googled 'PrivateP()'. Nothing. I did not try 'PrivateP(lvsnInstance)', which had just one hit - this LAVA thread.  Is LabPython the only surviving project to use this macro?

Thanks again,

Peter

[KeaneSenses]

Hey Peter,

To be honest I hadn't even heard of LabPython before coming across your post!  It looks like it was developed by community member rolfk many years back based on this other forum:

http://forums.ni.com/t5/LabVIEW/Trouble-with-LabPython-Setting-up-the-Python-Server/td-p/1444082

[rolfk]

It's actually even older than that. It was created around LabVIEW 6 times with Python 2.3 originally.

The reason those macros changed is because NI has to make its LabVIEW source code adapt to an ever increasing number of system APIs that claim more and more definitions that were once save to use and you can't have conflicting defines in any of the system platform headers and your own headers without getting into C preprocessor hell.

The assumption about how this macro has evolved is right but I haven't confirmed that a lvsnInstance is really a pointer and if it is it will fail catastrophally on 64 bit LabVIEW in the VI API where this is "casted" into a LabVIEW refnum which is always a 32 bit numeric value.