@tst wrote:
@mbn123 wrote:
the problem is that I have to exit labview completely before I am allowed to reinitialise my .net controls.
What do you mean by that?
I haven't tested it completely, but it seems that labview (8.2) handles .net exceptions badly sometimes.
I have succeeded in starting and stopping my labview application, without corrupting the .net object. But most of the time, it is unable to load the object (showing a square around an empty control). When I exit labview, it (sometimes) gives me an error arising in DotNetDomain.cpp and, at next startup, offers to investigate the error.
The .net controls are fairly buggy, as they are in active development, and I suspect that they fail in a way that is incompatible with labview. I use exceptions in my .net code, and labview reports it properly, but apparently it is not enough.
In my oppinion, it is a bug in labview 8.2. It may be circumvented by proper .net coding, but it is annoying during development.
@tst wrote:
I never had a problem in calling a constructor of a DLL I used previously. In my experience, the only time you need to exit LV is when you want to replace the DLL, and that's because LV keeps a reference to it.
Can you post a simple example demonstrating your problem with exact explanations?
P.S. I use LV 7.0, where embedded .NET controls were not available, so I don't really know about those if that's what you're using.
The first construction of the .net object of not an issue. The "exit labview" part is annoying, but helps avoid other problems.
I am currently converting vb6 activeX component to vb.net, and once you get a handle on how to handle property and method return values, it works nicely. You have easy access to methods and properties. I have never liked ActiveX components, so I recomment the transition.
