Call by Reference within Override VI

[thutch79]

Let me see if I'm following this right. I would have the object for the setting class in memory that I need access to, but it's the more generic class. I then use the path to get the correct class and use the default value to move the object to the more specific class that I need. Finally I call the accessor by reference just like I had done, but now I don't need to worry about the dynamic dispatch type. Is this correct?

[Intaris]

Almost, once you load the correct class, you don't need the "to more specific" OR the dynamic call.  Your code simply calls the DD method of the generic class.  The rest is taken care of ny LabVIEW in the background.

The wire in the IDE "looks like" a generic class but at run-time it's really the CORRECT class and the DD method ensures that the CORRECT method is called.

Shane

[thutch79]

I still don't think this gets to where I need to be. I still need to call the accessor I'm looking for. In order to do that, I need to call by reference. I don't see anyother way of calling the accessor for the setting I'm looking for. In order to call by reference, you need a strict type ref on the open. When I wire in the class from the "get lv class default data", broken wire...

If there is another way of calling the accessor I need, I'm not seeing it.

Unless you are suggesting creating a class for each config setting type (string, bool, etc). Then create a class that groups the settings I need.....that could work. Is that my misunderstanding?

[Intaris]

An object type for each config setting type is what you had, or at least that's how I understood it.  Otherwise I don't get the Dynamic Dispatch bit at all.

What it sounds like is that you simply need a selection of static dispatch VIs to choose from.  Do you have a single class with lots of different methods or do you have several classes each with several methods?

I must admit the Dynamic Dispatch element made me think there were many objects for all the different individual options you had.  Seems I was wrong.  Can you tell me why the dynamic dispatch is required at all?

[Intaris]

Instead of getting a dynamic reference to a specific accessor, just tell the object what you're looking for and let it pick the appropriate accessor (Case structure?) for you.  Doesn't need to be a case structure, there are other ways to remain strictly typed without having to go over a VI reference.  I don't quite understand the object composition you're dealing with and I think that's central to the question.

[thutch79]

None of this is really created yet, which is why switching up how I was going about this isn't very painful.

I originally had a different class for each group of settings (effectively replacing the various ini files in the system). Thus the need for call by reference accessors. Today, I've totally been rethinking this. I believe now I can have a class for each setting type (string, dbl, I32, etc). Each of those classes would have read and write accessors for the single value stored there. I would have a settings group class which contains an array of strings to name each variable along with an array of objects that actually have the values in them. Now, when I need a config setting, I search for the name in the array, file the corresponding object, type cast it to the correct type class because I will already know if I'm looking for a string, or dbl or something else.

This breaks one of my requirements, namely to easily update an old config file to the newer version, but the upgrade VI should be simple. I will just store a default settings file somewhere. When the system loads a config file, it will compair it against the default file for missing or extra variables and adjust the object accordingly. All I really wanted to do was keep from having to write an upgrade path for every version of config file possible. This should at least avoid that.

I think I'm on the right path now. If you see any gaping holes in my understanding, let me know. Despite the rocky start, you have been very helpful, and I appreciate that!

[Intaris]

What you just described is how I ended implementing my version of something similar.  I have an object for each individual data field type.  More complex data types were created from aggregating the more basic types.  Large sections of the INI file were again aggregated of these objects and so on.  I would include a version field in each settings group object so that when reading you know what you're dealing with.  This makes knowing what mutations are required much easier to figure out.

I appreciate that you decided to listen to what I was trying to say to you.  I've been down this road before and I was pretty sure that your approach was overcomplicating things.

Let me know how you get on.

Shane