Link to home
Start Free TrialLog in
Avatar of h20upto
h20upto

asked on

Progress Bars on File Transfer Part 2...

I'm using VB5 under Win95 and NT 4.0

I've already asked this question here once but the answer wasn't very responsive so I'm going to try again.

I would like to find out the most effcient way to to
have a VB5 progress bar show the progress of a file copy from one drive to another or to an LPT port (Actually a Novell Print Que).

I'm familiar with the API Calls:
LZCopy and SHFileOperation
But for reasons I won't go into I do NOT want to use
these in my program. I would prefer to use the VB5
progress bar format. Or something simular to the progress
bars you see in most setup programs during file copies.

I'm trying to figure out how to determine the amount copied
in the equation:

 progressbar.value = amount copied / total file size

I've thought reading the file as a binary in chucks and then
writting back out in chunks so I can meter the progress but this seems very inefficient because in many cases the files I will be tranfering will be quite large. 100K to 500K or so.

Progress bars during file transfers is a VERY common occurence in a LOT of other programs. I was just wondering
what common practice was for this proceedure.

If possible a code snippet would be VERY helpful.

Thanks VERY much for all your help. This Exchange is
a great idea and I plan to continue using it.
Avatar of vorlon
vorlon

h20upto,
What you are asking and what you are describing as other setup applications is different. Let me explain:

You want to be able to copy files yourself so that you can monitor each byte that gets copied therefore providing a percentage from say 100 bytes copied out of 1000 bytes total giving you 10%.

However, other setup applications don't work this way. They copy the entire file and then provide the percentage as in: 2 files copied totaling 5k out of 10 files total totaling 100k giving you  5%. This is why it takes setup programs to install the first 10% in 10 minutes while the last 90% takes up another 10 minues; the first 10% of files is actuall 80%-90% of the data.

You have to decide whether you're going to report the percentage as the percentage of data copied or the percentage of files copied. Most programs just tell you the percentage but we as coders can tell why the percentages are different in respect to the time it takes to copy them.

Given this information, if you decide to report on the percentage like other programs, then you can simple get the file size of all the files you have to copy and as you copy one file at a time, show the percentage of the total. (If you need help with this let me know...)

If you choose the other method, then you'll have to copy the files yourself (openning the file in binary..., etc). I've used some printing tools before that gave you callback functions for the printing routines to give you the printing status. Perhaps there are tools that do the same for file operations. Sorry I cannot be of any help on this part.

Hope this helps.
Avatar of h20upto

ASKER

Thanks very much for your response.

I can see I wasn't very clear in my question and I understand exactly what you mean. I should have made it clear that I am only interested in metering progress of the file transfer on a file by file basis. Many times only one file is being copied. But as I have said that file may be quite large. 200K to 1MB or more.

Let me give you a real quick background. I'm an engineer for a consulting company. We work with several different CAD design packages (AutoCAD, MicroStation, etc.). To produce output, one of our options is to copy generated plot files to a laser plotter on a Novell netware que. The problem is that the laser plotter requires different setup codes for different CAD packages. I've written a small program to send the appropriate ESC code sequences to setup the plotter followed by the actual plot file. These plot files are often very large. 90% of the time there is only one plot file being sent. The program actually already works.

 The problem I'm having is sometimes it takes so long for the file to copy that the program appears to have stopped working(even though it hasn't) and users are shutting down the task in frustration. The program is crying for a little file copy progress bar to clam the users down, and give them an idea of how long it will take. But I definitely don't want to make the problem worse by adding code that is inefficient.

 You mentioned that my own binary copy routine was about the only thing I could do. Do you think you could help me with a brief example of something you've done or seen that will work for my situation but is still VERY fast?

Thanks VERY much!


h20upto,
Can you provide me with a bit of environment background (OS, VB version) ?.

The software I used before was a graphics package. I used it with Pascal in a DOS environment. However, I think it was compatible with other environments. Pretty much, it encompassed declaring print driver assignments. You simply told it what printer you wanted to print (not generic at all like in windows). Then you after all that messy stuff you have to do when printing manually, you told it to print by passing a pointer to the print buffer in memory. You also proviced it with an address of a function (pointer to a function in C or procedure types in Pascal) that would act as a callback function. This function would simply be called with the total number of bytes to print and the current byte currently sent to the printer. It was simply a status callback function... I could try and find out where we got the package from in case you're interested.

In the mean time, I'll try to come up with something you can use. That is why I need to know which environment you're using...

P.S.: I'm also a contracter...

Vorlon
h20upto,
OOPS.

    "I'm using VB5 under Win95 and NT 4.0 "

Too early in the morning...
Vorlon
I have written in basic the very routine you describe.  It opens the files as binary, and writes large chunks to the output file, providing high speed file copy with a progress meter.  I also have a few DOS utilities that will do the same thing for you, and you don't have to write a thing.  If interested, email me at cymbolic@aol.com
Avatar of h20upto

ASKER

Hmm you kind of lost me with your last responce. I'm sure what is has to do with my situatuion really. I want to try to use VB5 to do this. I guess this must be a little more complex than I thought. I thought what I wanted to do was fairly common. Thanks for your help. I guess I'll just leave the program as is for now. And maybe I'll come across someone who has done this before.

Thanks again for you Help!!
why dont you get the filesize and open the file in random file access and pass the file to the other location by writing it?.  Using this way you can indicate changes in progress bar as often as you want, or maybe use the w95 file copy animation.

it will slow you down a little bit, but it wont be noticed, because your users will see movement, instead of an etern hourglass.

Should i send you the procedure?

Avatar of h20upto

ASKER

Yes I would olx, Thanks very much
Allow me to send you the code for your answer, unlock the answer and i will send you that.  

Thanks.
Avatar of h20upto

ASKER

How do I unlock the Answer??
Grade it an F
The current answer is from vorlon, grade it with an F, i am preparing the code for you now.
i don't see the problem...
why opening binary file is inefficent?
this should work just fine...
MSIMAN
ASKER CERTIFIED SOLUTION
Avatar of DavidMartin
DavidMartin

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Bought This Question.