Question

According to the answers to another question, the VB user interface cannot be updated if the thread that created it is busy: hence why big computational jobs usually have to go in a background task.

Here’s what’s mystifying then. I have the following code. It’s called over in-process COM, like this

1. client calls showform()
2. client does loads of work, freezing up its own UI in the process
3. client finishes work, returns to updating its own UI

At step 2, the VB form is there but frozen – you can’t interact with it. At step 3, the VB form becomes usable. But why is this? Surely the thread of execution has returned to the client? If the client is somehow handling events for the form, by what magic did it know what events to handle and where to send them?

<ComClass(ComClass1.ClassId, ComClass1.InterfaceId, ComClass1.EventsId)> _
Public Class ComClass1

  Public Sub New()
      MyBase.New()
  End Sub

  Private f1 As Form1

  Public Sub showform()
      f1 = New Form1()
      f1.Show()
  End Sub

End Class

Answer 1

The magic you speak of is the basis of Windows programming. My answer to your previous question explains why and how you can fix this. When making a COM call the client application just imports your procedure into their application. Whether they create a form by typing the code themselves or whether they create a form using code you have typed it doesn’t change the nature of the object/owner relationship. A COM call to your showForm will still make f1 belong to the thread which made the call (client UI thread). The window handle for that window will still be the responsibility of the UI thread that created it (the client).

Creating a form only makes a mailbox (window handle). A UI thread is a mailman (message pumping loop). You aren’t providing the client with a new mailman, just a new object with a mailbox. When the client program creates the window by making the COM call to your procedure it (the client UI thread) takes responsibility for delivering messages to the new form’s mailbox (registers its window handle with the main UI thread). Their mailman still needs to send you messages to make your visual objects work. If he is busy trying to calculate pi to a trillion decimal places then your object freezes like everything else on his mail route.