Mark Smith

The only time I've had to worry about thread exhaustion is when making interop calls to .NET/DLL/COM. LabVIEW will grab a thread for the interop call and not release it until the call returns. If you make simultaneous calls to DLLs (assuming they are thread-safe and not called in the UI thread), LabVIEW will allocate a thread and not return that thread until the DLL call is complete. This can lead to thread starvation and blocking if the DLL call takes a non-trivial amount of time to complete and you reach the thread limit for a given execution system. DAQmx is susceptible because it's all calls to the DAQmx DLL under the hood. Mark

As Rolf said in the referenced post, the GAC is the only sure bet for a .NET DLL (assembly). I presume the MySQL assemblies are signed and can be installed in the GAC. If MySQL won't install to the GAC automatically (I suspect it will) you'll need to include an installer that will install a .NET DLL to the GAC because the LabVIEW installer won't. The installer can be built from Visual Studio -most any version. Mark

I wrote some code years ago using the System.DirectoryServices to query the MS ActiveDirectory. I think querying LDAP might be similar, That code is in the LAVA code repository at http://lavag.org/files/file/49-activedirectorytools/ if you want to take a look. Mark

The Desktop Execution Trace toolkit (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209044 ) will help you find memory leaks in LabVIEW. It can show all the memory allocation and deallocation that LabVIEW does. If it's not LabVIEW leaking memory (if it is the .NET DLL) then maybe the Process Explorer (http://technet.microsoft.com/en-US/sysinternals) can help. Or maybe one of the other SysInternals tools - it's been a while since I needed them and my memory may not be accurate. At any rate, that toolset can be very valuable to a Windows platform developer. Mark

We've had reasonable luck using hard to call from LabVIEW COM implementations by wrapping them in .NET and then calling the .NET DLL/Assembly. It's pretty quick to create the .NET wrapper and try it and it may just work. See this link for details http://msdn.microsoft.com/en-us/library/ms404285.aspx Mark

OK - I see what you see and concur - it shouldn't get closed before the loop exits. I'll blame it on old age and bad eyesight

Rolf, On the attached picture, the ref wire from the _SmaoMain property node used to get the ref to the SmaoMain.Info property goes around the While loop where the Enabled Devices get queried and into a Close Ref. There's no data dependency I see that would keep the Close from operating on the Initialized _SmaoMain object before the property of that object gets queried. If the object that contains the property data gets closed, wouldn't the data associated with that property likely get disposed as well? Am I missing something obvious? Mark

Looks to me like you close the ref to SMAOMain in parallel with the loop you use to try collect the Enabled Drivers info. Once you close that ref, your SMAOMain object gets cleaned up and you're likely looping on a closed ref to the SMAOMain.info property when you try to get the enabled drivers. Mark

If all you need is a sine wave (or other standard functions), a fairly inexpensive alternative is to use a function generator instead of a analog out device capable of arbitrary wave forms. Maybe something like this http://www.amazon.com/Velleman-PCGU1000-2MHz-FUNCTION-GENERATOR/dp/B0011E5RNO/ref=sr_1_1?s=hi&ie=UTF8&qid=1381783997&sr=1-1&keywords=pcgu1000 $165 on Amazon

It may be obvious and you already are doing it, but make sure you are releasing those queue refs you obtain by name or you can create a small but sometimes consequential memory leak. It's bitten me in the past. Mark

The problem is that you can't instantiate an abstract or interface class. The ICollection interface requires you to create a class that implements the ICollection interface. See http://msdn.microsoft.com/en-us/library/ms173156(v=vs.90).aspx For more explanation. I don't have Visual Studio handy or I'd write a brief example. Let me know if you need the example and I'll get to it. Mark

Would you like to also " ... create gigaoptimal code in nanotime to make megabucks."? Check out http://mooregoodideas.com/mgi-efficiency-toolkit/ for some ideas - not necessarily good ones...

I followed this topic with interest but didn't have anything to add until today. I was looking for some C#/.NET code to support a project and found a nice library in the Code Project. Since this thread had got me worried about using third-party code and licensing, I took a look at the license under which it was released. After reading this license, I think it's a pretty good model and easy to understand. I can use the library as is or derive from it with the restrictions that I don't remove the original author's attribution, I don't try to pass this work off as my own, and I include a link (somewhere) to the license agreement. http://www.codeproject.com/info/cpol10.aspx Mark

I can't imagine why one couldn't call a static method from a .NET assembly from any .NET language. I'm wondering from the questions you ask if the wrapper dll your customers write is a COM wrapper, since no, you can't just register a .NET assembly as a COM object and have it show up through an ActiveX type interface. So maybe they want to call the .NET DLL from an unmanaged context (C++ maybe?). You can, it appears, make your .NET DLL COM Visible (see "Exposing .NET Framework Objects to COM", http://msdn.microsoft.com/en-us/library/zsfww439.aspx), but not directly from LabVIEW as far as I can tell. You would have to do the work explained in the link above using Visual Studio or such. Alternately, you can build a LabVIEW exe as an ActiveX server and that will show up as a registered COM component, but that's a whole 'nuther can of worms. It works, but it ain't pretty.

When I tried the event registration refnums, they were private data in one of my classes so they needed accessor VI's to be of use to any VI that wasn't a class member. That means that I had no choice except to share the event registration refnum, which turned out to be a bad idea for my use case since it doesn't really allow multiple subscribers. If I just expose the event refs,then its easy for any VI that wants to consume the event to subscribe. I don't find it ever necessary to preload event queues since I don't use the events for any kind of input control - they are only used to publish data to subscribers. More importantly, how do you accomodate multiple subscribers?