Jump to content

Finding Object type


Recommended Posts

QUOTE (Yair @ Sep 26 2008, 04:49 PM)

It's found in <vi.lib>\utility\lvclass, but I think it was only added in 8.5.

I guess that before that you can implement a dynamic dispatch method to return the path, but you would need to implement it for each class.

Yes it is not available in 8.2. I guess I will have to use Dynamic dispatch method in each of the classes!

Link to comment

QUOTE (test001only @ Sep 26 2008, 06:36 AM)

Yes it is not available in 8.2. I guess I will have to use Dynamic dispatch method in each of the classes!

Using a dynamic dispatch method in every class is the recommended way of handling this, although the recommendation is to create a method that does whatever it is you're trying to do. I'm guessing that you're thinking of a dynamic dispatch method that returns a name or ID of the object so you can say, "Is it equal to this? Ok, then it must be this class..." and then you do Action X if it is that class. If you write a dynamic dispatch method ActionX.vi and then override it appropriately, you'll save yourself on performance and have much easier time for code maintenance in the future.

You can also use the To More Specific node to test if a given object can be downcast to a given type -- this allows for inheritance testing as opposed to the name or ID comparison that only does type equivalence. If the To More Specific node returns an error then it is not of the destination type.

So your options are (in order of preference):

* dynamic dispatch method that does the action

* To More Specific node to do type testing

* dynamic dispatch method that returns name/ID of the class of the object

* Get Path of LV Object.vi (shipped in vi.lib in LV 8.5 but not added to the palettes until LV 8.6)

Link to comment

QUOTE (Aristos Queue @ Sep 26 2008, 02:02 PM)

Using a dynamic dispatch method in every class is the recommended way of handling this, although the recommendation is to create a method that does whatever it is you're trying to do. I'm guessing that you're thinking of a dynamic dispatch method that returns a name or ID of the object so you can say, "Is it equal to this? Ok, then it must be this class..." and then you do Action X if it is that class. If you write a dynamic dispatch method ActionX.vi and then override it appropriately, you'll save yourself on performance and have much easier time for code maintenance in the future.

I have a question regarding a specific use of dynamic dispatch that is related to this discussion:

I want extract only one specific child class (call it XYZ) from an array of parent class, populated with multiple different sibling children classes. Is it possible in some way to use a dynamic dispatch parent method that is overridden by *only* a method of child class XYZ and use that dynamic dispatch strategy in a loop on the parent class array so that I end up with only the child object XYZ?

I can easily envision ending up with an array of parent objects intermixed with my child XYZ object, but I am looking for a way to avoid type-testing altogether.

Any hints/suggestions very appreciated.

-Rick

Link to comment

QUOTE (Rick @ Sep 30 2008, 12:34 PM)

I want extract only one specific child class (call it XYZ) from an array of parent class, populated with multiple different sibling children classes. Is it possible in some way to use a dynamic dispatch parent method that is overridden by *only* a method of child class XYZ and use that dynamic dispatch strategy in a loop on the parent class array so that I end up with only the child object XYZ?

I can easily envision ending up with an array of parent objects intermixed with my child XYZ object, but I am looking for a way to avoid type-testing altogether.

Try this: Write a dyn disp function on the parent class that takes in the object (the dynamic input) and an array of parent, and outputs an array of parent. The parent implementation does nothing. The one child that you're interested in does a Build Array to put the object onto the end of the given array.

Now call that subVI in a loop to build the desired array.

Link to comment

QUOTE (Aristos Queue @ Sep 30 2008, 02:41 PM)

Try this: Write a dyn disp function on the parent class that takes in the object (the dynamic input) and an array of parent, and outputs an array of parent. The parent implementation does nothing. The one child that you're interested in does a Build Array to put the object onto the end of the given array.

Now call that subVI in a loop to build the desired array.

I can see how that will build onto an array of parent, given an instance of child, via dynamic dispatch. But my goal is a bit different.

What I want to do is essentially "find and extract" instance(s) of child XYZ from an array of parent, via dynamic dispatch. I currently have this working via brute force downcast type-testing, but I had hoped to use a more elegant solution.

Link to comment

Stephen already gave you the basic answer - the dynamic dispatch mechanism works by name, so all you need to is create this method only in the parent and in the specific class you want.

In the parent it will do nothing and all other classes will call that implementation. In the child it will do whatever you want (e.g. build an array).

I'm guessing the reason Stephen suggested building an array of parents is that having the link to the child in the parent breaks encapsulation, since the parent should not know about the child. Once you have the array of parents, you can simply cast all of it to an array of children.

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