Implementing SaveAs (import/export)

Tim Philip -- philip@cs.usask.ca
Sunday, December 22, 1996

Environment: VC++ 4.0, NT 4.0

Has anyone thought of a good way to integrate import/export to an MFC
app?  I am going to simplify my problem here.  I have three MFC 
programs using the Doc/View architecture.  A, B, and C.  A creates 
files of type F1, C reads files of type F2.  B needs to read both 
F1 and F2, and always writes F2.  So what is the best way to
organize this?!  Since I am writing all three, I would like to
re-use (minimize) my code as much as possible.

The best solution I could think of would be to have three
document types.  One called AF1, which creates files of
type F1 in application A.  One called CF2 which creates
files of type F2 in application C.  Then application B
could re-use both of these documents, *PLUS* document
BF1/F2 which reads in F1 files and writes out F2 files.
But this seems kind of crazed.

I took a look at Excel and noticed that it reads in about
15 different file formats that the user can specify in
the "file type" listbox.  How is this handled by MFC?
I know that if I have multiple document types they
will show up in that listbox, and when I open a file
MFC always picks the correct document type ... so
do I have to have a different document for every file
type?  I am equally confused about the "save as"
implementation.  How does MFC tell my app that it is
being saved as a different format?!  How do I register
different formats with MFC?  

I've poked around and cannot seem to find any information 
on this in the documentation, the FAQ, or any of the
sites I know about on the web.  Any hints/tips/
pointers/suggestions would be greatly appreciated.

Thanks!

Tim.

---

Brad P. Exchange -- Brad.P.Smith@Cognos.COM
Tuesday, December 24, 1996

>>
>I took a look at Excel and noticed that it reads in about
>15 different file formats that the user can specify in
>the "file type" listbox.  How is this handled by MFC?
>I know that if I have multiple document types they
>will show up in that listbox, and when I open a file
>MFC always picks the correct document type ... so
>do I have to have a different document for every file
>type?  I am equally confused about the "save as"
>implementation.  How does MFC tell my app that it is
>being saved as a different format?!  How do I register
>different formats with MFC?  
<<
>
MFC doesn't really help you with this. You add the extra file types to
the filter dropdown. On return from the dialog, you check which file
type was selected. From there, you execute specific code to export your
document to the new format. You're not going through the traditional
"FileSaveAs" code unless the selected file type matches your native
type. Beyond that, you're on your own.

>Brad.

---

Mike Bryga -- MBryga@PickSys.com
Tuesday, December 24, 1996


------ =_NextPart_000_01BBF1A5.9B064D80
Content-Type: text/plain; charset="us-ascii"

---

Sathiyamurthy Thiruvengadathan -- sathiya@colmds2.com
Thursday, December 26, 1996

paladin (Tim Philip) wrote:
> 
> Environment: VC++ 4.0, NT 4.0
> 
> Has anyone thought of a good way to integrate import/export to an MFC
> app?  I am going to simplify my problem here.  I have three MFC
> programs using the Doc/View architecture.  A, B, and C.  A creates
> files of type F1, C reads files of type F2.  B needs to read both
> F1 and F2, and always writes F2.  So what is the best way to
> organize this?!  Since I am writing all three, I would like to
> re-use (minimize) my code as much as possible.
> 
> The best solution I could think of would be to have three
> document types.  One called AF1, which creates files of
> type F1 in application A.  One called CF2 which creates
> files of type F2 in application C.  Then application B
> could re-use both of these documents, *PLUS* document
> BF1/F2 which reads in F1 files and writes out F2 files.
> But this seems kind of crazed.
> 

As you've said reading and writing in applications A and C are quite
straightforward. For B, I have a solution which might not be very clean
but will definitely work. In the doc. class of B keep pointers of both
docA (doc class of A0 and docC (doc class of C). Override the
OnOpenDocument fn and check the type of file being opened (by checking
the extension). Set a flag to indicate the type of the file (A or C). In
the Serialize() fn of docB while reading, check this flag - if it is A
allocate memory for the docA ptr and call the Serialize function for
docA. If it is C allocate memory for the docC ptr and call the
corresponding Serialize fn. While writing always write thru the docC
ptr.

///here goes the skeleton code
///.h file
class docB : public CDocument
{
	docA*	m_ptrA;
	docC*	m_ptrC;

	int 	m_nDoctype;
public:
	virtual BOOL OnOpenDocument (LPCTSTR lpFilename);
	virtual void Serialize (CArchive& ar);
....
};

///.cpp file

BOOL docB::OnOpenDocument (LPCTSTR lpFileName)
{
	// parse and get the extension
	if (extension indicates file A)
		m_nDocType = FILE_TYPE_A;
	else if (extension indicates file C)
		m_nDocType = FILE_TYPE_C;
.....
	// Call CDocument's OnOpenDoc
	return CDocument::OnOpenDocument (lpFileName);
}

void docB::Serialize (CArchive& ar)
{
	if (ar.IsStoring())
	{
		// Storing code
		if (m_ptrC == NULL)
		{
		// We read a file type A
		// Now create a docC from m_ptrA and assign ptr to
		// m_ptrC 
		}
		m_ptrC->Serialize (ar);
	}
	else
	{
		// Reading code
		if (m_nDocType == FILE_TYPE_A)
		{
			m_ptrA = new docA;
			m_ptrA->Serialize(ar);
		}
		else
		{
			m_ptrC = new docC;
			m_ptrC->Serialize (ar);
		}
	}
}

Hope this helps. You can mail me directly if you have any problems or
better ideas.

---

Mike Blaszczak -- mikeblas@nwlink.com
Saturday, December 28, 1996

At 16:53 12/22/96 -0800, paladin (Tim Philip) wrote:
>Environment: VC++ 4.0, NT 4.0

>Has anyone thought of a good way to integrate import/export
>to an MFC app? 

Try poking around with the WORDPAD sample--it does almost
exactly what you're asking for.  The STOCKS sample I wrote
for TechEd one year does it, too.  The code was written with
a pretty old version of MFC (eg, it's 16-bit stuff!), but it
ought to function without much extra work.  The programs (and
a couple of whitepapers to support them) appeared on the
MSDN CDs for a while.

>The best solution I could think of would be to have three
>document types.  One called AF1, which creates files of
>type F1 in application A.  One called CF2 which creates
>files of type F2 in application C.  Then application B
>could re-use both of these documents, *PLUS* document
>BF1/F2 which reads in F1 files and writes out F2 files.
>But this seems kind of crazed.

A different approach would be to just implement your serialization
code to know what file type it is reading and remember it for
later, when saving.  This might be more appropriate if the
code isn't so incredibly different and you can find a way to
internally store the data in memory that's the same no matter
what format you've read.

I think your approach is more appropriate if you have different
file formats _and_ different in-memory representations for the
same data.

.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.

---

| Вернуться в корень Архива |