WinHTTP and upload progress

[Eduardo-]

Hello all,

I need to handle http requests, GET and POST.
Some are fast, and other involve to download or upload files.
The site use secure conections (https).
I would like to have this operations inside one or more class modules, so I prefer not to use a control like Inet or Winsock.

There are several technologies:
Wininet API.
WinHTTP API.
Msxml2.XMLHTTP object (I don't know much about this one, but seems no to be installed in all systems).
WinHTTPRequest object.
And others like the Winsock API or some curl dll.

I want not to add any dependency file.

WinHTTPRequest seems fine.
But there is a problem: I found no way to notify the upload progress.
The upload is made in a POST call, sending the file as the content body.
The files can be of any size, up to the gigabytes range.
I'm planning to upload the files in chunks, may be of 4 MB (is that a good idea anyway, or is it better to make the chunks larger?).
But I need to show the progress, and 4 MB is still a way too large step to show in the progress.

I think I will have to go for the WinHTTP API, there is a WinHttpSetStatusCallback that can be set.

Do you have any suggestion?

Thanks.

[dilettante]

If you look at WINHTTP_STATUS_CALLBACK function pointer I suspect you will find that it won't help either. If it did there would probably be an associated event, since the events just wrap that callback.

Most HTTP client libraries are not really designed for massive POST requests. That is probably why "request progress" isn't often reported.

[Eduardo-]

If you look at WINHTTP_STATUS_CALLBACK function pointer I suspect you will find that it won't help either. If it did there would probably be an associated event, since the events just wrap that callback.

Most HTTP client libraries are not really designed for massive POST requests. That is probably why "request progress" isn't often reported.

Ah, OK, thank you.

So, basically there is no way to show the upload progress, may be with the Winsock API?

Anyway I'm already thinking in another workaround:
For files smaller than 4 MB, make the chunks of 250 KB.
For files between 4 MB and 16 MB, make the chunks of 1 MB.
For files larger than 16 MB, make the chunks of 4 MB.

It involves sending many upload requests for each file, even for the small ones, and I'm not sure if it is a good idea...

[Ordinary Guy]

Does it really need to be a progress bar? Why not just an animated image like you see on a lot of time consuming operations - the spinning arc you see on Chrome

[Eduardo-]

Does it really need to be a progress bar? Why not just an animated image like you see on a lot of time consuming operations - the spinning arc you see on Chrome

It's not a progress bar. It's a component and it would be an event with a parameter with the percent done or the number of bytes already uploaded.

People would want to know whether it will take a minute or an hour.

[dilettante]

Extensions to HTTP such as WebDAV use HTTP PUT to "write" (upload) to the server and these extensions allow data to be uploaded in chunks with a specified byte range.

So if the server supports WebDAV ranges the client can upload a chunk of data and measure the time it takes to complete. With the chunk size and time it can calculate an estimate to finish uploading, and then chunk the rest of the file piece by piece, updating the estimate/progress as it goes.

It is easy enough to implement a WebDAV client on top of most common client libraries. You'd just have to fall back to crude HTTP POST requests for servers that don't support WebDAV at all, or whole-file PUT for WebDAV servers not supporting range-PUTs. You'd do an HTTP OPTIONS query to determine server capabilities.

So for some servers you could do "upload progress" and others not.


Aside from that you could roll your own HTTP client code on top of TCP. That can be tricky, especially since more and more servers only support HTTPS any more.

[Eduardo-]

Extensions to HTTP such as WebDAV use HTTP PUT to "write" (upload) to the server and these extensions allow data to be uploaded in chunks with a specified byte range.

So if the server supports WebDAV ranges the client can upload a chunk of data and measure the time it takes to complete. With the chunk size and time it can calculate an estimate to finish uploading, and then chunk the rest of the file piece by piece, updating the estimate/progress as it goes.

It is easy enough to implement a WebDAV client on top of most common client libraries. You'd just have to fall back to crude HTTP POST requests for servers that don't support WebDAV at all, or whole-file PUT for WebDAV servers not supporting range-PUTs. You'd do an HTTP OPTIONS query to determine server capabilities.

So for some servers you could do "upload progress" and others not.


Aside from that you could roll your own HTTP client code on top of TCP. That can be tricky, especially since more and more servers only support HTTPS any more.

No, the server doesn't support PUT, only POST, and it only accepts HTTPS conections.

But I can send chunks, I have a parameter to set the offset.
That's my current idea:
For the first 4 MB, to send chunks of 250 KB.
From 4 MB to 16 MB, chunks of 1 MB.
After that, chunks of 4 MB.

I will check how that performs, and if I see problems I'll have to send only chunks of 4 MB or whatever size I decide at the end, without any good information about the upload progress.

I can't believe that something that should be simple (in my opinion) is a PITA.

But it's not the fist time that happen to me that I think that something "is of course a normal operation and there must be a polished mechanism that everybody use" is in fact something very difficult or almost impossible.

Thanks dilettante, you helped me in confirming (so far) that there is no simple way to overcome this issue.

[dilettante]

Yes, some servers support HTTP PATCH (https://tools.ietf.org/html/rfc5789) while others layer their own similar protocols on top of HTTP.

Aside from WebDAV you don't see such things much. You might find something in UrlMon but I don't see one:

HttpSendRequest function

[Eduardo-]

Yes, some servers support HTTP PATCH (https://tools.ietf.org/html/rfc5789) while others layer their own similar protocols on top of HTTP. Aside from WebDAV you don't see such things much.

I wasn't contradicting you.

You might find something in UrlMon but I don't see one:

HttpSendRequest function

Thanks, I'll take a look.

[Eduardo-]

I mean, the server that I'm currently have to work with doesn't offer another way to make uploads than with POST.

Perhaps in the future I have to make the same for other server that accepts PUT request, but this one doesn't allow this (I think it is for security reasons).

[Schmidt]

I mean, the server that I'm currently have to work with doesn't offer another way to make uploads than with POST.

If you have "Scripting-Rights" on the Server in question, you can easily make 3 serverside functions like:
- ServerOpenStream (e.g. returning a unique TempFileName - after creating that file)
- ServerAppendBytesToStream (returning the current FileLength after finishing the action, when no Bytes are passed, the routine just returns the lenght)
- ServerCloseStream (ensuring a final renaming - and returning an SHA-checksum of the serverside-file to compare the result with the clientside)

I'm using something like that with the WinHttp-5.1-Object and classic *.asp Scripts at the serverside
(chunksizes are between 64KB and 256KB per Append-Job, depending on the Upload-speed) -
working very reliable here.

Olaf

[Eduardo-]

Thanks Olaf, but I cannot use Scripting on the server.

I'm already working to test my idea of uploading small chunks at first and bigger after.

But I am also modifying a lot of things, since all work asynchronously and it's very difficult to handle all that in VB6 whithout the ability of creating new threads.
I've been reading a bit about Paul Caton approach of creating threads, but as I understood it cannot be done in an OCX, but it must be an ActiveX exe. And ActiveX exe's can't be deployed using SxS (as I think I've read) so they are ruled out.

So, I'm working with properties like StillExecuting, along with Doevents and setting Timers.
It's not easy to think about all re-entrancy cases that could happen and to handle all properly.

I know all this is off-topic, but could you confirm that (or am I wrong)? Thanks.

PS: I'm talking about many other functions, not only the uploads.

[DEXWERX]

SxS Multithreading can be done using vbRichClient(or Olaf's DirectCOM?) or Krool's VBMThread10

http://www.vbforums.com/showthread.p...Multithreader)

[Schmidt]

Thanks Olaf, but I cannot use Scripting on the server.

What kind of (Web)Server is it, that prevents you from adjusting it to specific needs, when you have to solve
the relatively uncommon problem of uploading huge (Gigabyte-range) files per http-POST commands only.

Is there really no PHP, Python, ASP.NET or anything available at the serverside to you?
If not, what about changing the Provider?

I'm already working to test my idea of uploading small chunks at first and bigger after.

This sounds like the Server-endpoint already supports chunkwise Uploading (appending
chunks to an existing file) - or does it not?

And if the chunks have a small enough buffersize (32KB will need about 100-150msec on a connection which has 2MBit/sec Upload-speed),
you could perform that without having too many "hickups" even in a singlethreaded Application (just checking progress occasionally with a timer).

But I am also modifying a lot of things, since all work asynchronously and it's very difficult to handle all that in VB6 whithout the ability of creating new threads.
I've been reading a bit about Paul Caton approach of creating threads, but as I understood it cannot be done in an OCX, but it must be an ActiveX exe. And ActiveX exe's can't be deployed using SxS (as I think I've read) so they are ruled out.

So, I'm working with properties like StillExecuting, along with Doevents and setting Timers.
It's not easy to think about all re-entrancy cases that could happen and to handle all properly.

As for VB6-threading, there's several approaches to that (the RC5 offering only one of them) -
but in your specific Upload-Scenario I'd consider handling the "huge-files" separately by
"shelled (GUI-less) VB6-Processes" (to keep it simple), which do nothing else than their FileUpload-Job
(reporting their Progress into a simple DB-Table, which you can query from anywhere).

If you have to upload a file with the size of 1GB (on a connection with 2MBit/sec Upload-rate),
such a process would need to run for about 1.5 to 2hours (if there's multiple processes you start parallel,
then the time will increase accordingly of course). So, having these (potentially) huge time-intervals
in mind, separate processes (which are managed from a Client-GUI which might be running - or not),
seems like a good idea.

Don't know what you mean with "StillExecuting" - is the scenario DAO- or ADO-based?
And how is it related to your http-Uploads (are you trying to transfer Recordsets over http)?

A bit more background-info would be nice to read about.

Olaf

[Eduardo-]

As I understand the code that is intended to be executed in another thread must be -already- compiled in a DLL, or can it be executed in my current OCX project?

Anyway now I'm thinking that perhaps threading wouldn't help me much to handle re-entrancy, since I still will have to wait with Doevents until the thread finishes and I'm able to return a result synchronously from the calling function (without locking the UI of the client program).

And it is more or less the same that I'm doing now without threading.

Most of the functions in my interface to the client program are synchronous, but since they involve a web request I cannot make them without Doevents because even when most of the times the web requests return fast, it's not guaranteed, and there are some of them that can take several seconds because they are more complex and involve several requests to the server and require some processing after.

So I have to set flags like:

Do While StillExecutingWhatever
    Sleep 1
    Doevents
Loop
' Now I am able to return the result or to go on with another request

It seems to me now that launching new threads won't help me to avoid that.

Some other jobs are asynchronous, like the uploads and downloads, and they are notified to the client with events. But I have no problem with these (I think), I suppose that WinHTTP already works creating own threads.

I cannot test much at this time because I'm currently refactoring all that I have done so far, in order to handle re-entrancy more properly.

[Eduardo-]

What kind of (Web)Server is it, that prevents you from adjusting it to specific needs,

It's not a server I can have any hand on, it's a web service.

when you have to solve the relatively uncommon problem of uploading huge (Gigabyte-range) files per http-POST commands only.

Uncommon? May be, but every day less uncommon.
I said gigabyte range as the larger case, but for more than 10 MB files it's the same situation since I don't know what connection can have the user (how fast).

I think, due to what I have read, that to use POST is the thend now for security reasons (it is a guess, I don't understand much about it, so don't take it very seriously).

Is there really no PHP, Python, ASP.NET or anything available at the serverside to you?

No.

If not, what about changing the Provider?

I have to do this for this provider now. I don't know how the other providers work but must be more or less the same.

This sounds like the Server-endpoint already supports chunkwise Uploading (appending
chunks to an existing file) - or does it not?

Yes.

And if the chunks have a small enough buffersize (32KB will need about 100-150msec on a connection which has 2MBit/sec Upload-speed),
you could perform that without having too many "hickups" even in a singlethreaded Application (just checking progress occasionally with a timer).

32 KB seem to me too small, that would require many, many web request to be sent for each file. And I think that each web request must have a latency of its own.

My current idea is to start with 250 KB chunks (or buffersize), and to increase the chunk size when "the uploaded file size" is growing.

As for VB6-threading, there's several approaches to that (the RC5 offering only one of them) -
but in your specific Upload-Scenario I'd consider handling the "huge-files" separately by
"shelled (GUI-less) VB6-Processes" (to keep it simple), which do nothing else than their FileUpload-Job
(reporting their Progress into a simple DB-Table, which you can query from anywhere).

If you have to upload a file with the size of 1GB (on a connection with 2MBit/sec Upload-rate),
such a process would need to run for about 1.5 to 2hours (if there's multiple processes you start parallel,
then the time will increase accordingly of course). So, having these (potentially) huge time-intervals
in mind, separate processes (which are managed from a Client-GUI which might be running - or not),
seems like a good idea.

I think that those must be already handled in another thread by the WinHTTP object...

Don't know what you mean with "StillExecuting" - is the scenario DAO- or ADO-based?
And how is it related to your http-Uploads (are you trying to transfer Recordsets over http)?

A bit more background-info would be nice to read about.

Olaf

In the message I just posted (before reading this of yours) I explin a bit better (I hope).

Thanks Olaf.

[Schmidt]

FWIW, here's an example (using WinHttp5.1 at the clientside and vbRichClient.com as a Test-Endpoint):

'into a Class, named cHttpChunks

Option Explicit

Event Progress(ByVal CurPos As Currency, ByVal FileSize As Currency)

Const BaseURL As String = "https://vbRichClient.com/asp/"
 
Function UploadFile(FileName As String, Optional ByVal ChunkSize As Long = 65536) As Boolean
Dim LocalHash As String, TmpFile As String, Strm As cStream, Pos As Long, B() As Byte
    LocalHash = New_c.FSO.GetFileHash(FileName, CALG_SHA1)
    
  TmpFile = RPC(BaseURL & "StreamOpen.asp")
 
  Set Strm = New_c.FSO.OpenFileStream(FileName, STRM_READ Or STRM_SHARE_DENY_NONE)
  Do Until Pos = Strm.GetSize
     RaiseEvent Progress(Pos, Strm.GetSize)
     Strm.SetPosition Pos
     Strm.ReadToByteArr B, ChunkSize
     Pos = RPC(BaseURL & "StreamAppend.asp?TmpFile=" & TmpFile, B)
  Loop
  RaiseEvent Progress(Pos, Strm.GetSize)

  UploadFile = (LocalHash = RPC(BaseURL & "StreamClose.asp?TmpFile=" & TmpFile))
End Function

Public Function RPC(URL As String, Optional Bytes, Optional ByVal TimeOutSec As Long = 10) As String
  With CreateObject("Winhttp.WinHttpRequest.5.1")
    .Open "POST", URL, 1 'async request-mode
    .SetRequestHeader "Content-Type", "application/octet-stream"
    If IsMissing(Bytes) Then .Send Else .Send Bytes
    If .WaitForResponse(TimeOutSec) Then 'we use the appropriate async-wait-method of WinHttp5.1 (not DoEvents)
      Select Case .Status
        Case 200:  RPC = .ResponseText: If InStr(1, RPC, "Error:", 1) Then Err.Raise vbObjectError, , RPC
        Case Else: Err.Raise vbObjectError, , "Error: http-status=" & .Status & " " & .StatusText
      End Select
    Else
      Err.Raise vbObjectError, , "Error: TimeOut of " & TimeOutSec & " reached."
    End If
  End With
End Function

And here the appropriate Code in a little Test-Form:

Option Explicit

Private WithEvents httpChunks As cHttpChunks

Private Sub Form_Click()
  On Error GoTo 1
    Set httpChunks = New cHttpChunks
    New_c.Timing True
    Debug.Print httpChunks.UploadFile("c:\temp\large.zip", 131072), New_c.Timing
1 If Err Then MsgBox Err.Description
End Sub

Private Sub httpChunks_Progress(ByVal CurPos As Currency, ByVal FileSize As Currency)
  Debug.Print Format$(CurPos / FileSize, "Percent")
End Sub

With an about 4MB TestFile I get the following results at my upload-speed of about 2.5MBit/sec (for different ChunkSizes):

22.687sec '32KB  (about 0.18sec per chunk)
15.944sec '64KB  (about 0.26sec per chunk)
15.314sec '128KB (about 0.50sec per chunk)
15.036sec '256KB (about 0.98sec per chunk)

So, for the "total-time" of the 4MByte-TestFile-Upload it will not get all that much faster with a buffer-size
of 256KB - compared to one of 64kByte (the smaller 64kB chunksize updating the progress any 0.25sec or so,
whilst with 256kB chunksize the time between progress-events was about 1sec.

Still don't understand, why one would want to upload larger Files (up to 1GB) with a synchronous RPC-call,
but the example above works this way (as it is currently)...

HTH

Olaf

[Eduardo-]

FWIW, here's an example (using WinHttp5.1 at the clientside and vbRichClient.com as a Test-Endpoint):

Thanks.

    If .WaitForResponse(TimeOutSec) Then 'we use the appropriate async-wait-method of WinHttp5.1 (not DoEvents)st-Form:

My question: In practice what difference is supposed to be between the two ways (DoEvents and .WaitForResponse)?

With an about 4MB TestFile I get the following results at my upload-speed of about 2.5MBit/sec (for different ChunkSizes):

22.687sec '32KB  (about 0.18sec per chunk)
15.944sec '64KB  (about 0.26sec per chunk)
15.314sec '128KB (about 0.50sec per chunk)
15.036sec '256KB (about 0.98sec per chunk)

So, for the "total-time" of the 4MByte-TestFile-Upload it will not get all that much faster with a buffer-size
of 256KB - compared to one of 64kByte (the smaller 64kB chunksize updating the progress any 0.25sec or so,
whilst with 256kB chunksize the time between progress-events was about 1sec.

The progress update every 1 second seems not too bad to me.

Still don't understand, why one would want to upload larger Files (up to 1GB) with a synchronous RPC-call,
but the example above works this way (as it is currently)...

HTH

Olaf

These upload calls will be asynchronous, but other tasks will be synchronous.
(I know I mixed things a bit here)

[xxdoc123]

you can used HttpSendRequestEx InternetWriteFile HttpEndRequest

upload 10.92%
★★★★★★★★★★★★★★★★★★
upload 21.84%
★★★★★★★★★★★★★★★★★★
upload 32.76%
★★★★★★★★★★★★★★★★★★
upload 43.68%
★★★★★★★★★★★★★★★★★★
upload 54.60%
★★★★★★★★★★★★★★★★★★
upload 65.52%
★★★★★★★★★★★★★★★★★★
upload 76.44%
★★★★★★★★★★★★★★★★★★
upload 87.36%
★★★★★★★★★★★★★★★★★★
upload 98.28%
★★★★★★★★★★★★★★★★★★
upload 100%
★★★★★★★★★★★★★★★★★★

★★★★★★★★★★★★★★★★★★
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>IIS 7.5 Detailed Error - 404.0 - Not Found</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana,Arial,Helvetica,sans-serif;background:#CBE1EF;}
code{margin:0;color:#006600;font-size:1.1em;font-weight:bold;}
.config_source code{font-size:.8em;color:#000000;}
pre{margin:0;font-size:1.4em;word-wrap:break-word;}
ul,ol{margin:10px 0 10px 40px;}
ul.first,ol.first{margin-top:5px;}
fieldset{padding:0 15px 10px 15px;}
.summary-container fieldset{padding-bottom:5px;margin-top:4px;}
legend.no-expand-all{padding:2px 15px 4px 10px;margin:0 0 0 -12px;}
legend{color:#333333;padding:4px 15px 4px 10px;margin:4px 0 8px -12px;_margin-top:0px;
border-top:1px solid #EDEDED;border-left:1px solid #EDEDED;border-right:1px solid #969696;
border-bottom:1px solid #969696;background:#E7ECF0;font-weight:bold;font-size:1em;}
a:link,a:visited{color:#007EFF;font-weight:bold;}
a:hover{text-decoration:none;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.4em;margin:10px 0 0 0;color:#CC0000;}
h4{font-size:1.2em;margin:10px 0 5px 0;
}#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS",Verdana,sans-serif;
color:#FFF;background-color:#5C87B2;
}#content{margin:0 0 0 2%;position:relative;}
.summary-container,.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
.config_source{background:#fff5c4;}
.content-container p{margin:0 0 10px 0;
}#details-left{width:35%;float:left;margin-right:2%;
}#details-right{width:63%;float:left;overflow:hidden;
}#server_version{width:96%;_height:1px;min-height:1px;margin:0 0 5px 0;padding:11px 2% 8px 2%;color:#FFFFFF;
background-color:#5A7FA5;border-bottom:1px solid #C1CFDD;border-top:1px solid #4A6C8E;font-weight:normal;
font-size:1em;color:#FFF;text-align:right;
}#server_version p{margin:5px 0;}
table{margin:4px 0 4px 0;width:100%;border:none;}
td,th{vertical-align:top;padding:3px 0;text-align:left;font-weight:bold;border:none;}
th{width:30%;text-align:right;padding-right:2%;font-weight:normal;}
thead th{background-color:#ebebeb;width:25%;
}#details-right th{width:20%;}
table tr.alt td,table tr.alt th{background-color:#ebebeb;}
.highlight-code{color:#CC0000;font-weight:bold;font-style:italic;}
.clear{clear:both;}
.preferred{padding:0 5px 2px 5px;font-weight:normal;background:#006633;color:#FFF;font-size:.8em;}
-->
</style>

</head>
<body>
<div id="header"><h1>Server Error in Application "70877835-VBRICHCLIENT.COM"</h1></div>
<div id="server_version"><p>Internet Information Services 7.5</p></div>
<div id="content">
<div class="content-container">
<fieldset><legend>Error Summary</legend>
<h2>HTTP Error 404.0 - Not Found</h2>
<h3>The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.</h3>
</fieldset>
</div>
<div class="content-container">
<fieldset><legend>Detailed Error Information</legend>
<div id="details-left">
<table border="0" cellpadding="0" cellspacing="0">
<tr class="alt"><th>Module</th><td>IIS Web Core</td></tr>
<tr><th>Notification</th><td>MapRequestHandler</td></tr>
<tr class="alt"><th>Handler</th><td>ASPClassic</td></tr>
<tr><th>Error Code</th><td>0x80070002</td></tr>

</table>
</div>
<div id="details-right">
<table border="0" cellpadding="0" cellspacing="0">
<tr class="alt"><th>Requested URL</th><td>http://vbrichclient.com:80/vbRichClient.com/asp/StreamAppend.asp?TmpFile=5B0D.tmp</td></tr>
<tr><th>Physical Path</th><td>E:\kunden\homepages\44\d438553801\www\vbRichClient.com\vbRichClient.com\asp\StreamAppend.asp</td></tr>
<tr class="alt"><th>Logon Method</th><td>Anonymous</td></tr>
<tr><th>Logon User</th><td>Anonymous</td></tr>
<tr class="alt"><th>Failed Request Tracing Log Directory</th><td><a href="file://faultRequestLogPath">faultRequestLogPath</a></td></tr>
</table>
<div class="clear"></div>
</div>
</fieldset>
</div>
<div class="content-container">
<fieldset><legend>Most likely causes:</legend>
<ul> <li>The directory or file specified does not exist on the Web server.</li> <li>The URL contains a typographical error.</li> <li>A custom filter or module, such as URLScan, restricts access to the file.</li> </ul>
</fieldset>
</div>
<div class="content-container">
<fieldset><legend>Things you can try:</legend>
<ul> <li>Create the content on the Web server.</li> <li>Review the browser URL.</li> <li>Create a tracing rule to track failed requests for this HTTP status code and see which module is calling SetStatus. For more information about creating a tracing rule for failed requests, click <a href="http://go.microsoft.com/fwlink/?LinkID=66439">here</a%3

[Schmidt]

In practice what difference is supposed to be between the two ways (DoEvents and .WaitForResponse)?

There isn't much of a difference - DoEvents just being the "more generic" solution (+ you need to define "your own loop"),
whilst WaitForResponse encapsulates a specific Loop already, which internally probably reacts to the Abort-Method of the httpObj.

Both will keep you App responsive to Win-Messages.

These upload calls will be asynchronous, but other tasks will be synchronous.
(I know I mixed things a bit here)

There are dozens of different ways, to ensure "synchronous-behaviour for asynchronous tasks"
('Sleep 1 + DoEvents' being only one of those "non-GUI-blocking Wait-Functions")...

I'd suggest to open up a new thread though (for the specific problem in question) - when it's more about:
- how to start threads (which process tasks, which would otherwise block the Main-Application)
- how to wait for the finishing of these threads within a function that behaves synchronously on the outside

Olaf