Options to turn off property designer extension

ClientUI includes a designer extension that parses and loads the documentation from the assembly's XML comment file. The process also adds category and other designer-related attributes to each property when the designer is loading the designer for that particular assembly. The combination of these property-related processes may cause the Visual Studio designer to load slower particularly during compile time when the page contains a number of controls from different ClientUI assemblies.

In the case that the property description and categoryare less important in your development,you may choose to turn off the property designer extension to improve the Visual Studio designer loading time. To turn off the property designer extension, please follow the instructions below.

• Open Registry Editor
• Locate HKEY_LOCAL_MACHINE\SOFTWARE\Intersoft Solutions\ClientUI\[InstalledVersion]\Silverlight. For examples, HKEY_LOCAL_MACHINE\SOFTWARE\Intersoft Solutions\ClientUI\5.0.5000\Silverlight
• Add a new string value named "LoadDesignerExt" and set the value to 0.

Note: For x64 operating system, please locate the registry node under the Wow6432Node branch.

Hi Richard,

Currently, the RolesRequired implemented "and" algorithm for the multiple roles, which follows the original implementation in .NET.

However, we realize that this may be not ideal in certain scenarios. Do you have any feedback on the ideal implementation that can support both "and" and "or" algorithm?

Thanks.

In the standard content control and panels, the content moving should work just fine without additional methods. This case is unique only for ContentTransition because it performs animation when the content is changed, which in this case applied to same object. This isn't allowed in WPF since a Freezable object can run only one animation at a time.

The official new build is scheduled to release on mid September. Let me know if you have any questions.

Hi John,

Thank you for your feedback.

The navigation behavior is originally designed that way. That's because when Back navigation occurred and the child content is already filled, the UXFrame will not be reset to empty to avoid re-selection. This gives impression that the back button doesn't perform navigation.

However, upon another evaluation, it seems we'll fix this behavior and enhance it further in final release for consistency purpose.

We will let you know when a new nightly build is available for you to test.

Got it, we'll have it in RTM.

Thanks!