We started using MATLAB 64 bits in our system and some of our legacy M code uses a custom version of the MSFlexGrid ActiveX component so we decided to write a .Net 64 bit version of it.
The ActiveX is exposed via a Windows Forms host.
[ProgId("FlexiGrid")]
[Guid("88888888-4444-4444-4444-CCCCCCCCCCCC")]
[ClassInterface(ClassInterfaceType.AutoDual)]
[ComVisible(true)]
public partial class GridWinFormsHost : UserControl
{
}
The Windows Form User Control embeds a WPF UserControl via ElementHost.
private IGrid grid;
private void GridWinFormsHostLoad(object sender, System.EventArgs e)
{
var host = new ElementHost { Dock = DockStyle.Fill };
this.grid = new GridView();
host.Child = (GridView)this.grid;
this.Controls.Add(host);
}
The control is successfully registered, visible to MATLAB, and can be instantiated via
actxcontrol('FlexiGrid', Position, Fig, CallBack);
Methods and properties exposed in the GridWinForms are visible and can be get/set/invoked.
However after instantiating the ActiveX we eventually need to call into .Net - in the MATLAB process - via a MEX DLL. The call executes successfully in .Net but the MATLAB process freezes when control returns from .Net. Running the same code without instantiating the ActiveX control succeeds and MATLAB doesn't freeze, which means that instantiating the .Net ActiveX control is probably the cause of MATLAB freezing.
When searching for solutions I came across this MSDN thread in which it is stated: "This problem occurs because the message loop that the Windows Form uses and the message loop that the COM client application provides are different." The original poster concludes that he solved the issue with WPF + MFC but doesn't detail the solution.
I also found this MSDN article which states that: "To make a Windows Form work correctly from a COM client application, you must run the form on a Windows Forms message loop." This is also promising except that the solution focus on creating new Windows Form windows but I need to run a Windows Forms user control embedded in a MATLAB window.
So the issue seems to be related to hosting a managed ActiveX control on an unmanaged application - any ideas?
