David,[color=blue]
> to serialize the state. So, let's look at my Serialize() function. It[/color]
starts[color=blue]
> off like this:
>
> private Serialize(Stream stream){
> BinaryFormatter bf=new BinaryFormatter();
> bf.Serialize(stream,innerObject);
> bf.Serialize(stream,someObject);
> }[/color]
Actually it would help if we saw where it really started, where the stream
itself is created. :-)
I suspect where it really starts, you create a stream object, then you call
Serialize for each of your UserControls. Correct?
Causing multiple serializations to the same stream. Correct?
Do you always call each user control in same exact same order when you
serialize & deserialize them? If you don't you may have problems later...
Although it makes sense in the context of your design, I'm not convinced
that BinaryFormatter.Serialize should accept a null for the graph either.
I also do not think you need to find a 'workaround' for
BinaryFormatter.Serialize not accepting a null.
Which brings us to your design, not that your design is flawed or anything.
Its simple straight forward, easy to follow. Which is a good thing.
When you use someObject & innerObject in your user controls are you checking
for null each time you use them?
I'm having two somewhat completely different thoughts here, neither of which
may really work for you.
1. Consider using a Special Case Pattern for someObject & innerObject.
http://www.martinfowler.com/eaaCatalog/specialCase.html
Instead of allowing null to be stored in these variables and checking them
for null before each use. Have a NullObject, an object that derives from the
MyInnerClass (or same base class) that returns the same values you would
have used if the variable was null. Your serialization logic can then stay
put. NullObject could be as simple as a singleton in the MyInnerClass
similar to String.Empty. However on deserialization you then need to worry
about getting back to the specific singleton. The IObjectReference interface
is useful in this regard. If NullObject was its own class derived from
MyInnerClass this would not be as big a problem, even then I would make this
new class a singleton.
http://msdn.microsoft.com/library/de...ClassTopic.asp
2. Consider having the Serialize & Deserialize methods accept a HashTable
(or something) instead. Adding or Getting someObject & innerObject from the
HashTable. I would consider using Control.Name as part of the key. Then
where the Stream is created, I would create a HashTable call all the
UserControl.Serialize methods, create the stream, serialize the hashtable,
close the stream.
Hope this helps
Jay
"David Sworder" <dsworder@cts.com> wrote in message
news:OGWeweBaDHA.1640@TK2MSFTNGP10.phx.gbl...[color=blue]
> Hi Jay,
>
> Thanks for your great comments.
>
> Here is the situation: Recall that I have a UserControl-derived class.
> Users of this class need to be able to persist the state of the control.
> This is done via a Serialize() method that I expose on my control. The[/color]
user[color=blue]
> may close/open the app numerous times and at some point it's possible that
> the app may need to create a new instance of my UserControl-derived class
> and restore it to it's given state as specified by the information[/color]
persisted[color=blue]
> in the file. This is done via the Deserialize() method exposed by my
> control.
>
> Note that I'm *not* trying to serialize the control itself. This would
> make no sense [you can't serialize the window handles, etc]. I'm just[/color]
trying[color=blue]
> to serialize the state. So, let's look at my Serialize() function. It[/color]
starts[color=blue]
> off like this:
>
> private Serialize(Stream stream){
> BinaryFormatter bf=new BinaryFormatter();
> bf.Serialize(stream,innerObject);
> bf.Serialize(stream,someObject);
> }
>
> Note that one or both of 'innerObject' and 'someObject' might be null[/color]
or[color=blue]
> non-null. If one (or more) of the objects is null, I need to record that
> "nullness" to the stream so that when my Deserialize() method is called,[/color]
the[color=blue]
> null-ness is restored. Does this make sense? The following call:
>
> bf.Serialize(stream,innerObject);
>
> will throw an exception if 'innerObject' is null. See the problem?
> Perhaps you're asking: If 'innerObject' is null, why serialize it at all?
> Why not just use an 'if' condition to avoid serialization if 'innerObject'
> is null? But that approach would corrupt the stream because my[/color]
Deserialize()[color=blue]
> method would have no idea whether or not to attempt deserialization of
> "innerObject." That's why I'm considering the approach of serializing some
> bit flags into the stream as a reminder at Deserialize-time of whether or
> not certain objects should be deserialized or set to null.
>
> I hope this makes sense.
>
> David
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow@email.msn.com> wrote in[/color]
message[color=blue]
> news:uP9r%23DBaDHA.2284@TK2MSFTNGP12.phx.gbl...[color=green]
> > David,
> > PMFJI: I too get an exception in VS.NET 2003, with an outer object as[/color]
> null.[color=green]
> >
> > However I question the 'need' for workarounds on serializing the outer[/color]
> most[color=green]
> > objects. Isn't having a work around to serialize the outer most object =
> > null, like saying: I do not have a Word document open/created yet, but I
> > need to be able to save the Word document? Note I am saying I do not[/color][/color]
have[color=blue]
> a[color=green]
> > Word document, as opposed to having an empty Word document. An empty[/color][/color]
Word[color=blue][color=green]
> > document I can save...
> >
> > Although you are saying MyInnerClass, is it really your outer class for[/color]
> the[color=green]
> > serialization purposes?
> >
> > If you let the formatter serialize the inner classes while it is[/color]
> serializing[color=green]
> > the outer class you do not need 'work arounds' there either.
> >
> > If I have[color=darkred]
> > > > | [Serializable()]
> > > > | private class MyInnerClass{
> > > > | public int Field;
> > > > | public String Str;
> > > > | }[/color]
> >
> > Elsewhere I would also have:[color=darkred]
> > > > | [Serializable()]
> > > > | private class MyOuterClass{
> > > > | public MyInnerClass inner = null;
> > > > | }[/color]
> >
> > I would have an instance of MyOuterClass which I was attempting to
> > serialize.
> >
> > I would use:[color=darkred]
> > > MyOuterClass graph = new MyOuterClass();
> > > new BinaryFormatter().Serialize(stream, graph);[/color]
> >
> > The formatter, would serialize the MyOuterClass, while serializing
> > MyOuterClass, it will serialize the MyOuterClass.inner field, seeing as[/color]
> the[color=green]
> > field is null, no inner object will be serialized. If MyOuterClass.inner[/color]
> had[color=green]
> > an object reference, that object would be serialized.
> >
> > The above is not intended as a work around, I'm explaining how I[/color]
> understand[color=green]
> > serialization works.
> >
> > Just confused & curious about what you are attempting as I am currently
> > working on serializing my objects.
> >
> > Hope this helps
> > Jay
> >
> > "David Sworder" <dsworder@cts.com> wrote in message
> > news:OeLOqm$ZDHA.440@tk2msftngp13.phx.gbl...[color=darkred]
> > > Hi Jeffrey,
> > >
> > > Yes, I implemented Serialize() and Deserialize() myself. These[/color]
> > functions[color=darkred]
> > > eventually invoke the appropriate methods on the BinaryFormatter[/color][/color][/color]
class.[color=blue][color=green]
> > All[color=darkred]
> > > classes to be serialized are marked with the [Serializable()][/color][/color][/color]
attribute.[color=blue][color=green][color=darkred]
> > > They do NOT implement ISerializable. The problem is occurring because
> > > BinaryFormatter.Serialize() does not accept a null argument for the[/color][/color]
> second[color=green][color=darkred]
> > > parameter. In other words, the top of the object graph cannot be null.[/color][/color]
> You[color=green][color=darkred]
> > > can reproduce the error as follows:
> > >
> > > ArrayList al=null;
> > > new BinaryFormatter().Serialize(stream,al);
> > >
> > > where 'stream' is a reference to a stream. In this trivial[/color][/color][/color]
example,[color=blue][color=green]
> > I'm[color=darkred]
> > > trying to serialize an ArrayList whose value is null. The exception[/color][/color]
> thrown[color=green][color=darkred]
> > > is:
> > >
> > > System.ArgumentNullException: Object Graph cannot be null.
> > > Parameter name: graph
> > >
> > > I can think of many different workarounds for this problem, but it[/color]
> > seems[color=darkred]
> > > like the BinaryFormatter should be able to serialize a null field. If[/color][/color]
> not,[color=green][color=darkred]
> > > what design pattern is typically used to circumvent this limitation. I
> > > suppose the best approach would be to serialize a bit flag of some[/color][/color][/color]
sort[color=blue][color=green]
> > that[color=darkred]
> > > indicates which fields are null and therefore won't be written to the
> > > stream.
> > >
> > > Thanks again,
> > >
> > > David
> > >
> > >
> > > "Jeffrey Tan[MSFT]" <v-jetan@online.microsoft.com> wrote in message
> > > news:blZATW5ZDHA.2108@cpmsftngxa06.phx.gbl...
> > > >
> > > > Hi David,
> > > >
> > > > Are your
> > > > public void Serialize(Stream s);
> > > > public void Deserialize(Stream s);
> > > > implement by your self?
> > > > Are them invoke BinaryFormatter.Serialize(Stream s, Object o) and
> > > > BinaryFormatter.Serialize(Stream s)?
> > > > You use the default serialization or customer your own behavior?
> > > >
> > > > I have tried the default serialization of binaryformatter and it[/color][/color][/color]
works[color=blue][color=green][color=darkred]
> > > well
> > > > with innerclass null.
> > > > I did not find the constrain that the BinaryFormatter.Serialize can[/color][/color]
> only[color=green][color=darkred]
> > > > serialize non-null object.
> > > >
> > > > If you defined your own way of serialization, can you show the code[/color][/color][/color]
to[color=blue][color=green]
> > me[color=darkred]
> > > ?
> > > >
> > > > Best regards,
> > > > Jeffrey Tan
> > > > Microsoft Online Partner Support
> > > > Get Secure! -
www.microsoft.com/security
> > > > This posting is provided "as is" with no warranties and confers no[/color]
> > rights.[color=darkred]
> > > >
> > > > --------------------
> > > > | From: "David Sworder" <dsworder@cts.com>
> > > > | Subject: How to Serialize 'null'?
> > > > | Date: Wed, 20 Aug 2003 16:28:54 -0700
> > > > | Lines: 36
> > > > | X-Priority: 3
> > > > | X-MSMail-Priority: Normal
> > > > | X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
> > > > | X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> > > > | Message-ID: <uNdRTL3ZDHA.2024@TK2MSFTNGP12.phx.gbl>
> > > > | Newsgroups:
> > > >[/color][/color]
> microsoft.public.dotnet.general,microsoft.public.d otnet.languages.csharp[color=green][color=darkred]
> > > > | NNTP-Posting-Host: rrcs-west-66-27-51-213.biz.rr.com 66.27.51.213
> > > > | Path:[/color][/color][/color]
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP12.phx.gbl[color=blue][color=green][color=darkred]
> > > > | Xref: cpmsftngxa06.phx.gbl
> > > > microsoft.public.dotnet.languages.csharp:177963
> > > > microsoft.public.dotnet.general:105256
> > > > | X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
> > > > |
> > > > | Hi,
> > > > |
> > > > | I've created a UserControl-derived class called MyUserControl[/color][/color]
> that[color=green][color=darkred]
> > > is
> > > > | able to persist and subsequently reload its state. It exposes two
> > > methods
> > > > as
> > > > | follows:
> > > > |
> > > > | public void Serialize(Stream s);
> > > > | public void Deserialize(Stream s);
> > > > |
> > > > | Within the MyUserControl class, there is a field of type
> > > MyInnerClass
> > > > | which is defined as follows:
> > > > |
> > > > | private MyInnerClass MyInner=null;
> > > > |
> > > > | ...where MyInnerClass is defined as:
> > > > |
> > > > | [Serializable()]
> > > > | private class MyInnerClass{
> > > > | public int Field;
> > > > | public String Str;
> > > > | }
> > > > |
> > > > | When MyUserControl.Serialize() is called, 'MyInner' might be[/color][/color]
> null[color=green]
> > or[color=darkred]
> > > > it
> > > > | might not be. When it's not null, serialization takes place[/color][/color]
> properly.[color=green][color=darkred]
> > > When
> > > > | it *is* null, serialization fails with an exception because
> > > > | BinaryFormatter.Serialize() expects a non-null parameter.
> > > > |
> > > > | What is the appropriate design pattern to use when serializing
> > > fields
> > > > | which might be null? I'd like to avoid having to serialize an[/color][/color][/color]
extra[color=blue][color=green][color=darkred]
> > > 'bool'
> > > > | flag that indicates whether the field is null or not. Any ideas?
> > > > |
> > > > | Thanks in advance,
> > > > |
> > > > | David
> > > > |
> > > > |
> > > > |
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]
