write to file

hi
i am writing a function writing to a file every one second, i get this error:
An unhandled exception of type 'System.IO.IOException' occurred in mscorlib.dll

Additional information: The process cannot access the file 'c:\users\mohamad\documents\visual studio 2005\projects\save to file\debug\file3.txt' because it is being used by another process.
THANKS

private: System::Void timer2_Tick(System::Object^  sender, System::EventArgs^  e) 
{DateTime		^now = System::DateTime::Now;
file2 = gcnew StreamWriter(System::AppDomain::CurrentDomain->BaseDirectory+"file3.txt");
MessageBox::Show(now->ToString());
 file2->Write(now->ToString());
 file2->Close();  
}

Open in new window

klay8Asked:
Who is Participating?
 
Alexandre SimõesConnect With a Mentor Manager / Technology SpecialistCommented:
My guess is that 1 second is too little time to this task.
If the StreamWriter is still open when the method is called again this exception will occur.

Try making it 5 or 10 seconds just to test it out.

My advise is that you evaluate the state of the stream right on the beginning of the method.
Declare the StreamWriter outside of the method so there's only one instance of it at a time, at the beginning of the method evaluate if it's open, if so exit, will try again on the next second.
0
 
josgoodConnect With a Mentor Commented:
The problem is the MessageBox::Show.  Consider:
1)  the timer ticks, timer2_Tick is entered and opens file3.txt.
2)  the MessageBox displays and waits for user input
3)  the user does nothing or is too slow
4)  the timer ticks, and timer2_Tick attempts to open the file again
5)  the file is still open from last time, and so the new attempt to open fails

Remove the MessageBox::Show and the problem will go away.
0
 
DauheeCommented:
instead use:

 my.computer.filesystem.writealltext
0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
Alexandre SimõesManager / Technology SpecialistCommented:

josgood: I considered the messagebox was there just by mistake for some test... it's essential thar a repetitive task that occurs every one second doesn't have any user interaction :)

Dauhee: that's VB and the man's code is C++ :)


Cheers!
0
 
josgoodCommented:
OK.  Understood on why you didn't mention the MessageBox.  

I did a short test, using a 0.1 second timer with the MessageBox removed, and there was no problem.

If more data was being written, I could agree with the idea that more time is required.  With a write this short, however, I don't see a problem on modern hardware.
0
 
Alexandre SimõesManager / Technology SpecialistCommented:
I don't know if the whole provided code was a mere example... is it just
file2->Write(now->ToString());

the real scenario? or is this just a sample code that wasn't well done?

Is this writing to a local drive or using a remote path?
How many process write/read to this file?
Can it be opened directly by a user?

All questions must be answered and in either case I think an "escape plan" right on the begginig of the method is in order to act as a safety net if the file is exclusively opened by another process...

Like "they" say... s**t happens :)
0
 
josgoodCommented:
These are all good questions.

I concur on the safety net.
0
 
itsmeandnobodyelseCommented:
>>>> The process cannot access the file 'c:\users\mohamad\documents\visual studio 2005\projects\save to file\debug\file3.txt' because it is being used by another process.

Do you have any idea what the second process is?

you didn't look at the file in the Visual Studio or another text editor?

Generally, if you open an existing file for write, it is truncated to zero size. That only works, if the file wasn't opened for write in a second program.

>>>> file2 = gcnew StreamWriter(System::AppDomain::CurrentDomain->BaseDirectory+"file3.txt");
You better split that statement into two. First build teh filename as a string. Then create a new StreamWriter object passing that string. Doing so, you can check whether the built filepath is valid in the Debugger. You also cancheck whether you can delete the 'existing' file using Windows Explorer and/or the command window. If you can't do it from there, it is clear that it wouldn't work programmatically either. Last, you could put the 'open' statement into a try catch block and handle the exception rather than let it crash.

0
 
Alexandre SimõesManager / Technology SpecialistCommented:
The process that is locking your file is the one that runs that code you've posted...

The first tick goes correctly but after one second another tick calls the same code but the file is still exclusively opened by the previous tick.
0
 
itsmeandnobodyelseCommented:
>>>> The first tick goes correctly but after one second another tick
>>>> calls the same code but the file is still exclusively opened by the previous tick.
No. While the timer handler was running there is no further timer action. Windows timers either were invoked by a message pump which calls timer handlers asynchronously but not in a separate thread.  And system timers have one timer handle which changes between signaled or non-signaled. While your are handling a timer event you must not fear that the same timer will be triggered again as long as you don't establish such a behavior yourself.
0
 
Alexandre SimõesManager / Technology SpecialistCommented:
Yeah... I think you're right...
I've done a little test and dropped the ticking interval to 1 millisecond and it works fine, no problems writing to a file.

Still there's no problem setting UI controls properties which means that it runs on the same thread than the UI.
The only way I was able to crack this was opening the file from the explorer wile the timer was running.
0
 
klay8Author Commented:
hi i resolved by this:

My guess is that 1 second is too little time to this task.
If the StreamWriter is still open when the method is called again this exception will occur.

Try making it 5 or 10 seconds just to test it out.

My advise is that you evaluate the state of the stream right on the beginning of the method.
Declare the StreamWriter outside of the method so there's only one instance of it at a time, at the beginning of the method evaluate if it's open, if so exit, will try again on the next second.

for now it's ok for me,
but i am interested about what u said all of u

thanks
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.