Jump to content

"Really" get the class name at run-time


Recommended Posts

Hi all,

I've searched the Internet and this site, and still didn't find what I was looking for - I guess I'm still a n00b :)

I would really like to get the name of the LV class and do this for all its ancestors.

So it will by a dynamic dispatch method that should return all the class names back to the base class.

Can someone please help me do this?

I've found these two threads:

but they are a bit over my head, to get anything out of them.

Thanks in advance, Mike

Link to comment

I would really like to get the name of the LV class and do this for all its ancestors.

So it will by a dynamic dispatch method that should return all the class names back to the base class.

HI Mike,

take a look at this API. And find attached the latest version* I use.

There is code for getting the class hierarchy (array of refs or array of paths).

*Disclaimer:

This version 2 of the API is not in the Code Repository yet because I haven't ported it back to 8.6 and haven't retested all methods, so use at own risks. But between you and me, the code for hierarchy is safe.

I also changed the package naming convention since version 1, so you might get a palette conflict if you have both installed at the same time. It might go back to what it was, but most likely, I'll just change the place where the code is stored and where it's installed in the palette to be able to install both. Version 1 becoming "deprecated" simply because I'd rather call it lavag_lvclass_api than normandinf_lvclass_api...

lava_lib_lvclass_api-2.0.0.15.vip

Link to comment

Thanks, I'll take a look, but what do I do with a VIP file? :blink:

Br, Mike

Download VIPM from jki.net. It's a code reuse package manager. Very useful to distribute code, get code from others and keep track of all your own reuse code, with forward portability between versions.

If you don't want to install a third-party software, PM me and I'll send you a code example.

Link to comment

Thanks again. I "abused" your library to get the LVClassLibrary.ParentClass which I was unable to find in the menu. :worshippy:

I hope you don't mind...

Br, Mike

Certainly don't mind...

For your RT problem, you might want to keep the hierarchy in a text file. I remember reading about that here on LAVA where people had the same problem. If not mistaken, Antoine Châlons discussed it. (Might be wrong, but try looking for his posts.)

Link to comment

NOOOO!!!!! :frusty:

LabVIEW Class:Open MethodShort Name: LVClass.Open

Available in Real-Time Operating System: No

Why me?!!!

Does someone know of a solution that works on a Real-Time system?

Br, Mike

I am not familiar with RT, but can't you use the Get LV Class Path vi and parse the name from that? Call your parent node vi and have it do the same thing? Each parent could append an array or append a string until you have a complete list?

I can make an example if you need.

Kurt

Link to comment

I am not familiar with RT, but can't you use the Get LV Class Path vi and parse the name from that? Call your parent node vi and have it do the same thing? Each parent could append an array or append a string until you have a complete list?

I can make an example if you need.

Kurt

Thanks for the offer, I thought about this as well, but ideally I am looking for a solution that would not require the developer to explicitly call a function in each implementation of the class. But if I'm forced to...

Br, Mike

Anyhoo, I'll post my Windows only solution tomorrow when I'm back at the office for any other unfortunate soul looking for this information...

Mike

Link to comment

I am not familiar with RT, but can't you use the Get LV Class Path vi and parse the name from that? Call your parent node vi and have it do the same thing? Each parent could append an array or append a string until you have a complete list?

I can make an example if you need.

Kurt

The "Parent Class" property requires that you open a reference to your library (refnum, not object), which you can't do at runtime, so RT is excluded too.

The Get LV Class from Path primitive works on RT, but the hierarchy can only be found, as stated by AQ in another thread Mike mentioned, through hacking the XML. But this solution has not been posted yet, to my knowledge anyway.

Link to comment

The "Parent Class" property requires that you open a reference to your library (refnum, not object), which you can't do at runtime, so RT is excluded too.

The Get LV Class from Path primitive works on RT, but the hierarchy can only be found, as stated by AQ in another thread Mike mentioned, through hacking the XML. But this solution has not been posted yet, to my knowledge anyway.

Maybe I misunderstood the OP. I thought he wanted the name of the class and the names of its ancestor classes not the complete hierarchy of a class, that is, not including its children (descendants).

He mentioned using a dynamic dispatch method, so this up the chain hierarchy would be determined at run time.

Did I miss the objective here?

Kurt

Link to comment

Maybe I misunderstood the OP. I thought he wanted the name of the class and the names of its ancestor classes not the complete hierarchy of a class, that is, not including its children (descendants).

He mentioned using a dynamic dispatch method, so this up the chain hierarchy would be determined at run time.

Did I miss the objective here?

Kurt

You understood it better than me. Now that I read it again (and your answer), I agree with you. Thanks for pointing this out.

Link to comment

What's your actual goal? I mean, why do you need the names of the ancestor classes at runtime? What are you trying to achieve? I ask because the reflection stuff works in editor environments, but not runtime environments. We may be able to propose an alternate approach than getting the class name because i doubt you're going to find a satisfactory solution to that exact problem... and we haven't made the reflection API part of the runtime engine because a) it would add to the size of the runtime engine and believe it or not, there is some effort made to keep the thing from becoming ever larger and b) no use cases have ever arisen where someone would need that kind of info in a running application. But perhaps you can explain the use case that would compel this addition in a future version...

