The reason is because the OnPaint event of the user control calls several functions which are potentially device-specific, preventing the designer from rendering the control in design view for security reasons
To fix this, a file named DesignTimeAttributes.xmta should be added to the solution containing the custom user control classes. The XMTA file must contain at least the following:
<?xml version="1.0" encoding="utf-16"?>
<Classes xmlns="http://schemas.microsoft.com/VisualStudio/2004/03/SmartDevices/XMTA.xsd">
<Class Name="MyNamespace.MyClass">
<ToolboxBitmap>typeof(Mooseworks.GI.SimpleGraph)</ToolboxBitmap>
<Editor>
<Type>Mooseworks.GI.SimpleGraphEditor, MwSimpleGraphEditor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=15EF1E3443EA1F6B</Type>
<BaseType>System.ComponentModel.ComponentEditor, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089</BaseType>
</Editor>
<DesignTimeVisible>true</DesignTimeVisible>
<DesktopCompatible>true</DesktopCompatible>
</Class>
</Classes>
'DesignTimeVisible' tells the designer to render the control in design view.
'DesktopCompatible' tells the designer to render the control in all cases
If you are using imports of unmanaged dlls or API calls, you should add the
DesktopCompatible attribute with a value of true to the class. You should also
assure that import calls of device specific dlls do not occur while in design mode.
Without the 2 properties the control will not be rendered in design view and will only be showed
as placeholders.
Compiling will creating 2 files e.g. MwSimpleGraph.dll for the classes and MwSimpleGraph.PocketPC.asmmeta.dll
for the XMTA files.
If the control is rendered in PocketPC project design view but not in smartphone design view (or
vice versa), make sure the configuration of the project/solution is set to Any CPU.
Reference: http://www.mooseworkssoftware.com/VS2005%20Control.htm
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.