mpdillon
asked on
How to use a COM object in Visual Basic 2013
I have a COM object that has numerous properties which are set prior to calling one if its methods. I have been using the following code to open/start the COM object. This code does not work inside a Try Catch block.
Is there a better way than trying to catch the error if the GetObject fails.
I would like to find a way to create the object inside the Try Catch block. I was thinking of Process.Start but I could not get it to work.
Existing Code:
Is there a better way than trying to catch the error if the GetObject fails.
I would like to find a way to create the object inside the Try Catch block. I was thinking of Process.Start but I could not get it to work.
Existing Code:
Dim objWP as Object
On Error Resume Next
objWp = GetObject(, "WPProjectX.Class1")
If Err.Number = 429 Then
objWp = CreateObject("WPProjectX.Class1")
End If
On Error GoTo 0
WIth objWP
.Connection = "Servername, etc"
.LotNo = "XXXXXX"
.DetermineSpecSheet
s = .SpecSheet
end withASKER
Ok. Good advice. I do have just one follow up question. How do I close that object.
More background than you probably need but I think it is relevant.
I wrote the COM object in VB6 over 10 years ago. it is an ActiveX exe. This COM is used by dozens of other programs. My experience has been that early binding has led to me having to remove the exe from the calling application when a Property or Method is changed in the COM exe. After removing the EXE from the calling application, it has to be added back to the program. The program recompiled. Uninstalled on the user's computers and reinstalled. These changes to the COM are infrequent, 2 or 3 a year now. However with early binding it is a huge task to update all the users computers without disrupting their work. Late binding seems to eliminate most of the problems associated with changing the COM object.
In this instance it will be part of a Web Service. I will just have to remember/document that I have to tinker with the web service when the COM is changed.
That is the explanation for why I was using Late Binding. Now onto my follow up question.
The COM is used not only for this web service but was developed for all the users at this location. Initially, the COM object would not always close completely on the users computer. The user's systems memory would become completely consumed by multiple instances of this COM object. I became very sensitive to the need to close the object and get it out of memory. There were some settings in the VB6 COM project that needed to be set. "instancing - GlobalMultiUse" and "Persistable - 0 NotPeristable". And I had to add extra code to the Methods within the COM object to ensure the forms were completely closed.
So my question about disposing of the object comes from a lot of history. What is the proper way to dispose of this object. Neither Dispose nor Close are available in Intelisense.
Thanks,
More background than you probably need but I think it is relevant.
I wrote the COM object in VB6 over 10 years ago. it is an ActiveX exe. This COM is used by dozens of other programs. My experience has been that early binding has led to me having to remove the exe from the calling application when a Property or Method is changed in the COM exe. After removing the EXE from the calling application, it has to be added back to the program. The program recompiled. Uninstalled on the user's computers and reinstalled. These changes to the COM are infrequent, 2 or 3 a year now. However with early binding it is a huge task to update all the users computers without disrupting their work. Late binding seems to eliminate most of the problems associated with changing the COM object.
In this instance it will be part of a Web Service. I will just have to remember/document that I have to tinker with the web service when the COM is changed.
That is the explanation for why I was using Late Binding. Now onto my follow up question.
The COM is used not only for this web service but was developed for all the users at this location. Initially, the COM object would not always close completely on the users computer. The user's systems memory would become completely consumed by multiple instances of this COM object. I became very sensitive to the need to close the object and get it out of memory. There were some settings in the VB6 COM project that needed to be set. "instancing - GlobalMultiUse" and "Persistable - 0 NotPeristable". And I had to add extra code to the Methods within the COM object to ensure the forms were completely closed.
So my question about disposing of the object comes from a lot of history. What is the proper way to dispose of this object. Neither Dispose nor Close are available in Intelisense.
Thanks,
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I am very appreciative of your lengthy answer. I know it took a long time to compose. I understand very little of memory management in .net or VB6. This was most helpful.
I will try your suggestion.
Thanks again,
pat
I will try your suggestion.
Thanks again,
pat
In the Solution Explorer, click on MyProject for your project. Go to the References tab, then Add, then the COM tab, and activate your dll that should be in there somewhere.
You can then use the more modern way of using your object:
Dim objWP as WPProjectX.Class1
objWp = New WPProjectX.Class1
This will be a better approach, because IntelliSense will be able to tell you about the properties, methods and parameters used to work with the class. The compiler will be able to validate what you do and catch errors that would otherwise end up being runtime errors.
Note that this not work with all COM dlls. Older ones cannot work with New and can be instiated only with GetObject or CreateObject.
You might also end up, in both techniques, with problems due to the differences between .NET and COM. Things such as the fact that the Variant data type does not exist in .NET. Some basic types have also changed, and you have to take that in consideration. As an example, what was a Long in COM is an Integer in .NET. The Long in .NET is bigger than in was and can cause problems if sent to a COM objects. Your .NET code should adapt to such situations in order to work as intended.