[CONNECT .NET] DgnTool tool name

Hi Jon,

Jon Summers said:

Perversely, there's DgnTool.GetToolName, but no method that I see that implements SetToolName.

I have not enough time do any real test, but in my opinion there is no reason to have anything like SetToolName. To think in terms of setting the object feature from outside is more "C procedural style" where code control through functions other code, but in OOP the code should be (but often it's not ;-) about sending messages what object should do.

Jon Summers said:

How do I set the tool name of a primitive tool that ultimately inherits from DgnTool?

Override GetToolName method by your own. When anybody from outside (including MicroStation engine processing your tool object) will be interested in to know the tool name, it will call your method and not base one (that returns null).

protected override string GetToolName() => "My tool";

BTW This example is wrong in fact, because it does not support localization through mui files...

With regards,

  Jan

Jan Šlegr said:

there is no reason to have anything like SetToolName

I don't understand your comment.

Both VBA and C++ allow us to set a primitive tool name...

• VBA: CommandState.CommandName = "My Command"
• C++: DgnTool (int toolId, int toolPrompt) where toolId is a message list index to provide the tool name

  The name is useful because it appears, for example, in MicroStation's Edit|Undo/Redo menu.  If DgnTool.SetToolName doesn't exist, is there another way to specify the tool name?

Jon Summers said:

I don't understand your comment.

Ok, will try to explain it a bit more ;-)

Jon Summers said:

VBA: CommandState.CommandName = "My Command"

VBA implementation is not relevant for this discussion at all, API structure and its overall philosophy is different. Moreover this approach breaks OOP best practices (encapsulation) in my opinion.

Jon Summers said:

C++: DgnTool (int toolId, int toolPrompt) where toolId is a message list index to provide the tool name

It exists also in NET implementation, but as discussed in another thread, now it's not clear whether it can be used (and how) or it's not functional.

Jon Summers said:

The name is useful because it appears, for example, in MicroStation's Edit|Undo/Redo menu.

I wrote nothing about it's not important and useful to provide the tool name to be presented in MicroStation GUI.

Jon Summers said:

If DgnTool.SetToolName doesn't exist, is there another way to specify the tool name?

I answered it already in my first post: Override GetToolName with your own implementation and return the tool name.

With regards,

  Jan

Hi Jon Summers,

Sorry I have been unable to respond sooner.  Jan is correct and wrt this post and your other (newer) post, I hope this can help until we have (1) .NET example we can provide (in an SDK update).

There is a delivered example that shows how to override the GetToolName as Jan recommended; since DgnTool provides no SetToolName method.

Elements\ManagedToolsExample\SolidUtilClassExamples.cs:26:        protected override string GetToolName () { return "SolidUtil Tool"; }

As for your other post (populating .NET DgnTool ToolSettings) that will take some additional input from development to hopefully provide a usable code snip.  I will update you on the status/response once received.

For now and fwiw the code will most likely be based on overriding:

include\DgnView\DgnTool.h:344:virtual bool _PopulateToolSettings () {return false;}

HTH,
Bob

Hi Jon,

I am not sure if the below question is same as yours?

https://communities.bentley.com/communities/other_communities/chinafirst/f/microstation-projectwise/146737/ms-ce-c-cli/521642#521642

Robert Hook said:

fwiw the code will most likely be based on overriding _PopulateToolSettings

I'm sure you're right.  However, a MicroStationAPI tool doesn't really need to use that call.  The native framework knows to load the Tool Settings dialog with an item list identified by the tool's command ID.

Yongan.Fu said:

I am not sure if the below question is same as yours?
MessageCenter.Instance.StatusCommand = "My Cmd";

No: that fixes the symptom but not the underlying problem.  Consider the VBA CommandState.CommandName read/write property.  It tells the primitive state engine to use that name when referring to the current command.  That's how the command name is entered into the undo/redo buffer queue.

Jon Summers said:

No: that fixes the symptom but not the underlying problem.  Consider the VBA CommandState.CommandName read/write property.  It tells the primitive state engine to use that name when referring to the current command.  That's how the command name is entered into the under buffer queue.

How about overriding GetToolName() method in DgnTool class?

   class DgnToolDemo : DgnElementSetTool
    {
        protected override string GetToolName()
        {
            return "MyTool";
        }
        public override StatusInt OnElementModify(Element element)
        {
            return StatusInt.Error;
        }
        ...
    }

Jon Summers said:

No: that fixes the symptom but not the underlying problem.  Consider the VBA CommandState.CommandName read/write property.  It tells the primitive state engine to use that name when referring to the current command.  That's how the command name is entered into the under buffer queue.

How about overriding GetToolName() method in DgnTool class?

   class DgnToolDemo : DgnElementSetTool
    {
        protected override string GetToolName()
        {
            return "MyTool";
        }
        public override StatusInt OnElementModify(Element element)
        {
            return StatusInt.Error;
        }
        ...
    }