Can't display a file in an SDI MFC application

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

Try the debugger.

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

You can always read the file manually!

/ Z

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 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

Quote:

---

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

Quote:

---

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.

Quote:

---

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

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...

Quote:

---

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

Well from MSDN, SetHandle:

Quote:

---

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.

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

Quote:

---

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

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.

Quote:

---

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

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.

Quote:

---

Originally posted by 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.

---

Sure. Here is the little text file I was using to test my code. It was created with notepad.

For what it's worth, I tried on another Windows XP computer to see if that wasn't due to my computer being hosed, and it exhibits the very same symptoms. Also, I tried using the MDI framework instead of the SDI framework and it's still the same.

Thanks,
Maxime

You are correct, that is a plain (non-Unicode) text file. So the next thing you can do if you want is to post the project.

The best way to do that is to zip the project. If you want to include the exe file then that would be good but we don't need anything else from the Debug and/or Release directories. It would help to have the contents of the Res directory but that is not important. You can also omit the following file extensions: aps, ncb, opt and plg, although their sizes are relatively small.

Quote:

---

Originally posted by Sam Hobbs
You are correct, that is a plain (non-Unicode) text file. So the next thing you can do if you want is to post the project.

The best way to do that is to zip the project. If you want to include the exe file then that would be good but we don't need anything else from the Debug and/or Release directories. It would help to have the contents of the Res directory but that is not important. You can also omit the following file extensions: aps, ncb, opt and plg, although their sizes are relatively small.

---

Ok, I think everything you asked for is in this zip file. I hope I didn't omit anything important nor put unneeded files :-).

Thanks,
Maxime

I had to do some things to get it to compile using VC 6 but when I did compile it the program works; that is, it can open the test.txt file and it looks normal. I was unable to execute the exe though since it is a debug version of a program compiled using VC 7. It it were a release version I would be able to execute it.

Also you did good in creating the zip file except the res directory was not included. I was able to create one easy enough and I know you are just beginning with this stuff so I just wanted to let you know that what you did is good except if you do this in the future you can try to include the res file also.

So I don't know what to say. Perhaps there is a problem with VC 7. Probably the good news is that it is not likely to be a problem with what you are doing.

What happens when you open other text files? Is there a problem if you open a cpp file or a h file? What happens when you create a file using your simpleedit; can you later open it? Can you open the saved file using notepad?

Quote:

---

Originally posted by Sam Hobbs
I had to do some things to get it to compile using VC 6 but when I did compile it the program works; that is, it can open the test.txt file and it looks normal. I was unable to execute the exe though since it is a debug version of a program compiled using VC 7. It it were a release version I would be able to execute it.

Also you did good in creating the zip file except the res directory was not included. I was able to create one easy enough and I know you are just beginning with this stuff so I just wanted to let you know that what you did is good except if you do this in the future you can try to include the res file also.

So I don't know what to say. Perhaps there is a problem with VC 7. Probably the good news is that it is not likely to be a problem with what you are doing.

What happens when you open other text files? Is there a problem if you open a cpp file or a h file? What happens when you create a file using your simpleedit; can you later open it? Can you open the saved file using notepad?

---

Thanks for taking a look at this code! I'll be sure to include the res directory next time :-).

SimpleEdit exhibits the exact same symptoms when I open other text files, header files, cpp files, etc.... When I create and save a file with SimpleEdit and open it with the notepad afterwards, I can only see the first character of the file.

I'm going to search the web to see if I find any reports of such problems with VC++ 7. Do you need me to attach a release version of the executable here?

Thanks,
Maxime

You can provide a release version if you want me to try executing it using my system but I can only tell you whether it works the same as it does on your system(s).

