JanJorgensen

OK. I haven't found a solution yet and I haven't found a way to get information from LabVIEW about the reason for not showing the constructors. Instead I have created a new assembly (.NET dll) with only the classes needed from my LabVIEW code. To be sure I can distribute it along with an LLB-file, I am registering the assembly in the GAC. This is not the desired solution, and maybe I can use the "real" assembly some time in the future, when it can be registered in the GAC. - all its dependencies must also be in the GAC . But with my current solution, it is very easy to use the assembly in LabVIEW, and all changes are immediately available after closing and re-opening LabVIEW. Thanks for the attention.

Yes, I'm sure that makes it harder to understand .NET connectivity for people without any object oriented programming experience.

Thanks alot, Yair. I will walk through the discussion, and see if I find something usefull. It looks very much like the same problems I am having. I'm sure it's not a 'public' problem, because all classes are perfectly usable from my main (.NET) application. /Jan

Thanks, Mark. I will have a look at your code tomorrow. Maybe there's something that triggers. OK tip about ILDASM, but I have been using the assembly from my .NET application for years, so I know the classes have public constructors. /Jan

Thanks, Yair. My assembly is perfectly callable from other environments and other .NET assemblies. But not from LV... What I'm looking for is e.g. a checklist of preconditions I can run through to make it sure it is usable from LV. It would have been easier if LV showed ALL constructors for a class, and made those not usable gray with a tooltip telling why they aren't callable. I checked Bryan Tylers blog, and found nothing on the subject. I have located the VI in the same folder as the dll. The referenced private assemblies are also there. The class I wish to use can be used from other assemblies and my main application. When I build a test-assembly with a simple class, I have no problems using it from LV. It's just as easy as it should be. But LV is not helping me by telling me what's wrong. The OK button of the Select .NET Constructor dialog is even enabled when I select a class with only private constructors! I will be VERY greatfull if anyone can help me on this. It would be really really great if our application could be used with LabVIEW. I have tried so many things and I'm pretty stuck right now.

Hi. I'm using LV8.5. I have developed a quite large application in .NET 2.0, and have also made a separate assembly (dll) which can be used by other applications for interoperating with our application. I can browse the classes and interfaces inside the assembly from LV, but no constructors are shown for any of my classes. I don't get an information from LV, why the constructors are not shown. I have searched around, but haven't found a good description on the preconditions for a .NET assembly to be callable from LV. Any ideas?

QUOTE(Aristos Queue @ May 25 2007, 04:34 AM) I really hope that NI R&D ( :worship: ) is in the fast lane and will come up with a simple solution before that happens. While we're at it: I don't think it is nessecary to have build-in protection and other advanced features. I mean - file RefNums, VI RefNums and all the other don't have that either. If we just had a global hidden panel where controls could be created and closed dynamically then it would be possible to make a simple solution (just a spontaneous idea). I have my faith in NI, they will solve it! /Jan

I would like to use a queue based design, but my "problem" is that I wish to pass the LVOOP object reference to some .NET code (it will only be stored in there and then passed back again to LV code later). I have made my own VI Server in .NET (quite same design as the first versions of the native VI Server). My application is written in C# (VS2005) and it will be using plugins coded in LabVIEW. I would like to make a base class for the plugins in LVOOP. I have checked all the examples in the "Refactoring the ReferenceObject example in LV 8.2" topic and I'm not very pleased with any of them; there's too much work involved. I need a very simple solution that I also think my future customers will appreciate. In one of the examples though there was an idea where the reference is a Control RefNum (which can be casted to an int32) and that could be a usable solution for me - I'm just not so sure about the performance. I think I could end up with 500+ instances of referenced LVOOP objects at a time - and that would therefore mean 500+ instances of the reentrant VI that holds the control with the object data. I have no idea if that's a problem; I have to test it one of these days. Do you know if there's a "best object reference design" anywhere which most labviewers use? Any hints, tips or tricks? /Jan P.S. Thanks for asking, my nordic brother.

F... This was working perfectly until ... The "bug" is now reported. Thanks Tomi. /Jan

QUOTE(Tomi Maila @ May 24 2007, 12:25 PM) I am using LV 8.2.1. Have you tried loading my code? - do you get the same warning? The error can be reproduced this way: Create a class Make a class VI that has the class as input. Create a VI RefNum type def. for that VI. Add the type def. to the class data. Save and close. Load class.

(my first posting !) Hi there, I started using the LVOOP a few weeks ago. Now I'm trying to make a basic ByReference-framework (as many others already have). When I load my class I get the warning: D:\Projects\BaseRef.llb\BaseRef.lvclass\BaseRef.ctl - The class expected to be at "D:\Projects\BaseRef.llb\" was loaded from "D:\Projects\BaseRef.llb\BaseRef.lvclass". The code is working but I get the warning every time I load the code. I'm afraid it has something to do with the private data in the class; I have a VI RefNum for a VI that has the class itself as input parameter (and output). This is my code: http://forums.lavag.org/index.php?act=attach&type=post&id=5934 Any ideas?