Persist Data in UserControl

[Merchand]

I'm looking for a little help here on how to persist data in a User Control class library in VB.net. I have this StatusBar UserControl and it is made up of two statusBar constituent controls called sbrMessage and sbrApplication. The sbrMessage is to display any type of message the user wants during application development. While, the sbrApplication contains several panels one for time, one for date, one for application name, one for caps lock and one for num locks, etc...

I'm wanting to know the best and perferred method of persisting my user control's data. I have been reading as much online stuff as possible from msdn and elsewhere. I have asked this question before in the window forms forum. I'm looking at using binary serialization to store my usercontrol data but is this the best solution? (In VB6 we had the property bag to store data for persistancy.

Help!

 

[JohnH]

MS suggested replacement for the property bag is serilization, be it to binary or xml.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchPropertyBagChangesInVisualBasicNET.asp

 

[Merchand]

JohnH,

Very good info! I appreciate the link and information!

Yesterday I had read a lot on Serialization and was leaning toward it. However, both Serialization and Dynamic Properties in a test application or real application that is using my user control will have to do the work of serializing or dynamically saving the property values.

I was thinking there should be a way for me to expose properties and methods in my user control to help the application developer to do this saving, retrieving, etc... What would be the advantages and disadvantages of doing this? If I allowed the user to select the save location or just saved it in there app path. (???)

Feedback welcome!

 

[jmcilhinney]

You could just implement IDisposable and handle the serialisation in the Dispose method. You could then handle the deserialisation in the constructor. That way the caller needs not even know that the serialisation is taking place. I'm not 100% sure that that would be considered appropriate use of a Dispose method or not, but it certainly does the job.

 

[Merchand]

jmcilhinney, I'd say your 100% right about the Construtor/Dispose method. I may not even have to implement IDisposable. I might be able to just override the Dispose Method and then call the base Dispose method. (???)

I was not able to get the Serialization/Deserialization to work with the UserControl I created because the UserControl does not expose or use the <Serializable()> attribute so I can't use it in my inherited usercontrol.

I was able to move my private data to a new Friend Class with Friend member variables and then use Serialization/Deserialization on that class. However, I had to rework all of my public properties so they worked with the new private instantance of my new class. I did get the S/D to work great but some how I seemed to lose my connection to the testapp's properties for the usercontrol.

Maybe the Contructor/Dispose Method might help. I'm just wondering if I even really need to keep track of the property values. If I add a M$ control or other 3rd-Party control to my form I don't expect them to keep my property value changes. Normally they would change the initial property settings and those would be placed in the InitializeComponent() area of system generated code. And if I then changed those property settings in code the application would normally default to the values in the InitializeComponent() area.

So Now I'm thinking I don't need to make this work. I'm going to play with it some more today if I have time.

What do you think?

 

[jmcilhinney]

As far as IDisposable is concerned, in fact you cannot implement it in a class if one of its ancestors already does. As for whether you need to persist the data at all, that's completely up to you. It really depends what the data is and why you wanted to persist it in the first place. If you're talking about Size and Location and things like that then normally it should be left up to the containing form, but there may be other things that it wants to keep. Normally though, I would think it would be up to the application designer, not a third-party provider, to decide what data an application needs. There are always special circumstances though.

 

[Merchand]

jmcilhinney,

Wow, great advise on where or not I should even persist this data. I did learn a lot about Serialization/Deserialization. I plan on doing a lot more controls in the near future. Thanks for all your help!