Re: DocClass Implement Serial
On Jun 20, 4:51 pm, "RB" <NoMail@NoSpam> wrote:
Well I have done a bit more study and experimenting and I have 3 question=
s.
Ok, you are going ahead of you now. You are not supposed to know the
answer to all these questions so fast, you need 3 years MFC
serialization experience first, minimum! ;-)
Appreciate input from everyone as usual and hopefully Goran will also rep=
ly
since he has helped me the most on serialization and from going back and
rereading the context of his replies (after I studying and experimenting =
enough
to even understand them) I can tell the he has a firm grasp on what is=
going on
in MFC's serialization process. ,
My first question is, I can not help but wonder why MFC does not
generate the Doc class (derived from CDocument) with the Serial macros
as opposed to the Dyncreate.
I guess simply because MFC does need _DYNCREATE (to create the
document at runtime, from a template), but does not need _SERIAL,
because MFC simply calls Serialize(ar); on the document class.
Clearly, to simply call Serialize on an object, you don't need any of
these macros.
Now, remember, _SERIAL gives serialization operators >> and <<, and
schema number. Since every serialization code I've seen so far has
"global" document version, and some "magic" file type marker (your own
does it), I proposed the use of DECLARE_SERIAL and SerializeClass
simply because that will give you both, without reaching out for a
custom solution. SerializeClass will store class name in the
serialization stream (that's your "magic" file type marker), and will
also store the version (that's... well, version).
In all honesty: I came up with this idea of my own and I don't know if
someone else does that. But I see no flaw in it. BTW, IIRC ;-)... If
there's an error in the file (e.g. it's really something else, not
your file), SerializeClass throws an exception with
CArchiveException::badClass. That gets nicely reported in document's
ReportStoreLoadException.
Like at first I was thinking of creating a whole
other class derived from CObject with implement serial just to hold membe=
rs
I wanted a schema to, but then Goran gave an example of the mfc schema
with creating the DocClass with SERIAL and after he showed this to me I b=
egan
to wonder why MFC did not generate it that way ? Maybe because of ......
( Goran did not recommend it since this ties serialization with your =
document
class name, so you could have trouble changing it using of seriali=
zeClass or
operator<</>> and might be a problem if a major overhaul of serial=
ization occurs)
2 other questions below, denoted with ************
one simple mfc comment queston and
another question on 2nd set of code at bottom.
-------Implementing DocClass Serial instead of Dyncreate------
class CFileHandlingDoc : public CDocument
{
// RB question what exactly does this MFC generated comment mean ?
// =
| | | ************
protected: // create from serialization only
CFileHandlingDoc();
Stupid and untrue wizard comments. ;-) I guess it wants to say: ctor
is protected because this will be created from serialization only. But
document will be created at runtime when creating a new document, too,
so it's untrue that it's from serialization only. Only when document
is open, "dynamic creation" AND seralization happen.
// DECLARE_DYNCREATE(CFileHandlingDoc)
// RB doc creation with serial instead
DECLARE_SERIAL(CFileHandlingDoc)
..........
..........
}
// CFileHandlingDoc implementations
// IMPLEMENT_DYNCREATE(CFileHandlingDoc, CDocument)
// RB creating doc with serial instead
IMPLEMENT_SERIAL(CFileHandlingDoc, CDocument, 0)
Wow, wow, not like that! You need SERIALIZABLE_SCHEMA in there. I
always start with SERIALIZABLE_SCHEMA|1, but I guess you can start
with 0 as well.
// And in my DocClass serialize function
void CFileHandlingDoc::Serialize(CArchive& ar)
{
if (ar.IsStoring())
{
ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc));
No, that goes in front of the "if". Otherwise, you're calling it twice
for no reason. See below, you do it already.
ar << VerData.Ver << VerData.CpyRt << VerData.Corp;
ar.SerializeClass(RUNTIME_CLASS(CMapStringToString));
ExpMap1.Serialize(ar);
} =
else
{
ar.SerializeClass(RUNTIME_CLASS(CFileHandlingDoc));
ar >> VerData.Ver >> VerData.CpyRt >> VerData.Corp;
ar.SerializeClass(RUNTIME_CLASS(CMapStringToString));
ExpMap1.Serialize(ar);
} }
// The above compiles and works on writes and reads doc class
// CRuntime Data with no problems
++++++++appreciate comments on below +++++++++++++
So then I am later reading in MFC Under the Hood by
Laura Draxler on page 255 on the use of the SERIAL
macros for user classes derived from CObject, she says:
"It may seem inconsistent to you at first that document
class does not need the SERIAL macros, and it uses the
DYNCREATE macros instead, but the framework provides this
support automatically for the document class."
I believe that this stems from a common misconception that you need
XXX_SERIAL if you want to use serialization. Not necessarily. If all
you want is to call Serialize, do it and forget XXX_SERIAL (in fact,
you can often forget _DYNAMIC and _DYNCREATE, too). But schema changes
get harder then ;-).
As I explained before, MFC calls Serialize on the instance of the
document class, but that's the end of it. It certainly does __not__
provide any additional support for document's serialization (logical,
how can it know about stuff I want to save?). So if it's not calling
SerializeClass, and it is not using << / >>, it does not need
XXX_SERIAL, so why do it?
I'd say that the explanation in the book is confusing at best.
Goran.