
Signature
Carlos J. Quintero
MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
> I've been wrestling with this one for a while now.
>
[quoted text clipped - 41 lines]
>
> --M
> Non modal forms of .NET don4t work well with VS.NET (focus problems
> and others). The only (recommended) way to have non-modal forms in
> VS.NET is through toolwindows, created with CreateToolWindow function
> and using an ActiveX shim control to host your .NET user control. See
> the Files section of http://groups.yahoo.com/group/vsnetaddin/ about
> shim controls.
Hmm. Okay, then, according to the readme in VSUserControlHost.zip:
"Because .NET UserControls are not ActiveX controls, a
UserControl cannot be directly hosted on a tool window."
The question I'd then have is, why can a UserControl not be hosted
directly on a tool window? (Or is that just another Microsoftism that
I'll have to learn to live without an explanation for?)
Regardless, I found a workaround. I'd been trying to have my builder
code spawn off a non-modal dialog. My workaround was to create the
dialog as a modal dialog, then have the dialog spawn the builder code.
That seems to do almost exactly what I want. I don't seem to be able
to set the focus to the dialog with the mouse, but it stays on top of
the IDE and that's what's important in this case.
Oh, and thanks. :)
--M
Carlos J. Quintero [.NET MVP] - 16 Feb 2005 16:34 GMT
> "Because .NET UserControls are not ActiveX controls, a UserControl cannot
> be directly hosted on a tool window."
> The question I'd then have is, why can a UserControl not be hosted
> directly on a tool window? (Or is that just another Microsoftism that
> I'll have to learn to live without an explanation for?)
Don´t get me started about the damned shim controls...

Signature
Carlos J. Quintero
MZ-Tools 4.0: Productivity add-ins for Visual Studio .NET
You can code, design and document much faster.
http://www.mztools.com
Matthew Korth - 16 Feb 2005 18:42 GMT
> > "Because .NET UserControls are not ActiveX controls, a UserControl
> > cannot be directly hosted on a tool window."
[quoted text clipped - 3 lines]
>
> Don4t get me started about the damned shim controls...
Ah. One of THOSE things. :)
"Ed Dore [MSFT]" - 16 Feb 2005 21:34 GMT
Heh heh, I think I like Carlos's answer better<g>.
There isn't a good interop story with respect to hosting .net
controls/winforms, in native Win32 applications. The VS .Net IDE is almost
completely a creature of C++, ATL, and COM. This is primarily due to the
fact that when the IDE was initially created, large portions of .NET were
still on a white board.
The good news is that for VS 2005 (aka Whidbey) that shim control will be
history.
One other suggestion would be to kick off a 2nd thread that displayed your
modeless dialog, and use PInvoke to call the SetParent API to parent the
dialog on the main IDE window. That could be a bit tricky though, as you'll
have to find a way to get the HWND of the main IDE window. It isn't exposed
through the VS automation stuff, so you'd probably have to use some
additional Win32 API's like FindWindow, GetCurrentProcess, and
GetWindowProcessID to retrieve the HWND. You'd also need to come up with a
way to communicate across the thread boundary, via messaging or mashalling
interfaces.
Sincerely,
Ed Dore [MSFT]
This post is 'AS IS' with no warranties, and confers no rights.
Matthew Korth - 18 Feb 2005 17:16 GMT
> One other suggestion would be to kick off a 2nd thread that displayed
> your modeless dialog, and use PInvoke to call the SetParent API to
[quoted text clipped - 5 lines]
> also need to come up with a way to communicate across the thread
> boundary, via messaging or mashalling interfaces.
I tried creating the dialog in a separate thread, but as I've never
done multithreaded programming before I'm pretty sure I screwed it up.
:P
And if the HWND for the main IDE window isn't exposed, what's
EnvDTE.MainWindow.HWnd?