4

We have a VB6 app that shows a .NET WPF modal Window (on the main VB6 thread).

It correctly blocks interaction with the VB6 UI, because the thread blocks at window.ShowDialog().

We also have a timer in VB6. Since the timer ticks on the main thread (Does VB6 Timer control create separate thread?), I would expect that the timer would also be blocked until the modal Window closes. This is not the case. The VB6 timer continues to tick, executing VB6 code on tick, and updating the blocked VB6 UI. Further, once the timer ticks for the first time, the WPF window LOSES its modality - meaning I can click back to the VB6 screen and the WPF window will move behind the VB6 window.

Any idea what's up with this? Is WPF handling WNDPROC messages and then suddenly letting VB6 code executing and for some reason losing IsThreadModal?

Thank you.

Community
  • 1
  • 1
Jeff
  • 35,755
  • 15
  • 108
  • 220
  • It should indeed allow the timer event to get processed, that is to be expected. But the fact that the the modal relationship is broken doesn't sound right. What are you doing to ensure that the WPF window treats the VB6 window as its parent? – tcarvin Sep 30 '14 at 16:15
  • Absolutely nothing. We're doing something like new Window().ShowDiaglog(). Can you explain WHY you'd expect the timer event to get processed if the thread is currently blocked at ShowDialog()? – Jeff Sep 30 '14 at 16:25
  • 1
    Because VB6 timer events have always fired even when a modal dialog is showing. Not knowing the VB6 implementation, I assume it is using `SetTimer` with a callback function pointer, which is called by `DispatchMessage`automatically. – tcarvin Sep 30 '14 at 16:44
  • This is some what similar to processing of WM_PAINT messages. When you drag a modal window and reveal some of the parent form, that parent form repaints itself. If it didn't you'd see ugly ghost images or other weirdness in the window beneath each time you dragged a floating modal window. – tcarvin Sep 30 '14 at 16:48
  • Interesting. So I understand why the timer tick code still fires (which is about what I expected)...but why does the .NET window lose it's modality? – Jeff Sep 30 '14 at 16:58
  • 1
    I don't know. If the .NET form was a Windows Forms form then I would try to pass a `IWin32Window` instance into `ShowDialog` to specify the VB form as the parent, but I don't know the equivalent for WPF. (And even still, I don't know if the `IWin32Window` would work for sure). – tcarvin Sep 30 '14 at 17:13
  • Is the result of the tick (whatever code you are running inside the tick event) causing the .net forms parent window to change its window handle - ie is it closing the .net form's parent window? – Scott Feb 13 '15 at 03:36
  • 1
    Also, have you tried setting the .net windows owner using the WindowInteropHelper class? https://msdn.microsoft.com/en-us/library/ms618134(v=vs.110).aspx – Scott Feb 13 '15 at 03:40

0 Answers0