We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


Progress Bars on File Transfer Part 2...

h20upto asked
Medium Priority
Last Modified: 2012-08-14
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.
Watch Question

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.


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!

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



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

Too early in the morning...

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


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?


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.  



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...
Try this, you'll need to work on it a bit to fit your needs, but not much...

' ------------------------------------------------------------------------
' Sub   - Copy file from sSrcFile to sDestFile and update
'         status panel.
'         (I know the FileCopy() function would be quicker
'         but this is prettier)
' Params    sSrcFile    - source file to copy
'           sDestFile   - destination of file
'           lTotalLen   - Total length of file to copy
'           lBlock      - Number of blocks copied so far
' ------------------------------------------------------------------------
Sub CopyFile (sSrcFile As String, sDestFile As String, lTotalLen As Long, lBlock As Long)
    Dim sBuffer As String
    Dim fSrc As Integer
    Dim fDest As Integer
    Dim bFinished As Integer
    Dim iStatus As Integer
    Dim lLOF As Long
    ' Open source and destination files
    fSrc = FreeFile
    Open sSrcFile For Binary Access Read As fSrc
    ' Delete the existing copy of the file
    If Dir$(sDestFile) <> "" Then
        Kill sDestFile
    End If
    fDest = FreeFile
    Open sDestFile For Binary Access Write As fDest
    ' Copy file
    bFinished = False
    lLOF = LOF(fSrc)
    Do While Not bFinished
        ' Setup buffer length
        If (lLOF - Loc(fSrc)) > BUFF_LEN Then
            ' Read BUFF_LEN bytes from file
            sBuffer = String$(BUFF_LEN, 0)
            ' Read number of bytes left in file
            sBuffer = String$(LOF(fSrc) - Loc(fSrc), 0)
            bFinished = True
        End If
        ' Read file
        Get fSrc, , sBuffer
        ' Write file
        Put fDest, , sBuffer
        ' Update status
        lBlock = lBlock + 1
        iStatus = (lBlock * BUFF_LEN / lTotalLen) * 100
        ' Only update the status if it has changed
        If iStatus <> pnlStatus.FloodPercent Then
            pnlStatus.FloodPercent = iStatus
        End If
    ' Close the source and destination files
    Close fSrc
    Close fDest
End Sub

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Bought This Question.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.