mje Posted August 16, 2011 Report Share Posted August 16, 2011 So the Get LV Class Default Value.vi does a great job, insomuch as it will load from memory when it can, but that still means I need to know the path of the class I want to load. Is there any reason we don't have the capacity to load a class via fully qualified name? This of course would only work for classes already in memory. Seems like it might be useful for factory patterns, among other things. Maybe my classes are scattered across several disk locations and I don't want to worry about keeping track of what comes from where. All I know is I want a MyLib.lvlib:MyClass.lvclass, regardless of where it came from or who brought it into memory. -m Quote Link to comment
Aristos Queue Posted August 16, 2011 Report Share Posted August 16, 2011 > Is there any reason we don't have the capacity to load a class via fully qualified name? It's not an unreasonable request. Just one that hasn't -- to the best of my memory -- been made before. My guess as to why? I suppose that if it is a fixed list plug-in system, users write code to select the object from some sort of list (either build an array or have a case structure with each in a different case). If it is a dynamic list, it needs to go to disk sometimes, so always working by path is reasonable. Quote Link to comment
mje Posted August 16, 2011 Author Report Share Posted August 16, 2011 Yes, there's no use case that wouldn't already be covered by the path based VI, and using a QN would even be more limiting since it would require the class to already be loaded. I was just doing some brainstorming about serializing a plugging based object for transfer across application boundaries. Part of the serialized data will have to be a list of types that are contained in a piece of data. The problem is though we can't use paths- who is to say the paths will be the same from one system to another? Relative paths aren't acceptable either, the objects might not even have a common base path. Let's work on the assumption there's already a mechanism in place to ensure whatever I need will already be in memory. During load I would take some kind of UID and do some cross referencing to determine the path I need to load. The thing is though, LabVIEW has already done all of this work for me. If I use the class' QN as my UID, LabVIEW should be able to resolve it for me. Like I said, with a little extra book keeping, this can already be done if I build some way of cross referencing my QN to a path, but that work has already been done for me by the RTE/IDE. I just hate re-inventing things. 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.