[QUOTE]Originally posted by Sam Hobbs
You can provide a release version if you want me to try executing it using my system but I can only tell you whether it works the same as it does on your system(s). [/QUOTE

I guess that's still a valuable information. Here is a release version of the executable.

Thanks,
Maxime

Since the same code works correctly with Sam's VC++ version 6, but fails with mux's version 7, I'll hazard a guess: mux might be compiling with UNICODE defined.

I don't know how to check this in version 7 since I also use version 6. Typically you would look under project settings, or maybe at the top of your stdafx.h file.

Sorry that this is a guess, and that I'm hazy on where to check if UNIDODE is defined. Maybe Sam will tell us that he compiled with UNICODE defined and that it works fine, in which case you can all justifiably deride me for being a silly speculator :)

Mike

I don't have mfc70.dll but I was going to see if I could get it from somewhere. Probably I can.

I considered the possibility that Unicode is defined so I searched the files for the VC 7 project and did not find "Unicode" so I assume that is not the problem. When I execute Maxime's compiled exe I shoudl be able to easily determine if it is using Unicode.

If anyone has mfc70.dll and was able to execute the program then you can let us know what happens.

Quote:

---

Originally posted by Sam Hobbs
I don't have mfc70.dll but I was going to see if I could get it from somewhere. Probably I can.

I considered the possibility that Unicode is defined so I searched the files for the VC 7 project and did not find "Unicode" so I assume that is not the problem. When I execute Maxime's compiled exe I shoudl be able to easily determine if it is using Unicode.

If anyone has mfc70.dll and was able to execute the program then you can let us know what happens.

---

What I know for sure is that I didn't define UNICODE myself, so if it is defined, it has been done by the project wizard. I don't see UNICODE defined in stdafx.h either, but maybe it lies elsewhere?

I tried to attach my mfc70.dll file after zipping it, but it exceeds the maximum size allowed by the forum.

Thanks,
Maxime

If Unicode is specified for a VC 7 project the same way as for a VC 6 project then it is done in the project settings.

If you want to try something you could try creating a static release build instead of a dynamic release build. Then MFC70.dll would not be needed. The problem is that then the exe might be too big to fit as an attachment here but probably not.

To do a static release build change the project settings to specify use of MFC in a static library instead of a shared DLL.

Quote:

---

Originally posted by Sam Hobbs
If Unicode is specified for a VC 7 project the same way as for a VC 6 project then it is done in the project settings.

If you want to try something you could try creating a static release build instead of a dynamic release build. Then MFC70.dll would not be needed. The problem is that then the exe might be too big to fit as an attachment here but probably not.

To do a static release build change the project settings to specify use of MFC in a static library instead of a shared DLL.

---

I found a setting for the character set in the project properties. It was set to multi-byte character strings. Setting it to unicode produces different garbage when opening a file, but it's still garbage :-). Setting it to "Not set" doesn't change anything.

I wanted to attach a static release build to this post, but the file is too big for the forum.

Thanks,
Maxime

The problem you are seeing is to do with visual styles.

A quick google search found this explanation:

http://tinyurl.com/ywnvz

I am still looking for a solution...

Anthony Wieser
Wieser Software Ltd

I think you misunderstood what I meant by specifying Unicode in the project settings. I might have forgotten what it is I meant, but I am nearly certain I meant that your application (project) should be built for Unicode. Note that I said project settings.

I think you are setting the Options, not the project settings, when you set the character set. Unless VC 7 is different, there is not a setting for a font (character set) for a project. Are you sure it is a project setting you changed? If not, then it sure won't have any affect on your program, except possibly enabling you to see the data correctly using the editor (Visual Studio).

The problem I see occurs in an ANSI build. It works if you don't have a manifest attached to the program, and doesn't if you do.

I am building with VC6.

Anthony Wieser
Wieser Software Ltd

Here are a few comments a few years on for what its worth:

CEditView has a method called SerializeRaw() which is different to all the other Serialize() methods. For loading Serialize() expects the first two words to be size information. If you have a normal text file and use Serialize(), then the first two characters ascii value is interpreted as numbers. Then Serialize() reads that much data, which may be over the end of the file and look like garbage. SerializeRaw() expects a normal text file with no size information in the first couple of words.

Allan