fstream problems. No output to file.

[Earth Wyrm]

Hi, as is about to become entirely apparent, I'm a newbie programmer and I'm having some problems with what should be simple operations.

I'm having some trouble writing to file and no matter what method I use I can't seem to get it to work as I hope it to. I use the code below to open a file and append some text to it, but when I open the file afterwards to check that it has worked, the file is no different to how it was before I attempted to write to it.
Even if I specify ios:trunc (whic should clear the whole file) it seems that there is no change made at all.

The code below contains three different methods of writing to file for means of testing (in the hope that even one of them works).

fstream OutputFile;
		
OutputFile.open("Notes.txt", ios::out|ios::app);
	
if (!OutputFile.good())
{
	MessageBox(hwndContainer, "There has been a problem opening the file", "File error", MB_OK);
}
{
	OutputFile << "Just write to file!" << endl;
	OutputFile.write("Hello?",7);
	OutputFile.put('Test');
}
OutputFile.close();

The file 'Notes.txt' is not open and is not ever opened anywhere else in the program, so it's not that I'm trying to open a file which is already open.
If I place a breakpoint on any one of the output statements, I can see that the program does run them, so I'm not sure what to think.

I've read several tutorials and threads on the use of fstream and I can't see any difference between the way that I'm using it and the way that I'm supposed to be using it. I've even used it for input earlier on in the program (from a different file which I then close). I'm completely stumped.

No doubt I'm making some silly fundamental error somewhere, but I just can't seem to find what it is that's causing the problem.

Any help would be appreciated, thanks.

Edit:
I moved the code to a different section of my program (to the end of WinMain) and it worked.
I guess then it has something to do with when I'm calling the code. Here's some more code from the place that I want it to be:

case IDC_ADDSYMBOL:
{
	bool ReturnValue;
	ReturnValue = DialogBox(GetModuleHandle(NULL), MAKEINTRESOURCE(IDD_NEWSYMBOL), hwndContainer, NewSymbolProc);
	if ( ReturnValue )
	{
		//file stream - ios:app Input/output stream for appending.
		fstream OutputFile;

		OutputFile.open("Notes.txt", ios::out|ios::app);

		if (!OutputFile.good())
		{
			MessageBox(hwndContainer, "There has been a problem opening the file", "File error", MB_OK);
		}
		{
			OutputFile << "Just bloody write to file!" << endl;
			OutputFile.write("Hello?",7);
			OutputFile.put('Test');
		}
		OutputFile.close();
	}
	else
	{
	}
	break;
}

This is in a switch checking the loword of wParam after receiving a WM_COMMAND notification. IDD_NEWSYMBOL is an input form. ReturnValue is true if the user clicked OK and the input form was filled in correctly, otherwise it's false.

[Earth Wyrm]

I've just been trying a few things, moving the code around to different places to see where it works and where it doesn't. It seems to work in all of the places which aren't useful to me, and not to work in all the places that are.

Here's what happens if I pass it to WindowProc - it works fine on WM_CLOSE but not on a custom message.

Worse than the fact that it doesn't work is that I don't know why it doesn't work. ¬_¬

case WM_CLOSE:
{
	/*
	If I put the output to file code here, everything is fine 
	and the output appears in the text file
	*/

	//Destroy the window
	DestroyWindow(hwnd);
	//And let the OS know that it's over between us.
	PostQuitMessage(0);
	break;
}
case WM_WA_NEWSYMBOL:
{

	/*WM_WA_NEWSYMBOL is a custom message whic I've defined so as I can pass the output statements to WindowProc.
	It doesn't work here, even though this code gets executed*/

	fstream OutputFile;

	OutputFile.open("Notes.txt", ios::out|ios::app);

	if (!OutputFile.good())
	{
		MessageBox(hwnd, "There has been a problem opening the file", "File error", MB_OK);
	}
	{
		OutputFile << "Just write to file!" << endl;
		OutputFile.write("Hello?",7);
		OutputFile.put('Test');
	}
	OutputFile.close();
	break;
}

Edit:
The same problems are encountered if I use send a WM_COMMAND message from the child dialog box instead of a custom message.

[Bench]

Perhaps, while you're learning, it would be a good idea to leave all the windows stuff alone. at least until you've got a firm grip on the basic language.

There's alot less that can go wrong when you're just dealing with C++ on its own.

[Earth Wyrm]

Thanks, I might be tempted to take that piece of advice if it weren't that I've already put a couple of weeks work into this program. :)

Once it can write out to a text file it's virtually complete, so I'm kind of anxious to get this part working.
I've already implemented a dialog box to get all the information that needs to be added to the text file, it places all the information in a structure ready to be written - I just can't seem to write the information to file when it's appropriate.

[Lerner]

One or the other or a combination of these suggestion may be helpful

fstream OutputFile;

//try removing the ios::app mode until you can write to file in the first place
OutputFile.open("Notes.txt", ios::out|ios::app);

if (!OutputFile.good())
{
   MessageBox(hwndContainer, "There has been a problem opening the file", "File error", MB_OK);
}

//try putting an else here
{
   OutputFile << "Just bloody write to file!" << endl;

   //You may not need to include the null char here, so try 6 instead of 7
   OutputFile.write("Hello?",7);

   //Test is a string whereas put() is used with a single char so use 'T' or 'e' or 's' or 't' but not 'Test';
   OutputFile.put('Test');
}
OutputFile.close();

[Earth Wyrm]

Cheers Lerner. :)

I got it working in the end, it seems like if the output was in WM_CLOSE, WinMain (And no doubt a few other places I didn't test) then it didn't need a full filepath and would open Notes.txt without any problems (Notes.txt was in the same directory as the executable), but when I moved it elsewhere it needed the full filepath for notes.txt to be given explicitly. If it wasn't given explicitly then, for some reason, it would fail to open but not post the error message I set up for if fstream.good() == false. In fact, fstream.good() was evaluating as true.

A bit wierd, but I just set up a function using GetModuleFileName() to get the filepath for the executable and put it in a string, trim filename.exe off of the end and process it character by character to 'double up' on any backslashes. Using that string (with "Notes.txt" concatenated) in the open statement made it work fine.
It's puzzling why it needed the path to be explicitly stated in some places but not in others, but at least it works now.