[CONNECT .NET] DgnTool tool settings

Hi Jon,

Jon Summers said:

What is the purpose of DgnTool.PopulateToolSettings()?

The method is described in MicroStation API documentation for DgnTool Struct: Called to populate the tool tool settings for this tool.

... which I agree is not very descriptive and clear ;-)

But based on return values explanation I guess it's used by engine, when processing the tool object, to check whether the tool will take care about the tool settings (e.g. it attach WinForm or WPF to Tool Settings dialog) or MicroStation shoul load the definition from resources.

Jon Summers said:

Where and how does it find the list of dialog items with which to populate MicroStation's tool settings dialog?

In my opinion a question here is whether it's possible or if it's just a consequence of wrapping native DgnTool class.

My assumption is that it's the same process how XCommands can be utilized in .NET AddIns: It's about how project is compiled to let MicroStation know that rsc file should be loaded together with managed AddIn.

I am not aware of any such example :-(

Jon Summers said:

What does its Boolean return value signify?

true if handled by tool,
false populate the tool settings by command number/command item list id. 

By default (when the method is not overriden), false is returned.

With regards,

  Jan

What does its Boolean return value signify?

Jan Šlegr said:

Populate the tool settings by command number/command item list id

So how is that list ID specified? In a .NET project, where is that list?

It seems to me that DgnTool is an incomplete wrapper around the C++ class.  There are loose ends regarding access to MicroStation resource data (e.g. message lists, dialog item lists) that need to be completed and documented. 

Right now the MstnPlatformNet is not a complete and robust alternative to the MicroStationAPI.  That's disappointing after 2 years as a Release Candidate and subsequently 4 years as a commercial product (MicroStation CONNECT was release in August 2015).

Jon Summers said:

Right now the MstnPlatformNet is not a complete and robust alternative to the MicroStationAPI.

Well, I slightly agree, but more because of it is not documented well and to understand NET API, alwyas MicroStationAPI doc is necessary. Personally I do not expect NET API will be the same as C++ API, but it has to provide the same functionality in terms of basic operations like access to all DGN data, all elements etc. A substantial part of functionality is already available, but not all.

Jon Summers said:

There are loose ends regarding access to MicroStation resource data (e.g. message lists, dialog item lists) that need to be completed and documented. 

Yes, this are is not clear. But I think "XCommands for .NET AddIns" chapter in MicroStationAPI is a place where to start, because it describes how XCommand definition stored in rsc should be included into .NET project.

Regards,

  Jan

FYI. Per this thread, I have asked development review and recommendation on the topic of this thread. We will provide an update as soon as available.

Thank you,
Bob

  the DgnTool.PopulateToolSettings do nothing but return false and is waiting for the derived user tools to override it. However I don't find any tool in the CE internal tools, and SDK examples which override and implement it. The return bool value means whether or not it populate tool settings successfully, but I don't know how to populate it.

  if you just want to design a .Net tool with tool settings, we provide a more preferable way as following, using WPF VMMV manner. Then in the .Net tool, you can access the tool setting properties in your view model flexibly.

1. design your own setting controls in a xaml

<UserControl x:Class="ReplaceContentToolSettings">

...

</UserControl>

2. design your ViewModle to communicate with your tool setting UserControl
   

public class ReplaceContentVm : DisposableViewModelBase

{

...

}

3. bind your view model to the setting controls in your UserControl
   

public partial class ReplaceContentToolSettings : UserControl

{ 

...

internal ReplaceContentVm ViewModel

{

get { return DataContext as ReplaceContentVm; }

set { DataContext = value; }

}

...

}

4. design your ToolSettingsHost

internal class ReplaceContentToolSettingsHost : ToolSettingsHost

{

internal ReplaceContentToolSettings Settings { get; private set; }

internal ReplaceContentToolSettingsHost()

{

Settings = new ReplaceContentToolSettings();

Settings.ViewModel = new ReplaceContentVm();

Content = Settings;//key point to display your setting controls in the tool setting host dialog

SizeToContent = SizeToContent.WidthAndHeight;

Title = Properties.Resources.ToolSettingsTitle_ReplaceContent; 

}

}

5. design your .Net tool and attach ToolSettingsHost

internal class ReplaceContentTool : DgnElementSetTool

{

private ReplaceContentToolSettingsHost SettingsHost { get; set; }

internal ReplaceContentToolSettings Settings { get { return SettingsHost.Settings; } }

private ReplaceContentVm ViewModel { get { return Settings.ViewModel; } }

internal ReplaceContentTool() : base(0, 0)

{

SettingsHost = new ReplaceContentToolSettingsHost();

}

protected override void OnPostInstall()

{

SettingsHost.Attach(PCMAddIn.Instance); // key point to attach the wpf tool setting dialog to your tool and show the dialog

base.OnPostInstall();

}

protected override void OnCleanup()

{ 

SettingsHost.Detach();

SettingsHost.Dispose();

}

...

}

dorlig na said:

I don't find any tool in the CE internal tools, and SDK examples which override and implement it. The return bool value means whether or not it populate tool settings successfully, but I don't know how to populate it

That was my question.

dorlig na said:

If you just want to design a .Net tool with tool settings, we provide a more preferable way as following, using WPF VMMV

Thanks, but that seems excessively convoluted.  I'll wait for an example to show up in the SDK.

Meanwhile, I'll stick with the MicroStationAPI and CommandTable resources: they work well, are documented, and plenty of examples exist.

Jon Summers said:

Thanks, but that seems excessively convoluted. 

I agree that for simple dialogs with just a few items to implement MVVM (Model-View-ViewModel) pattern is just overkill.

On the other hand, MVVM was invented specifically for WPF and it's "core" of WPF stack, so it's great it's supported also in MicroStation API. My experience is when GUI patterns like MVC (quite common), MVP (WinForms) or MVVM (WPF) are used, other styles with no clear functional split become unclear and dirty ;-)

Regards,

  Jan

Jon Summers said:

Thanks, but that seems excessively convoluted. 

I agree that for simple dialogs with just a few items to implement MVVM (Model-View-ViewModel) pattern is just overkill.

On the other hand, MVVM was invented specifically for WPF and it's "core" of WPF stack, so it's great it's supported also in MicroStation API. My experience is when GUI patterns like MVC (quite common), MVP (WinForms) or MVVM (WPF) are used, other styles with no clear functional split become unclear and dirty ;-)

Regards,

  Jan