respectively. Only problem occurs is when a large file is being copied over, say 8-10MB. The bar just hangs until the file is copied over and then adjust to my calculation of completness. How can I configure a progress bar to realtime?
Are you doing the file copy in the program's main thread?
Or are you creating a worker thread to do the copy?
Any action that takes a "long" time should be placed into a worker
thread. If something takes a long time, then the main window
cannot get updated periodically.
If you use the main thread for the copy, then you need to create
a worker thread and do the work there.
Originally posted by cvogt61457
Are you doing the file copy in the program's main thread?
Or are you creating a worker thread to do the copy?
Any action that takes a "long" time should be placed into a worker
thread. If something takes a long time, then the main window
cannot get updated periodically.
If you use the main thread for the copy, then you need to create
a worker thread and do the work there.
I would take exception to that as a generalization. Worker threads can be useful if other work can be done while a background task is running. There's no point in creating a thread and the issues that go with synchronizing multiple threads if it doesn't enable the user to be more productive.
In this case if he's using CopyFile, he just isn't getting any progress messages until the copy is complete. There isn't much he can do about that unless he writes the copy code himself.
I am using a modal dialog with the progress bar and code with it. It works well. Until the file copy process is complete, I do not want the Parent dialog (I assume this is what is ment by main thread) to gain focus. And it doesn't, if a user clicks on it, it simply shows the "not responding message". This is Ok.
I guess I'm trying to get something closer like you would see on a download from the internet. You can download winzip from download.com or else were. Even though it is a 1-3MB file, you still get a download progress that is incremental during the downloading of the file.
Originally posted by Sam Hobbs
If that is the only alternative then a worker thread is a useful solution.
But he still won't get status back from CopyFile indicating how much of the file is done. As I understand his problem he gets a large jump in his progress bar after a large file is copied. To avoid that he'd have to write a copy function himself (which would be all of 20 lines of code or so) and then he'd know how much of the file he'd copied and could update his progress bar as the file was copied.
In this case I don't think a thread buys him anything at all.
Originally posted by GCDEF
But he still won't get status back from CopyFile indicating how much of the file is done.
Who says CopyFile is being used? As far as I can tell, you are the only one that says it is and therefore it is only a guess. However, yes, there is not a callback from CopyFile, but there is from CopyFileEx. Perhaps CopyFileEx can be used; I don't know if it will show progress automatically but it does have a callback that is explicitly for showing a progress bar.
Originally posted by Sam Hobbs
Who says CopyFile is being used? As far as I can tell, you are the only one that says it is and therefore it is only a guess. However, yes, there is not a callback from CopyFile, but there is from CopyFileEx. Perhaps CopyFileEx can be used; I don't know if it will show progress automatically but it does have a callback that is explicitly for showing a progress bar.
I did say "if" he's using CopyFile, but yes you are correct. Anything that will give him a status of the copy in progress will work fine. Still, a thread by itself as suggested, will do nothing to solve the problem, and that was my point.
Having a thread to copy the file won't help with the progress bar
unless some other file copy method is used (CopyFileEx is alot
better than a thread and does provide progress data)
How are you copying the file and what are the source and destinations?
Is the transfer divided into blocks that you have control over the
data flow? Or is it a single call to the OS that returns when the
file transfer has been completed?
How you do the transfer will determine how you will need to
update the progress bar.
With the IE example that you had, the file is being received from
the host in blocks of data. If the size is known, then as each
block is received, update the bytes received and use this in your
progress bar.
[Note: In my original message, I didn't connect the progress bar
to the file copy. Probably should have. Should have guessed that
the file being copied was the reason for the progress bar - Doh!!]
Originally posted by jkw2068
I am using a modal dialog with the progress bar and code with it. It works well. Until the file copy process is complete, I do not want the Parent dialog (I assume this is what is ment by main thread) to gain focus. And it doesn't, if a user clicks on it, it simply shows the "not responding message". This is Ok.
Well..if you are displaying a modal dialog while doing the file copy the parent dialog cannot be used for user input by default. However, if you are experiencing problems updating the progress bar of your modal dialog, it depends where and how you actually do the file copy. If you are doing the file copy within the main thread of the modal dialog, processing of the message queue will be interrupted for the time the copy will take. There are several solutions depending on the actual copy function...so the question would simply be: Where and how do you do the file copy?
Guys. Thanks. Sorry for any frustration if any. I do like the attention and all. Sorry. In fact, I am using CopyFile(). If CopyFileEx() might provide a solution, I'll look into that. If needed, I'll do some reaserch on worker threads. If anyone else has any brain farts. let me know. Thanks
Originally posted by Andreas Masur
nevertheless not the one where you actually do it...
Not sure what is meant by this. Could you explain please?
The CopyFile() function is being used to simply copy the source file selected by the user via the CFileDialog to its destination. Default is the floppy drive.
Looks promising. Wish MSDN had some samples though.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.