I have VB.NET solution targeting .NET 4.0 Client Profile that includes add-ins for Excel and PowerPoint. There is a separate assembly for each, and a third assembly with code that is common to both. So, the common assembly is a dependency of the other two.
Sometimes, but not predictably or reliably, when code in the common assembly opens a MessageBox, it is dismissed automatically without user input. It seems as if the calling assembly (i.e. the Excel add-in) has seized back control of the UI from the common assembly (maybe something to do with threading?), or the calling assembly code just continues executing while the MessageBox is shown.
I have observed this behavior in various and completely separate parts of my solution, and cannot figure out what the problem is. Again, this does not happen all the time, and I cannot reproduce the condition reliably. I am testing this on Windows 8.1 in Office 2013.
Unfortunately, there really isn't any relevant code to post, except:
MessageBox.Show(...)
I am hoping someone can provide some insight into what may be happening here, and provide a fix.
EDIT
After incorporating Hans' suggestion below, my code is now:
MessageBox.Show(New WindowWrapper(handle), [Message], [Caption], MessageBoxButtons.OK, [Icon])
where handle [Integer] = Excel.Application.Hwnd and:
Public Class WindowWrapper
Implements IWin32Window
Private hwnd As IntPtr
Public Sub New(handle As IntPtr)
hwnd = handle
End Sub
Public Sub New(handle As Integer)
hwnd = New IntPtr(handle)
End Sub
Public ReadOnly Property Handle As IntPtr Implements IWin32Window.Handle
Get
Return hwnd
End Get
End Property
End Class
Still having the same problem.
Aucun commentaire:
Enregistrer un commentaire