Can't display a file in an SDI MFC application

[mux]

Hello all,

I'm trying to develop a very simple text editor with VC++, the MFC and the SDI framework. I'm using the CEditView class and I started off with the SDI application skeleton from the VC++ wizard. I am experiencing weird symptoms - or at least they seem so to me.

I can enter text in my view and it gets displayed properly, but whenever I try to open a file (using WinApp::OnFileOpen), all I get on my screen are | characters and not the actual text contained in the file. My code is very similar to the multipad sample except that it's using the SDI framework and not the MDI one, and I'm having a hard time figuring out what's wrong.

My apologies if I'm not describing my problem well, I am a total beginner with VC++ and the MFC :-). Any help would be greatly appreciated.

Thanks,
Maxime

[zerver]

Try the debugger.

Also, check if this works.
m_EditView.GetEditCtrl().SetWindowText("hello");

You can always read the file manually!

/ Z

[bytz]

In the OnFileOpen(), did you actually open and read the file? If so, you can use the debugger to step through the code that reads the file and look at what it's reading. You then want to follow the data to where it get's placed in the editview. Ensure that the memory allocated for the file contents (where the read data is stored) exists until the data is placed in the editview. If all else fails, post your code or email it to me, and I'll take a look.
If you post, potentially others will look as well.

[mux]

I tried to trace the program's execution with the debugger but couldn't see anything obviously wrong. I probably lack the necessary knowledge to use the debugger efficiently.

I added this :

((CEditView*)m_viewList.GetHead())->GetEditCtrl().SetWindowText("hello");


to the Serialize() method of my CDocument derived class instead of the call to SerializeRaw() and it successfully printed "hello" in my view. It's probably not the best place to put it in but at least it shows that it works.

Thanks for your help so far,
Maxime

[mux]

Originally posted by bytz
In the OnFileOpen(), did you actually open and read the file? If so, you can use the debugger to step through the code that reads the file and look at what it's reading. You then want to follow the data to where it get's placed in the editview. Ensure that the memory allocated for the file contents (where the read data is stored) exists until the data is placed in the editview. If all else fails, post your code or email it to me, and I'll take a look.
If you post, potentially others will look as well.

I'm not doing anything in OnFileOpen() since I'm using WinApp::OnFileOpen.

Thanks,
Maxime

[bytz]

Originally posted by mux
I'm not doing anything in OnFileOpen() since I'm using WinApp::OnFileOpen.

Thanks,
Maxime

Eventually it will need to get to code that you wrote to read the file. I beleive (not totally sure) that if you intend to use serialization that it will not work on a plain text file, you'd need to check around on that, or ensure that the deserialization code handles it appropiately... My personal feeling is to just read/write the file you're interested in without the hassles of serialization... but that up to you.

[mux]

Originally posted by bytz
Eventually it will need to get to code that you wrote to read the file. I beleive (not totally sure) that if you intend to use serialization that it will not work on a plain text file, you'd need to check around on that, or ensure that the deserialization code handles it appropiately... My personal feeling is to just read/write the file you're interested in without the hassles of serialization... but that up to you.

I'm a bit astonished since the multipad sample just uses SerializeRaw() as I do, and it's able to read and write from text files perfectly. I should probably document myself better about what SerializeRaw() does.

Anyways, if I chose to read and write the file myself, should I change my Serialize() method and do it there, or should I make things differently?

Thanks again,
Maxime

[bytz]

I've looked through your code, and you need to handle/write appropiate code to read/write the file in the CTest2Doc::Serialize method, or figure out what/why SerializeRaw() is failing...

[mux]

Originally posted by bytz
I've looked through your code, and you need to handle/write appropiate code to read/write the file in the CTest2Doc::Serialize method, or figure out what/why SerializeRaw() is failing...

First, many thanks to you for taking the time to look at this code.

I've looked at CEditView::SerializeRaw() and couldn't find anything which could explain why it was failing on me. I've traced the code in CEditView::ReadFromArchive() and the file content is properly read and put in a buffer. I examined this buffer and it's not corrupted or anything at this point. So this suggests that something bad happens when this code calls CEditView::GetEditCtrl()::SetHandle(). SetHandle() is implemted using a message, and I don't know how to debug this problem further. Any ideas?

Thanks,
Maxime

[bytz]

Well from MSDN, SetHandle:

Call this function to set the handle to the local memory that will be used by a multiple-line edit control. The edit control will then use this buffer to store the currently displayed text instead of allocating its own buffer.

This seems to be a really weird implementation for These functions to use... Once the SerializeRaw() method is finished, do you still have access to the data? If so, try setting the edit text (setwindowtext) directly from that buffer. If I were doing this code, I'd avoid the serialization and do my own file handling, as it seems like overkill to use it...

Just read through the code for SerializeRaw(), as I was writing this... I have no clue as to why they'd (MS) want to change the handle (the edit ctrl's internal text buffer)... I'd think about overriding the SerializeRaw method in your code, copy the stuff from the CEditView::SerializeRaw() method to your method and
change it to allocate the memory, read the archive, and call setwindowtext. You don't need to use the LocalAlloc, Lock & Unlock stuff, as that's only for 16-bit windows compatibility...

The only reason I can think of for using the SetHandle stuff, is that it's a work around for the limit of text in a CEdit.

[Sam Hobbs]

First look at my Simple CEditView Application. Then if you need something different then I will try to help.

[mux]

Originally posted by Sam Hobbs
First look at my Simple CEditView Application. Then if you need something different then I will try to help.

The application I was working with wasn't generated using a CEditView class but with a CView one because I didn't know it was possible to tell the wizard to use an another view class at that time. I then changed it to a CEditView myself. So I started a new application from scratch using the wizard, following the suggestions in your site. I was pretty sure I botched something up when I did the move from CView to CEditView.

I selected an MFC application with the SDI framework and, this time, using the CEditView class. Unfortunately, it exhibits the exact same symptoms as my little piece of code, that is it prints | characters instead of the file when I open one.

I didn't even touch one character of the code generated by Visual Studio C++ and built it as is. At least it seems to show that I didn't do anything dumb... I'm starting to think that the problem I'm having is more serious, and maybe lies in the MFC libs or something.

I'm not so much interested in knowing how to work around this problem and have something working, but I'd be more than happy to understand what the **** is going on here. I don't really need this application, I started doing it in order to learn VC++/MFC.

For what it's worth, I'm using Windows XP and VC++ 7.0. Maybe I'm hitting a well known problem ?

Thanks for your help,
Maxime

[Sam Hobbs]

My guess is that it is the data. Are you able to view the data using other applications? You probably already answered that question previously so I apologize for asking if you did. Are you sure it is not a Unicode text file? If it is then most applications would display it properly and you might not realize it is Unicode.

[mux]

Originally posted by Sam Hobbs
My guess is that it is the data. Are you able to view the data using other applications? You probably already answered that question previously so I apologize for asking if you did. Are you sure it is not a Unicode text file? If it is then most applications would display it properly and you might not realize it is Unicode.

The files I was trying to open are all plain text files, created with notepad, so I guess they aren't unicode files. What is probably the best proof is that when I trace the program's execution in CEditView::ReadFromArchive() and examine the buffer in it, I can see that it's a normal string, which contains the file's content as expected.

Thanks,
Maxime

[Sam Hobbs]

This does sound strange. I am not aware of any problems and since you say you compiled the generated application as it existed when generated, it sure should work.

If the files you are working with are small and do not have anything you can't share then try attaching a sample of the files to a reply so we can see what the data looks like.