In an earlier post, I described a method of hosting windows controls that relied on a hidden form on the add-in side that hosted the add-in control, but appeared in a designated area of the host form.
There has been continued interest in using CLR Add-Ins with Windows Form, see the CLR Team’s post Support for Windows Forms in Hosts and Add-Ins.
While it work well graphically, some of the more detailed integration of ALT+ and CTRL+ keys, tab order, etc. did not work entirely well.
Following the advice of the Jesse Kaplan at the Microsoft CLR Add-In team, I have created a new sample using WPF and Crossbow to handle the pseudo-marshalling of the windows control.
This example uses VS2005 and, other than the add-in pipeline itself, it is, from the perspective of the host and add-in developer, a *pure* Windows Forms experience.
>>Download Solution Here (more…)
Please Read
I wrote this initial example before Jesse Kaplan suggested using WPF and Crossbow to implement Windows Control Add-in integration. My newer post here describes this technique. The approach below may still be valid if seen as a *lightweight* technique if the overhead of loading WPF is too great and Hot Key integration is not important.
UI Integration for Add-Ins
With the release of .NET 3.5 Beta 2, Jack Gudenkauf touted the inclusion of the highly requested UI integration feature for System.AddIns, for WPF only. While from a .NET 3.5 perspective it looks attractive to leave Windows Forms behind, the reality is that:
- Microsoft has done an excellent job making new .NET Framework versions additive and pseudo-backwards compatible, thus it has become easier to use the best of the new without needing to fully migrate to the bleeding edge.
- Windows Forms has been around a long time. There’s plenty of legacy code, and perhaps more importantly, legacy developer skills.
Even with an eventually migration to WPF in the near-term future, I needed a Windows Form extensibility story now. (more…)
