[CONNECT Update 16 .NET] Questions about MstnPlatformNet and WPF

Question

The MstnPlatformNET help doc mentions several classes in namespace Bentley.MstnPlatformNET.WPF . The purpose of some classes is self-evident, but many defy immediate understanding. The two WPF examples don't reveal a lot. Here are a few questions about Bentley.MstnPlatformNET.WPF ... Questions about MstnPlatformNet and WPF WpfAddIn Class I can see that is an inheritable base class for our AddIns , but what does it do? Neither of the WPF example AddIns inherit from that class. MstnRelayCommand Inherits from RelayCommand

Robert Hook · Accepted Answer

Hi Jon Summers , 
 As you observed and Jan mentioned WpfAddin class is not typically used/required except when there is a need to apply application specific WpfTheme. I could not locate any such code being used in MicroStation or, other applications for that matter. 
 The best summary information I could extrapolate would be the following: 
 The WpfAddin class is available tor an MDL application to ensure it is properly registered using our domain and app scheme (via LoadAddIn method) thereby supplying a reference module (typically self) from which all components would inherit the application's WpfTheme and ThemeStyleAttribute. If needed and not registered/implemented properly WpfThemes have the potential to affect other WPF applications. So if you need to troubleshoot style issues, start by removing any [ThemeStyle] attributes and/or <Style> elements within your application, then incrementally add each back to reveal if a specific style may be causing issues. 
 Both MstnRelayCommand (used behind Ribbon Button behaviors and actions) and HostedControl (lowest layer between our WPF implementation and Windows Controls layer) and should be considered internal classes to MicroStation; since currently it difficult to discern and (clearly) publish .NET internal vs. external assembly scope; e.g. what is for public consumption vs internal use. In order to provide that level of clarity we could need to review and move all (intended) "internal" assemblies into an easily identifiable location; e.g. ..\Assemblies\System\... Let me know; possibly by task/functionality you are trying to achieve; if we can provide more information. 
 HTH, Bob

Jan Šlegr · Answer

Hi Jon, 
 a few more notes about the discussed classes (and to the topic in general): 
 Jon Summers said: but many defy immediate understanding. 
 A question is whether all classes must be documented (because some can be public only because of implementation requirements) and whether it's necessary to know all classes in every assembly. 
 In my opinion, especially in the case of WPF, it's fine to use (only) classes, shown in SDK examples, and standard classes and concepts, used in WPF ecosystem and/or in particular MVVM framework or concept. Probably, when you would like go beyond pre-cooked solution and to implement custom MVVM pattern, or to add own WPF control, deeper knowledge maybe required, but I guess even in such case, WPF API will be used primarily. 
 Jon Summers said: WpfAddIn Class 
 Well, because it's not used, it's probably not necessary ;-) 
 As you can simply find out, this class adds several extra methods, directly related to WPF themes management. There are probably not many reason why normal addin should accesses and manages WPF theme(s), when behavior is inherited from parent WPF automatically. 
 Jon Summers said: Neither of the WPF example AddIns inherit from that class. 
 I see that even only several MicroStation tools are based on this class. They are typically a kind of "GUI special" ones, like SplashScreen, ribbon, VUE and other rendering related modules etc. So, the main reason there is maybe to able to define own theme, when standard one does not cover all functionality, required by dialog(s) with special content. 
 Jon Summers said: What does MstnRelayCommand provide beyond the .NET RelayCommand<Object> ? 
 I think it's not important to what MstnRelayCommand provides beyond any other similar class, but that it - together with other classes - represents simple MVVM framework, ready to be used by MicroStation developers. 
 As written in documentation: It's not mandatory to use it, you can reference and use any other MVVM framework available for WPF (or, I would add, when anybody is so bad developer and likes to write dirty code, to do not use MVVM at all ;-) 
 Jon Summers said: Where should we use a HostedControl ? Neither of the WPF examples demonstrate the use of that class. 
 HostedControl inherits standard WPF ContentControl, so it's clear the class represents implementation of WPF control. So , the answer is "never, as long as you do not decide to implement own integration of WPF into MicroStation ;-) 
 Further analysis (just to simple check an inheritance graph) shows, that representatives of HostedControl are pre-cooked classes like DockableToolbar, DockableWindow, ToolSettingsHost etc. So it's returns me to my first answer, that there is often no reason to know functionality of all public classes, because they may be public and part of API only because of implementation requirements, where they define a specific functionality, used in different places in API. 
 With regards, 
 Jan

[CONNECT Update 16 .NET] Questions about MstnPlatformNet and WPF

Questions about MstnPlatformNet and WPF

WpfAddIn Class

MstnRelayCommand Inherits from RelayCommand<Object>

HostedControl Class

Top Replies

WpfAddIn Class