Using Line tool for a reference in the API

[AGGilliam]

Background:

I'm currently working on a tool that places components in a line,  but because it's an Addin, it doesn't produce any temporary dimensions or ortho snaps. I'm trying to find a workaround for this so the user can easily measure out the distance without having to draw a line then going into the custom tool.

Question:

I know I can use a postable command to access the line tool, but is there a way to retrieve that line afterwards for use in placing the components? Open to any other workarounds as well.

[RPTHOMAS108 · Accepted solution]

Posting a command for this purpose seems awkward since it occurs after the API context finishes and you would have to find a way to get back into the context.

How about using a dynamic model updater so that when a line of a given category is created it is automatically converted into your spaced components? You choose the sub category name of line to look for and when such a thing is added you are given details of it to turn into something else.

The main benefit being that it would be ever present working seemlessly and you wouldn't even have to invoke a command. Perhaps also as the curve is created you can prompt for options etc. i.e. what component to use centres etc. However I believe that largely DMU is meant to be non user interactive.

[AGGilliam]

That's a great idea! How would I specify the scenario in which it would be triggered though? Are you saying just look for a specific line type as in Model Line vs Detail Line or would there be a way to be a bit more specific than that? For example, if someone wanted to draw a Model Line without the DMU being triggered.

[RPTHOMAS108]

You have to work with setting up the triggers in terms of what is available to use i.e. you would likely use:

Element.GetChangeTypeElementAddition for change type and use a filter that returns main category of Lines. I don't believe you can get as granular as sub category at that stage (in terms of limiting when the updater is called).

So when implementing the Execute method of the IUpdater interface you would then get the ElementIds added via UpdaterData.GetAddedElementIds and then investigate the sub category of the lines returned at that stage to determine if you want to do anything with them or just skip out of the process. The code for this should be as brief as possible, expanding some elements to get the subcategory of the lines shouldn't be noticeable in terms of performance.

I don't believe there would be any advantage of using model lines rather than detail Lines for this task since you are working in a view and the line is ultimately going to be replaced. So in terms of IUpdater.ChangePriority you would probably return either DetailComponents or Annotations. I have a remembrance that detail lines fall under ChangePriority.DetailComponents rather than annotations. These two priorities are at the end of the queue in terms when all updaters can execute.