Link to comment
  • 2 years later...

I am pretty new to LVOOP as well but I found one way to do something similar. I added a dynamically dispatched VI to all levels, but the top level, that looks like this:

gallery_11112_82_8999.png

The top level passes an empty string out in my case. Each child calls the parent method and the concatenates the strings given in the constant of each. I was trying to mimic the path given in a shortcut menu selection event. Through this means you could construct an array instead of concatenate.

Link to comment
  • 5 years later...

I was looking for getting ancestry list at RT solution for a while. Found few posts, did some coding - no success. I just reply to this old post as @Aristos Queue asks why would someone need that information. I wish to flatten/unflatten object to other format than xml. Surely this post is a grate start, but still unable to get TD even whole data is there. If flatten/unflatten to xml function can do the job, there must be solution hidden under the hood. 

Link to comment

@Zyga

Here: https://forums.ni.com/t5/Actor-Framework-Documents/AQ-Character-Lineator-working-draft-version-of-serialization/ta-p/3512840

It's my complete, working flatten-to-anything-unflatten-from-anything serialization library for classes [and any other lv data type]. I forget exactly how the names are extracted, but the functions are in there if you want to use them for your own serialization project. Also, feel free to use the library as it stands. 

Link to comment
On 9/7/2018 at 2:03 PM, Aristos Queue said:

how the names are extracted

From what I see they are not. Correct me if I am wrong, but this lib enforce "serialize" method to be overwritten and then calls it through whole hierarchy.
Disadvantage of that solution is a need to change inheritance. Ok, but enough of moaning. We will use one of existing solution. Just wanted to point out where retrieving ancestry list would be useful (wonder why this information is not in the class flattened string?).

Link to comment
Quote

From what I see they are not.

Oh, yeah. I forgot about that. There's a whole writeup somewhere discussing why I did things the way I did for that library. It's been a while since I worked on it. Sorry for the wild goose chase.

Quote

(wonder why this information is not in the class flattened string?).

Flattening the names of the complete ancestry into every flattened string would be an incredible bloat of the flattened size of data.

Quote

Disadvantage of that solution is a need to change inheritance.

I do not believe this is a disadvantage. Serialization is special... if the parent is not serializable then the child is not serializable. Requiring inheritance from a base Serializable does not seem to me to be a bad requirement. Even in other languages where serialization is an interface, mostly they have to add special syntax checking to make sure that the interface is implemented by the eldest class or else it doesn't work. Serialization isn't functionality that can be injected on a descendant level. It's all or nothing to be meaningful because failure to preserve parent state means you aren't actually saving the state of the object. Thus the requirement to inherit from specific base seems absolutely reasonable to me... indeed, it is an advantage because it syntactically assures that the ancestors are included.

Link to comment
6 hours ago, Aristos Queue said:
Quote

Disadvantage of that solution is a need to change inheritance.

I do not believe this is a disadvantage. Serialization is special... if the parent is not serializable then the child is not serializable. Requiring inheritance from a base Serializable does not seem to me to be a bad requirement. Even in other languages where serialization is an interface, mostly they have to add special syntax checking to make sure that the interface is implemented by the eldest class or else it doesn't work. Serialization isn't functionality that can be injected on a descendant level. It's all or nothing to be meaningful because failure to preserve parent state means you aren't actually saving the state of the object. Thus the requirement to inherit from specific base seems absolutely reasonable to me... indeed, it is an advantage because it syntactically assures that the ancestors are included.

Now when I am thinking of it, it sounds obvious. I am possessed by flatten to/unflatten from xml ease of use..

 

6 hours ago, Aristos Queue said:
Quote

(wonder why this information is not in the class flattened string?).

Flattening the names of the complete ancestry into every flattened string would be an incredible bloat of the flattened size of data.

Once again, now mentioned it is perfectly plain. For me it is hard to imagine using more than 3-4 inheritance levels, but looking on e.g. VI Server I see it is reasonable to have more than that.

Edited by Zyga
Link to comment
On 8/12/2010 at 10:50 PM, Aristos Queue said:

b) no use cases have ever arisen where someone would need that kind of info in a running application. But perhaps you can explain the use case that would compel this addition in a future version...

The attached file extracts the relevant slides from a presentation I made at NI Week presentation 2012 that presents just such a case. (I left the slide on Transition Execution Sequence at the beginning of this selection because of the reference.)

The hierarchy can be determined at compile time and stored (not so robust), or at run-time using a couple somewhat complex approaches (adding code to the classes to derive the hierarchy, or attempting casting and see if it fails). Reflection would provide a solution, I think. (The hierarchy could still be determined once at the beginning of program execution.)

TS8237_Lotz_ReflectionExtraction.pptx

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.