LabVIEW
How to get only the string out of a U8 array?
Solved!
@rolfk wrote:
wiebe@CARYA wrote:
There are ups and downs with "Pascal strings". The only downs are when dealing with external code, like most Windows APIs. LV never cared much for interfacing with external code.
Never cared? It has a Call Library Node with a few 100 options which is generally a few 100 options to much for most users! Do those few 100 options cover every possible craziness out there in external code? No of course not, that would require a few 1000 options and that would be a few 1000 options to much for pretty much every user.
I don't see that many configurable options, maybe a few dozen.
And I don't see thousands of other options either, maybe 5 that are actually deal breakers.
It could be there are thousands f options I never run into of course.
Development on this has been very low the past decade(s).
Search LabVIEW like a graph! 
Let me guess, you want a callback pointer. Chances for that is about as likely as LabVIEW going to do rhymes. Not impossible but still not gonna happen.
Such a callback pointer would need a configuration of its own that is just as complicated if not more as the current Call Library Node configuration. There would need to be an additional mapping of parameters to VI connector terminals somehow, everything would be even more brittle if not configured perfectly correct.
Result: A huge amount of work that 99% of LabVIEW users never even could use even if they wanted to.
There are much more urgent things that should have been tackled 15 years ago: Unicode string, long pathnames, TCP IPv6 support!
Not just the callback pointers.
I can do those in LabVIEW. I can even make a LV dll once, that calls VI in development\RT space dynamically (iff the CP is known). Which makes me think it's not that hard for NI to make it easier then it is.
Life time management would be nice. If the creating top level VI stops running, give us something to allow a clean up. I can actually do this too, but it's hard and NI could make it easier.
I know name mangling isn't standard, but most tools seem to be able deal with it.
Some way to handle exception handling would be nice. .NET seems to handle at least some C\C++ exception handling natively. But calling PE dlls from .NET in LabVIEW has bugs that make LV crash, so a wrapper isn't an option.
It's not just that they won't develop (maybe arguably) usable features, it doesn't help that the features they did add (like the Callbacks that are there) aren't that useful.
Those "Callbacks" are exactly meant to do lifetime management. Trivial, not of course not, but that is life time management on C level never.
Exceptions in .Net are well defined but not so in C. You have C++ structured exception handling that varies by compiler because some nitwit thought it was a good idea to patent it, Then there is Windows Exception handling, which does its own thing and even can be used from C, but it's obscure, badly documented and doesn't play nicely with C++ exception handling. So as long as you stay in .Net managed everything is quite easy peasy but that is not an option for LabVIEW and might not even be an option in LabVIEW NXG depending on which level you try to interface (definitely not in the Call Library Node or whatever that thing was called in NXG).
Hi Wiebe
Sorry to correct you but Pascal strings also have the length available nect to the string itself.
https://beza1e1.tuxen.de/strings.html for a more formal explanation.
So just like LabVIEW
@Albert.Geven wrote:
Hi Wiebe
Sorry to correct you but Pascal strings also have the length available nect to the string itself.
https://beza1e1.tuxen.de/strings.html for a more formal explanation.
So just like LabVIEW
That's not a correction of what I said, but a confirmation:
wiebe@CARYA wrote:
@GerdW wrote:As I wrote before: LabVIEW stores the string length separated from the string data!
Like Pascal, IIRC.
@rolfk wrote:
Those "Callbacks" are exactly meant to do lifetime management. Trivial, not of course not, but that is life time management on C level never.
I know. But they are useless unless you have control over the dll.
If you get a 3rd party dll and want to add lifetime management the construction can't be used.
If you could specify the dll there, you could make a LV dll to do the clean up. Not sure why it can't be a VI, but at least you have options.
@rolfk wrote:Exceptions in .Net are well defined but not so in C.
My point was that .NET seems to automatically catch C++ DLL exceptions. Maybe just standard ones though.
The OpenCV c++ dll throws exceptions. The .NET wrapper (OpenCVSharp?) catches them automatically and passes them as a .NET exception.
Seems to me LV could make an effort to do the same.
Believe me, C/C++ Exceptions is a mess. C doesn't actually have an exception mechanism itself. The Win32 API does have but it is not the same as the Visual C++ exceptions and those are not the same than GCC exceptions. Likely C Sharp can catch Visual C++ exceptions somehow, it's in so far from the same vendor, not sure about Win32 exceptions although it would be brain damaged not to allow that.
Maybe much of the problematic has been solved by time now, since there are only really two compilers that still matter, Microsoft C on Windows and GCC on everything else, but not so much on Windows. A few years ago it was an exercise in frustration.
@rolfk wrote:
Believe me, C/C++ Exceptions is a mess. C doesn't actually have an exception mechanism itself. The Win32 API does have but it is not the same as the Visual C++ exceptions and those are not the same than GCC exceptions. Likely C Sharp can catch Visual C++ exceptions somehow, it's in so far from the same vendor, not sure about Win32 exceptions although it would be brain damaged not to allow that.
Maybe much of the problematic has been solved by time now, since there are only really two compilers that still matter, Microsoft C on Windows and GCC on everything else, but not so much on Windows. A few years ago it was an exercise in frustration.
I do belief you...
I haven't looked into how or how well .NET does this. I think in the case of OpenCV, it's a GCC (or LLVM?) dll called by .NET.
I also occasionally miss a way to call a function by string name.
Esp. those annoying physics libs (LibHuAir and Refprop) have 200 functions, each function has 1, 2 or 3 doubles as input. Having to duplicate them in a case is just silly.
Alternatively, a call by pointer would do (as it's easy to get pointers by name).
