Serialization and Dynamic Dispatch

[GabbyG]

Hi

first let me congratulate you to that wonderful tool. The more I use it the more I love it......

I have a class with several children. At one point I want save the current state of a child on disk and read it back sometime later.

The serialization is done with a reference to the parent hoping that dynamic dispatch will sort out the proper child info.

I used XML coding to verify and it seems that this part going right.

When I read back the serialization string, I do not know of which child class that record came from.

I tried to use the parent constant as template for the de-serialisation, hoping the vi would generate an approriate child. It seems that it does not do this.

Is there a way to analyze the content of the serialisation to find out which child was saved ?

Thanks in advance.

Gabi

[Mattias_Ericsson]

Hi Gaby,

Actually the support for serialize an object of a class that contains aggregate was removed for XML in the last version, but works for binary serialization. The XML serialization didn't work properly and was to difficult to make an easy fix upon. Serialization of an aggregation tree is quite difficult, but it work for non-XML option. However, that makes the parsing of the string more difficult.

I'm not sure if I understand the "When I read back the serialization string, I do not know of which child class that record came from.", but typically you use the "Deserialize" VI to serialize back and object state? After serialization of the object to disk, is the application closed then and you later try to deserialize the state back when restarting your application.

Could you please explain a bit more or attach an example.

Mattias

[GabbyG]

Thank you Mattias form coming back so promptly.

I have attached two images of what I want to do .

This is part of a sequence handler.

The user is given a tool to configure a sequence of actions on different sets of registers of a device.

The sequence is stored in a file and at times read back for editing or to execute an action (i.e. write the registers).

The register sets are all similar and are derived from a parent class "Struct" (excuse the trivial name). Method "Open" as seen in the serialize clip will collect the current values that are open in a subpanel and store them in the obj attributes. (Not all child "Open"s are yet done as you can see.)

When I read back the string from disk I want to insert it into a parent-type object (Struct) that can be used later but only as an instance of the child class that was stored before.

A parent-class of  "Struct" holds a list of all active childs and I could access them to fill them from the string. Is this how de-serialisation is supposed to work ?

The orignal project is too large, but I may build a sample if you want it.

Thanks

Gabi

[Mattias_Ericsson]

Hi,

A-ha, now I see what you are up to. If I understand you correctly, your problem is when you deserialize, you are not sure which concret subclass implementation that was used when serializing in order to use the correct (=same) subclass to deserialize. No, you can't see that from the serialization string.

I probably would solve this by using "G#Object.lvclass:GetClassName.vi" or "G#Object.lvclass:GetClassPath" before I use serialize. Then you could store this information together with the serialization stream. When deserializing, you could check class name (or path) info and choose correct subclass instance to use when deserializing the object.

I attach two exampe of the two ways. The "path" approach lets you get rid of the subclass constants in deserialization that you may want to avoid in order to create more generic code. In the path way  you need to convert the G# reference to the more specific "base" reference in order to use any methods in the class later.

Thanks,

Mattias

[GabbyG]

Hi Mattias

Yes you are right, that's what I wanted to do.

I had prepared a little example, of what I wanted to do, but you have already given solutions. Thank you.

In my application it's no problem to attach the name of the class, there is more information to go along anyway.

Everything will be clustered and stored as a variant. But handling the main information as a class instance makes everything still much simpler.

Thank's again for that great tool G#.

Gabi