jbjorlie Posted February 29, 2012 Report Share Posted February 29, 2012 (edited) I just posted this on AF site but thought KNOW the LAVA LVOOP group would have some elegant solutions: I have a Child of Actor.lvclass called INSTRUMENT. INSTRUMENT has children VIEW and CONTROL. I launch the desired VIEW from an VI owned by CONTROL and I need to insure this new VIEW object inherits INSTRUMENT's current data. The picture below shows my problem. I choose which VIEW to launch from a path, so it's wire will be of type LVObject until run-time when the correct class is chosen by the file name. I thought of placing a ToMoreSpec Class into the LVObject reference but that will screw up the selection of the Actor Core wont it? There must be a way to do this without making a case structure holding all possible VIEW objects, right? Edited February 29, 2012 by jbjorlie Quote Link to comment
jgcode Posted February 29, 2012 Report Share Posted February 29, 2012 You can't do this. If creating plugins like this the Parent Class is the 'interface' so you should design it to use DD to add new behavior from Child Classes - as opposed to case structures as you mentioned. Is a Control or View an Instrument? I would say no - so maybe you should look at a different type of relationship. For example setting the e.g. view with the instrument data rather than inheriting from it etc... Quote Link to comment
jbjorlie Posted February 29, 2012 Author Report Share Posted February 29, 2012 You can't do this. If creating plugins like this the Parent Class is the 'interface' so you should design it to use DD to add new behavior from Child Classes - as opposed to case structures as you mentioned. I understand, I think. Are you suggesting the DD VI takes the "from file" object as its dynamic input and takes the parent as another input? It would then use the "from file" object to typecast the new child... Is a Control or View an Instrument?I would say no - so maybe you should look at a different type of relationship. For example setting the e.g. view with the instrument data rather than inheriting from it etc... It's not really "Instrument" class, it is Instrument Control class and "Control" is actually Control Mediator. I think it is OK to call View a child of Instrument Control in this case. View is communicating with and launched by Control Mediator. Control Mediator cannot be a parent of View but it does need to retain some View parameters to pass between Views. At times there will be no View open & something needs to retain the information or I will have to go fetch it from all the Models again. I suppose you are right, I can just have the mediator send the necessary information to the View but then I have to store it somewhere. That is why Control Mediator is a sibling with View and child of Instrument Control. Poor naming perhaps but I retain that right as a LabView programmer and not a computer scientist Quote Link to comment
jgcode Posted February 29, 2012 Report Share Posted February 29, 2012 Poor naming perhaps but I retain that right as a LabView programmer and not a computer scientist 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.