0

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
Community
  • 1
  • 1
Sideshow Bob
  • 4,566
  • 5
  • 42
  • 79

2 Answers2

2

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.

J...
  • 30,968
  • 6
  • 66
  • 143
  • Ha ha, I like the image of a mailman distracted by calculating pi :) So, tell me if this is right: the client thread has a message loop. Form1 contains code which calls the windows API and registers the client thread as responsible for the window. Windows later decides that Form1 needs redrawing, so it adds this request to the client's message queue. The client gets this message but what does it do with it? Does it call back to the API asking where the actual redraw code is? – Sideshow Bob Jun 23 '12 at 13:17
  • The main UI thread (which runs the message loop) would get a `WM_PAINT` or some such message from Windows. This, when processed, would have the main thread decide which of the components and controls under its watch would need redrawing (ie: which are visible, etc) and would set about the task of calling all of the `Paint` event handlers for those components. Each bit holds the code which describes what to do with itself when painting is required but that code is executed by the main UI thread in response to a message from Windows. – J... Jun 23 '12 at 16:38
0

check the form.load event. the form loads and runs code... that is where it freezes.

Naval
  • 344
  • 2
  • 7