Registration Free Com in Excel

[Richard Deeming]

If the API was written in .NET, it might not be exposed as a COM library. There are specific steps you have to take to make that happen: Exposing .NET Components to COM[^] If there isn't a COM API available, you have a couple of choices. You could write your own wrapper API in .NET, and expose that wrapper as a COM-callable library. Or, you could use VSTO to write a .NET Execl add-in[^], and call the API from that.

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[User 12303436]

Okay, so if I create my own Library exposing the .NET calls to be consumed in VBA I can reference this Library in Excel? I have Visual Studio so I can build DLL files and anything that does not require installation (or registry access) to run. If I can consolidate the functionality to an Excel workbook that would be great. Which is why I was thinking of Reg Free COM. How can I call the Library in Excel VBA? Edit: I can't build executables either. IT is picky about what we can and cannot do. However Excel is free game.

[Richard Deeming]

Yes, if you follow the instructions in the article I linked to, you can create your own .NET library to call the API, and then call that as a COM component from Excel. Or you could use VSTO to create an Excel add-in or workbook with .NET code running behind it. But it sounds like you might be locked out from doing that as well.

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[User 12303436]

Hello, in the article you linked in your post, there are two different GUIDs. What are the differences in the 2, and which ones should I be using? Also, in the article to call the COM object he was able to reference the COM wrapper class built to expose the .NET calls to VBA in Visual Studio. I am trying to do this in Excel, where I can't simply reference the dll. Can somebody tell me how I can call COM objects in Excel? Here is my code for the COM Wrapper Class:

Imports System
Imports System.Collections.Generic
Imports System.Runtime.InteropServices
Imports NXOpen
Imports NXOpen.UF
Imports NXOpen.Assemblies

Namespace ExcelNXInterface

\_
Public Interface \_ExcelNXInterface
    Sub HighlightCompTag(ByRef tag As Long)
    Sub Echo(ByVal output As String)
End Interface

Public Class ExcelNXInterface
    Implements \_ExcelNXInterface

    Public \_ExcelNXInterface

    Dim theSession As Session = Session.GetSession()
    Dim ufs As UFSession = UFSession.GetUFSession()

    Public Sub HighlightCompTag(ByRef tag As Long) Implements \_ExcelNXInterface.HighlightCompTag

        'Cycles through component objects by tag in NX, and then when finding it, highlights it. 

        Try
            ufs.Disp.SetHighlight(tag, 1)
            Echo("Component(s) Highlighted...")
        Catch e As NXException
            Echo("NX Exception is: {0} " + e.Message)
        Catch e As Exception
            Echo("Exception is: {0} " & e.Message)
            Echo("DONE!" & vbLf)
        End Try

    End Sub

    Sub Echo(ByVal output As String) Implements \_ExcelNXInterface.Echo

        theSession.ListingWindow.Open()
        theSession.ListingWindow.WriteLine(output)
        theSession.LogFile.WriteLine(output)

    End Sub

End Class

End Namespace

Here is the manifest I built to reference in Excel:

[Richard Deeming]

Obviously, you need to create your own Guids. :) I believe you'd use the Guid from the IDispatch interface, but it's a long time since I've had to touch COM at that level.

Member 12336929 wrote:

progid="ExcelNXInterface.Open" Set myNX = actCtx.CreateObject("ExcelNXInterface.Open")

That doesn't seem to match the name of the class you created. Did you mean to use ExcelNXInterface.ExcelNXInterface instead?

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[User 12303436]

Okay, based on some other examples I found online I saw that some people used the progid in the manifest. I wasn't sure why, but I just followed the examples. So I went ahead and tried using your suggestion. This time around I got another error, but it seems much friendlier (maybe). It says "ActiveX component can't create Object". So maybe using ExcelNXInterface.ExcelNXInterface was the way to go, even though it still isn't working. It seems better than the error saying the Create Object Method Failed. Anyway, I am pretty much lost from here out. Not sure what else can be done. I have seen in other forums online that some people claim in order to pull this off you need to alter the Excel.exe.manifest file to point to your dll, and store the dll in the same folder as Excel's executable file. I'm hoping that isn't true.

[Richard Deeming]

I suspect you'd need to update the progId in the manifest to ExcelNXInterface.ExcelNXInterface as well.

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[User 12303436]

Okay so I changed the manifest to reflect the new progid: ExcelInterface.ExcelInterface . I assumed that also meant that I should change the progid in the DLL to match the manifest. I changed the following line: ProgId("ExcelNXInterface.ExcelNXInterface")> Public Class ExcelNXInterface. As a result I am getting the following error: Method 'CreateObject' of object IActCtx failed. Thank you for your help by the way.

[Richard Deeming]

Member 12336929 wrote:

ExcelInterface.ExcelInterface

Member 12336929 wrote:

ProgId("ExcelNXInterface.ExcelNXInterface")

Which is it? These should both match.

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[kdbueno]

dim sub var does not preclude subject.iss on iss rules, neither ops rules, object conjecture.