Jump to content

Siblings called from File need Parent Data


Recommended Posts

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?

post-15786-0-81974700-1330543223_thumb.j

Edited by jbjorlie
Link to comment

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...

Link to comment

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 :cool:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.