Custom Derived Object of Native Inventor Object

[J-Camper]

I'm curious to know if anyone has tried to create a custom derived class of and Inventor object in a vb.net application?  I'm a self taught programmer and I don't really know where I would start for this, so I'm hoping for some insight.

My current thought was if I would make a custom object derived from a PartDocument Object. 

[WCrihfield]

Hi @J-Camper.  As you may know, I am also a self-taught programmer (other than CNC stuff), but I have created several relatively basic Classes before, when needed.  I believe the two main starting points would be the Inherits statement, and/or the Implements statement.  The Inherits statement is probably more what you are looking for though (Inheritance Basics ).  Objects in Inventor's API (and iLogic API) can be a bit odd, because it seems like most of them are actually an Interface type object, instead of an instance of a Class (Link, Link, Link).  The PartDocument is an Interface, which is derived from the Document which is also an Interface.  You may not see this in the online help documentation, but you can see it by typing in these Types in an iLogic rule window, and looking at the Intellisense tips about those Types.  The Implements statement is more for, if you already have an Interface containing most of the skeleton of what you want, this is a way of insisting that this new Type contains all the skeletal aspects of that Interface, but then you must include the code defining all that stuff within your new Type.  The Inherits path seems simpler...no need to include code for all the same stuff that was in the parent Type, at least I do not think so, for the most part.  But I believe you can expand upon them, if you wanted to.

[Frederick_Law]

What do you want with the new class?

That new "object" will only work with your program.

Other without your program will not be able to use the file.

For example PartDocument is a derived of Document object.

It add more "functions" to Document.

You'll need to create all method and interface for IV to use those new "functions".

[J-Camper]

Thank you both for your replies! 

@WCrihfield,

Thanks for the documentation links.  I noticed in the Inheritance Basics link there is a notion of a "NotInheritable" Keyword for classes that is false by default, but can be set true.  Do you happen to know if Interfaces might have a similar keyword?  I couldn't find one in the cursory look through upon reading this post.  There is definitely more research to be done on my part.

Have any of the classes you have made been derived from a class that you did not create the base for yourself?  Like deriving a class/object from an application specific class/object?

@Frederick_Law,

I intentionally left the idea vague because I don't really know what is even possible yet.  I do understand that anything I add will be proprietary to those with access to my add-in, but that is fine with me.  Your last statement is roughly what I would like to explore, deriving a part document interface into a proprietary part document interface, to add some custom properties and/or methods. 

[Michael.Navara]

If you need to add some new functionality to the PartDocument you have two possibilities.

1. Create your own class which implements PartDocument interface. But this is too much work and it depends on API version. When you update API version you must check/update this implementation. I DON'T RECOMMEND THIS.  
2. Use extension methods. This allows you to add some new functionality without explicit implementation of PartDocument interface.

Part of sample implementation of PartDocument interface

Class MyPartDocument
    Implements PartDocument

    Dim p As PartDocument

    Public Sub New(p As PartDocument)
        p = p
    End Sub


    Public Sub Activate() Implements PartDocument.Activate
        p.Activate()
    End Sub

    Public Sub Close(Optional SkipSave As Boolean = False) Implements PartDocument.Close
        p.Close(SkipSave)
    End Sub

    Public Sub Save() Implements PartDocument.Save
        p.Save()
    End Sub
...

Sample of extension method

Class ClassInYourAddin
    Sub SampleUsageOfExtensionMethod()

        Dim p As PartDocument

        Dim fileNameWithoutExtension As String = p.FileNameWithoutExtension()
    End Sub
End Class

Public Module PartDocExtensions

    <Extension>
    Public Function FileNameWithoutExtension(part As PartDocument) As String
        Return System.IO.Path.GetFileNameWithoutExtension(part.FullFileName)
    End Function

End Module

[WCrihfield]

Hi @J-Camper.  Unfortunately, no.  I did attempt something like that a couple times before, but decided to create my own independent Classes instead, due to some of the complications that Michael mentioned.  We are allowed to 'Implement' multiple Interfaces into a custom new Class, but as far as I know, we can only 'Inherit' from one other Class when we are making a new Class, and can not Inherit from an Interface into a new Class.  That makes attempting to create something like a 'SheetMetalDocument' Class that has all the same stuff as a PartDocument, plus some new/different stuff quite challenging, if not impossible, since we do not have access to all the source code behind the PartDocument Interface or whatever other code resources support its use in Inventor's API & iLogic.

I had seen some of that 'extension' stuff multiple times before, and am not really using any of it myself yet, but that seems like a pretty good idea, if that would suit your needs.  Since creating my own Inventor add-ins seems to not be an option for me right now, due to corporate security policies, I have created a list of external iLogic rules, with the 'Straight VB Code' option turned on, and formatted accordingly, as a way of adding a host of added functionality to my other iLogic rules, by simply using the 'AddVbFile' keyword in the Header to reference one of them, when needed.  It was a challenging road getting to this point though, having to learn a lot about all that related stuff along the way, but I honestly like that sort of thing and find it all very interesting, so I tend to pick it up quickly.  I still have a lot to learn, but I like the challenge, and keep learning new and useful stuff all the time, which is great.

Good luck.

[J-Camper]

@Michael.Navara,

I was not aware of this workflow.  The documentation link states that only methods can be added this way, properties and events cannot be.

When you say that Updated API versions make the implementation workflow harder to deal with, does that mean every service pack update? or just major updates?

[Michael.Navara]

Ad 1) Yes, you can declare only methods this way (not events). But you can implement something like property with two methods

Function GetSomething() as Object

Sub SetSomething(value as Object)

Ad 2) You need to update the implementation every time when interface is changed.

Another posibility

If it is useful, you can implement your own wrapper for Inventor object. One of the examples is ThisDoc object in iLogic. Wrapper provides directly your own methods, properties and events. You can also access the underlying object using ThisDoc.Document property and call the native functions and properties on them.

[J-Camper]

@Michael.Navara,

The Wrapper idea seems really interesting.  do you have any documentation or examples for how to create a wrapper of an object?

[Frederick_Law]

Attached Template with a InventorButton wrapper.

Don't remember where it came from.  Probably Modthemachine.

One is VB, one is C# converted from that VB.

The wrapper make it easier to use Inventor objects in program.

It doesn't add anything in Inventor.