Call by Reference within Override VI

[thutch79]

I'm trying to make a dynamically dispatched VI that accesses a property in a class by name. (see attached) The idea was to use "call by reference" for the property required to call the correct data member access VI. The CBR does not seem to preserve the dynamic wire from the input to the output causing the VI to be broken. (see second attachment)

Two questions: First, why doesn't this work? I understand that Labview needs to ensure runtime type is preserved through a dynamic dispatch override VI, but why couldn't it just assume and throw an error if type is not preserved? Second, any ideas how to get around this limitation?

[Intaris]

For Type propagation LV neede to KNOW that the VI being called will propagate the wire.  It does checks ont he Sub-VI to do this at compile time.  Whirling in a random VI at Run-Time cannot possible guarantee this so this error is perfectly expected.

Why on earth do you want to cann a Dynamic Dispatch VI by reference?

How to get around the limitation?  Stop calling Class VIs by reference.  Load the object into memory (Checking takes place upon load) and then call it directly.

[thutch79]

I hate posting on this forum. People are so friggin rude. Do people really just sit on this forum all day looking for people's posts they can sh$t on?

If you must know the story of why I'd like to do this, I'm trying to replace a config file system based on ini file with one based on objects. The main motivation is objects storied in binary nicely convert to a new version without any code. Our config files store hundreds (if not over a thousand) settings for our application. We have anice little VI for each variable that handles the read/write of those settings which call them by name. It makes it very easy to drop them in a program where needed. It would be really nice to not have to modify a huge list of VI because of this change.

[Intaris · Accepted solution]

I agree that people can be so rude.  So ungrateful too.  What's the youth of today coming to at all.  I really have no idea.  The future is surely doomed.  Doomed I say!

Now getting back on topic....

Why don't you just implement a class method instead of loading a member VI via Reference?  I simply don't understand the role the "By reference" part plays here.

If you MUST go this way (Which I doubt at the moment) then please outline why calling a DD VI dynamically is a requirement.  In the mean time insert a "Preserve Run-Time Class" primitive ont he output of your dynamic call.

That MIGHT help.

[Intaris]

By the way, do you know that you can LOAD an object at run-time to do all this work for you?  Search for "Factory pattern" on the forum.  What you are trying to do is something I've done in the past and if you want my opinion (Which you probably don't but I'll give it anyway) you're going about it wrong.  If you take time to listen, I'll tell you a far far better way to achieve exactly what you want.

If you can stop yelling expetives at me for amoment.

[thutch79]

I know what a factory pattern is. No, it does not help in this case. I need to access member data by a string. Like I said before, there are hundreds of accessor VIs to choose from. I cannot see how I would get the accessor I need without calling by reference. I need to get the data out of the class. This is not a fully object oriented application. I am trying to utilize a class for the purposes of config files to easily replace an ini file system. If you have a better way for implement config files stored in binary that allows me to easily add config settings without writing a ton of addition code to convert old config files, I'm all ears.

My general problem with your approach is instead of thinking "gee, this person may have had a long thought out reasoning for arriving at this need. Maybe I'll ask him how he got to this" you jump to, "this person is an idiot, why on earth would they do it that way". That seems to be the general approach in this forum.

Despite your rudeness, yes, it does seem that "preserve runtime class" does what I was looking for and I thank you for that.

[Intaris]

You're welcome.

[Intaris]

---

@thutch79 wrote:

I know what a factory pattern is. No, it does not help in this case. I need to access member data by a string. Like I said before, there are hundreds of accessor VIs to choose from. I cannot see how I would get the accessor I need without calling by reference.

---

Well how do you know which accessor to call?  I'm sure this information could be used to do what you want in a "proper" OOP approach.

Shane

[thutch79]

Attached is an example of a config setting VI. This VI would be placed anywhere in the application to quickly dip into the ini file and retrieve the correct setting. I'm trying to replace the subvi in there. This is common to all config settings VIs. I feed it a key for the config setting I need and it spits out the setting stored in the ini file.

In the case of the object, I intend to load all settings objects from files into memory at application startup. My need is a VI that will find the correct object, then obtain the correct setting from the object. Ideally, I'd like to build this all in the same subvi I already use to save me from having to modify the hundreds of config VIs the application has.

[Intaris]

Well, my previous question was how you decide which accessor to call dynamically.  Your VI in the first attachment has some logic code in place already which spits out the path of an object to read in your data.  How do you find this path?  And why can't you use this path to dynamically load the object into memory and simply do a normal VI call on that object..... No need for dynamic calling at all.

Shane.

Ps the clue here is the VI "Get LV Class Default Value" which will load any class you provide a path to into memory allowing you to use it directly (as a parent class).