C++ dynamic library problem with Numerical Recipes (ADVANCED!!)

[dgholstein]

---

@rolfk wrote:

I do sometimes use datalog refnums to pass around my private data handles. Dropping in an enum with a single enum value specific to your handle type will basically refuse to allow anyone to wire something else to that connection pane parameter than my own private handle type.

---

Rolfk;

What you describe sounds like something I want!  Since I am defining more than one refnum (one for database connection and one for spline fits), it would be really cool to see a broken wire when trying to connect the wrong refnum to a subVI.  Can you show me a screen shot of how to do that?  (unless you do that with LV <= 7.1, I wouldn't be able to read your VI)

   ...Dan

[rolfk]

---

@dgholstein wrote:

What you describe sounds like something I want!  Since I am defining more than one refnum (one for database connection and one for spline fits), it would be really cool to see a broken wire when trying to connect the wrong refnum to a subVI.  Can you show me a screen shot of how to do that?  (unless you do that with LV <= 7.1, I wouldn't be able to read your VI)

   ...Dan

---

Well here it is! Basically you simply take a datalog refnum and drop in an enum with a single value describing somehow your connection. For my database library I simply used the letters ODBC (very original I know) for a connection refnum and STMT for statement refnums.

I also resize it and pasted a little icon over it in the control editor so that the refnum is a bit more visually distinctive. If you wire a refnum directly to an adapt to type Call Library Node parameter, LabVIEW will pass the reference to that refnum value (a 32bit integer) to the DLL function.

Rolf Kalbermatter

[dgholstein]

---

@rolfk wrote:

take a datalog refnum and drop in an enum

---

Rolf;

I'm getting closer, I've started wiring in the "Not a refnum constant" and it looks better already.  I still don't see/understand "drop in an enum", is this in a custom control?  When I add an enum to a custom control panel with a "Not a refnum constant", it breaks -- if I make it a cluster, the wire will not be correct.

BTW:  Check out my sql_LV on Source Forge, it looks like we're doing similar things.  I do use OpenG toolkit to wire in my data as field-named clusters.

Thanks,

   ...Dan

[rolfk]

---

@dgholstein wrote:

---

@rolfk wrote:

take a datalog refnum and drop in an enum

---

Rolf;

I'm getting closer, I've started wiring in the "Not a refnum constant" and it looks better already.  I still don't see/understand "drop in an enum", is this in a custom control?  When I add an enum to a custom control panel with a "Not a refnum constant", it breaks -- if I make it a cluster, the wire will not be correct.

BTW:  Check out my sql_LV on Source Forge, it looks like we're doing similar things.  I do use OpenG toolkit to wire in my data as field-named clusters.

Thanks,

   ...Dan

---

You did get a datalog refnum, did you? It is similar to a datafile refnum but is really an empty shell that requires you to define some datatype. It is meant to be used for datalog file access a file format where LabVIEW does the flattening of more or less complex data structures for you.

But we are not using it for this but "abuse" it to create our own private refnum. Basically when passed to the Call Library Node it is just a pointer to an uInt32 and what you put in that is up to you. Of course don't try to wire this refnum to any file IO functions 🙂

I'm aware of lv_sql. This tool however has been started back in 1996 when I needed to interface to a customer specific database and the then called SQL Toolkit could not connect to their database driver. While it was crude in the beginning it has been refined to great lengths in several updates in the meantime and I do use it for all my database projects. All the datatype handling for retrieval and to a much smaller part on storing is however done inside the shared library code. All the C code is only tested on Windows but done in a way that it could fairly easily be recompiled for other LabVIEW plattforms, anyone saying ODBC Access for Linux?
No OpenG Variant Toolkit or LabVIEW Variants used, since everyting is done inside te shared library but if NI would have documented the C API for the Variants, I would have added that too.

While I have been thinking about opening that up to other people I haven't done so yet for several reasons.

Success with your project and lv_sql!

Rolf Kalbermatter

Message Edited by rolfk on 06-18-2008 05:09 PM

[MathGuy]

I would actually consider this a somewhat poor design approach on NR's part. The reference to the raw input data is hidden by two structures (first the NRVector<> and then the Spline2D_interp) making it difficult to track ownership. I would hope that they offer a non-reference constructor where this data is copied internally so it can be freed by the parent's destructor. Of course, that's just my opinion based on my experience in designing and using these types of math algos.

Based on the current thread contents, I think you know that caching LV handles (or their pointer contents) is not recommended. If this still seems unclear as to why, I'll take a stab at explaining it briefly here. If you do know, then you don't bother reading more.

Even though array data on the diagram is represented by handles (for efficient internal management of the data), LV treats arrays by value and passes them to DLLs accordingly. This means that if the wire representing that array is split and run into two different functions where one changes the data, LV makes a copy so that each function gets what they expect - the original array data.

When configuring the Call Library Node (CLN), you can pass an array so that LV believes the DLL will not change it. One such configuration is to set the input array parameter to const. LV uses this configuration to know if passing the array to the CLN requires protection (aka a copy if run in parallel w/ another function/VI). However, this does not guarantee that between DLL calls, your handle will contain the same pointer. LabVIEW is free to move the array's data to another location if it needs to. There are some exceptions to this, but this is the main reason why caching the handle or handle's contents is not recommended.

[dgholstein]

---

@rolfk wrote:

I'm aware of lv_sql. This tool however has been started back in 1996 when I needed to interface to a customer specific database and the then called SQL Toolkit could not connect to their database driver. While it was crude in the beginning it has been refined to great lengths in several updates in the meantime and I do use it for all my database projects. All the datatype handling for retrieval and to a much smaller part on storing is however done inside the shared library code. All the C code is only tested on Windows but done in a way that it could fairly easily be recompiled for other LabVIEW plattforms, anyone saying ODBC Access for Linux?
No OpenG Variant Toolkit or LabVIEW Variants used, since everyting is done inside te shared library but if NI would have documented the C API for the Variants, I would have added that too.

While I have been thinking about opening that up to other people I haven't done so yet for several reasons.

Message Edited by rolfk on 06-18-2008 05:09 PM

---

Rolf;

Sorry, I should have said "sql-LV" on SourceForge.  I have done exactly that (from scratch)!  I use the OpenG Variant toolkit and link to UnixODBC or MS ODBC.

Yes, I say, "ODBC Access for Linux!!".   Take a look, it makes LabView "The Best Language" for handling databases.  I'd send a link but don't know that it's appropriate in this nice forum.

   ...Dan

[dgholstein]

---

@MathGuy wrote:
I would actually consider this a somewhat poor design approach on NR's part. The reference to the raw input data is hidden by two structures (first the NRVector<> and then the Spline2D_interp) making it difficult to track ownership. I would hope that they offer a non-reference constructor where this data is copied internally so it can be freed by the parent's destructor. Of course, that's just my opinion based on my experience in designing and using these types of math algos.

---

For our particular problems in working with LabView, you are correct; as well, for program readibility and programming ease.

I do believe NR was written mostly to be used in C++ programs though, for numerically very intensive work involving very large grids and long execution times.  With the emphasis on macros and inlines, programs written to use NR code will be much faster -- there won't be the overhead of function calls (which is often significant).  Please look at the routines again in that light.

As far as trade-offs between program readibility, programming ease and performance -- that's the choice we all make here.  It's actually symptomatic of this thread -- I'm using LabView for the user interface and core functions, and employing NR C++ for it's power and speed.

---

Based on the current thread contents, I think you know that caching LV handles (or their pointer contents) is not recommended.

---

I think that's an understatement, I found "caching LV handles" to be no less than impossible -- but an easy trap to fall into.

   ...Dan

[dgholstein]

---

You did get a datalog refnum, did you? It is similar to a datafile refnum but is really an empty shell that requires you to define some datatype. It is meant to be used for datalog file access a file format where LabVIEW does the flattening of more or less complex data structures for you.

---

Rolf;

You learned me a lot there!  Thanks.

   ...Dan

[rolfk]

---

@dgholstein wrote:

---

Based on the current thread contents, I think you know that caching LV handles (or their pointer contents) is not recommended.

---

I think that's an understatement, I found "caching LV handles" to be no less than impossible -- but an easy trap to fall into.

   ...Dan

---

Actually it's not impossible. But you need to take care that LabVIEW does not use them itself after you return from the external function. I explained how that can be done but it is involved and you need to be careful about it. And of course once you take ownership of such a handle you also have to dispose it yourself.

Rolf Kalbermatter