JanJorgensen Posted May 25, 2007 Report Share Posted May 25, 2007 (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? Quote Link to comment
Tomi Maila Posted May 25, 2007 Report Share Posted May 25, 2007 Seems as if your project gets corrupted for some reason. Are you using LV 8.2.1? If not update your LabVIEW and retry. Tomi Quote Link to comment
JanJorgensen Posted May 25, 2007 Author Report Share Posted May 25, 2007 QUOTE(Tomi Maila @ May 24 2007, 12:25 PM) Seems as if your project gets corrupted for some reason. Are you using LV 8.2.1? If not update your LabVIEW and retry.Tomi 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. Quote Link to comment
Tomi Maila Posted May 25, 2007 Report Share Posted May 25, 2007 It's a bug in LabVIEW. I guess that your code should not compile as it uses recursive data structure but LabVIEW incorrectly compiles it which leads to errorneous references in binary code. Please report this bug to NI. Tomi Quote Link to comment
JanJorgensen Posted May 25, 2007 Author Report Share Posted May 25, 2007 F... This was working perfectly until ... The "bug" is now reported. Thanks Tomi. /Jan Quote Link to comment
Tomi Maila Posted May 25, 2007 Report Share Posted May 25, 2007 If you want by ref objects, you should use queue based design. They are perform very well. What's the time scale you are going to need a by-reference classes? Tomi Quote Link to comment
JanJorgensen Posted May 25, 2007 Author Report Share Posted May 25, 2007 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. Quote Link to comment
Aristos Queue Posted May 26, 2007 Report Share Posted May 26, 2007 QUOTE(JanJorgensen @ May 24 2007, 02:56 PM) Do you know if there's a "best object reference design" anywhere which most labviewers use? Man, LVClasses have only been available since August! We'll have a "best design" for a lot of things ... in about three years. At the moment there's a scattershot of "things that R&D put together that seem to work well" and "things the early adopters (such as Tomi) have attempted when the R&D stuff failed to meet their needs". What you see in the shipping examples and postings to LAVA is pretty much the extent of things at this point. If you do hit on a really clean implementation, post it --- and in a couple years we may be pointing to your design as the "best" recommedation. Quote Link to comment
JanJorgensen Posted May 26, 2007 Author Report Share Posted May 26, 2007 QUOTE(Aristos Queue @ May 25 2007, 04:34 AM) What you see in the shipping examples and postings to LAVA is pretty much the extent of things at this point. If you do hit on a really clean implementation, post it --- and in a couple years we may be pointing to your design as the "best" recommedation. 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.