Way back in the wild west days of VB6, if you wanted a long running utility to ALSO pop up a progress bar, be cancelable, and be nicely encapsulated in a reusable class, you didn’t have a lot of options.

The first was to actually use VB6’s multithreading support via a thread per object ActiveX exe. It worked, but it wasn’t a trivial exercise.

One trick I used on a number of occasions was the modal form callback.

Essentially, it works like this.

• You call into a class to “start” the long running process.
• The class opens an associated progress form, and passes itself to the form.
• The Progress form stores a WithEvents reference to the class, so it can be notified of progress as the class does its work.
• Then, the form shows itself modally, and in the Activate event, calls back into the class to actually start the processing.
• The class then starts it’s long running processing, raising progress events as appropriate, and yielding via DOEVENTS at appropriate times.

It’s a tad complex, to be sure, but certainly less complex than some of the alternatives and it still yields a nicely responsive UI that the user can easily cancel out of.

Fast forward to today. I had a similar requirement for a little VB.NET utility, so I figured, what the hey, might as well use that old trick.

After a bit of coding, I run the app and am rewarded with this:

Huh? I wasn’t “Attempting to call into managed code without transitioning out first.” Heck, there wasn’t even any API calls in this mix, Much less “Low Level extensibility points”!

Of course, the VS help for this message proved utterly useless, so I start googling.

Equally useless. Surely, I’m not the only guy out there to get this treat, right?

Anyway, eventually, I decided that maybe, just maybe, something about the reentrancy into the class from a modal dialog was causing the problem, though I still don’t have concrete proof of that.

I reworked the class to cooperate with the BackgroundWorker component (a nifty little bit of new .NET goodness), and everything’s back on track.

The only bit of nastiness left is that my background worker class raises several events, which my progress form monitors and presents, but doing anything within those events directly resulted in an exception about accessing UI objects from a thread other than the one they were created on.

The VS Help was helpful for this though, and adding code like this to the event handlers…

   Delegate Sub ScanningFileCallback(ByVal FileName As String, ByVal Count As Integer)
   Private WithEvents MyClass As MyClass

   Private Sub MyClass_ScanningFile(ByVal FileName As String, ByVal Count As Integer) Handles MyClass.ScanningFile
      If Me.prgProgress.InvokeRequired Then
         Dim d As New ScanningFileCallback(AddressOf MyClass_ScanningFile)
         Me.Invoke(d, New Object() {FileName, Count})
      Else
         me.prgProgress.Maximum = MyClass.FileCount
         me.prgProgress.Value = Count
      End If
   End Sub

worked around that problem nicely, although it’d be nice if the background worker class could somehow handle this transition itself. Hmmm….