Subclass a feature (like Hole for example)

[eric23NGD]

Is there a way to subclass (any OO folks out there?) a feature?

My example is the Hole feature.  It does exactly what I want, but I have some standard hole configurations that I want to use for various pieces of hardware in my inventory. 

So, make an addin that is just a hole with, say ,

Counterbore

10mm diameter head

2mm tall head

20mm total length

clearance (no threads)

flat point

size M3

Fit Normal

So, kinda sorta a Macro  for a specific hole stetting.

Anyway to do this?  Am I making sense?  I don't want to re-implement hole...

[BrianEkins]

You can't derive from any of the Fusion classes.  What is possible is to create your own command dialog for your hole type.  It would be much simpler and have fewer options than the standard Hole command.  The command would gather the needed input and then use the API to create a standard hole using this input.  With the upcoming custom feature functionality, you can even wrap the hole as a custom feature which will allow you to control which parameters are available in the Parameters dialog and when the user edits your hole, it will display your dialog so they'll have the same limitations during edit that they had when they created the hole.

[eric23NGD]

Yeah, I get all that. I know that.  I am a programmer. Since waaaaay, waaaay back.

Talk to your Fusion developers. They get sub classing. In the programming world, it is brilliant. Perhaps it has not percolated to the engineering world, but it is seriously, seriously, what smart people do these days. Engineers should too. Brilliant is kinda universal.

Probably not that much work for them. Makes things cake-walk for the rest of us.

Derive (your vocabulary - tell the programmers SUB CLASS) is powerful mojo. I "derive"" the Hole, preset some of the parameters, hide some of the others, everything else works. AND when "hole" the feature is upgraded - for whatever reason - I inherit that auto-magically. Nice.

10 lines of code - python or c++ . Easy peasy. Your way, is the long and fussy and unmaintainable.

You could open the door to all kinds of wild and crazy new stuff. Talk to the programmers. They get it. Seriously!

Just the opinion of somebody using the free version. Not like I didn't get my money's worth.

Cheers!

[nnikbin]

In some open architecture programs, like 3ds Max, 3rd party developers use the same API for developing plugins as the internal developers use for developing most of the native plugins and tools shipped with the product. But I think Fusion 360 API has a different story which @BrianEkins as the designer of Fusion 360 API knows about it better than anybody. I think Fusion 360 API hides many internal complexities from 3rd party developers and the native commands are builth with a different access level to underlying data of the program. So I guess one of the obstacles to subclassing Fusion 360 native commands is that it is not possible to bridge between these two systems.

[BrianEkins]

@nnikbin is correct.  Especially with features, there's a lot more going on under the hood than you would think and the API is doing a lot to expose it in a way that mimics the UI and makes some sense.  There is also have the restriction of needing to support multiple languages (C++ and Python for now) and they have different capabilities and approaches to object-oriented programming.