Skip to main content

Using EXTRA Basic COM object with Reflection and .NET

  • May 9, 2017
  • 6 replies
  • 1 view
D

We are transitioning from EXTRA Basic to Reflection later this year, and are just beginning the process of testing and validating our existing processes with the new Reflection software. We have a large volume of VBA (Excel) and .NET applications that we use for automation with EXTRA Basic. Typically, these applications connect to EXTRA Basic using the code block below (or something similar).

In VBA, this code (or the VBA equivalent) works fine as-is with Reflection without changing anything. However, it doesn't work in VB.NET - it's unable to create the "EXTRA.System" COM object, which causes the rest of the process to fail. It's strange to me that VBA is able to create the COM object, but .NET isn't.

Is there anything we can do to get this code working as-is in VB.NET? Obviously Reflection has a newer .NET API available, but we would prefer not to have to modify every existing application we have (there's a lot of them!) with the new code.

    Dim _system As Object
    Dim _screen As Object
    Dim _sessions As Object
    Dim _session As Object
    Dim _waitHostSettleTime As Object
    Dim _originalSystemTimeout As Integer

    Public Function Connect(Optional waitHostSettleTime As Integer = 50) As Boolean
        Try
            _system = CreateObject("EXTRA.System")
            _sessions = _system.Sessions
            _waitHostSettleTime = waitHostSettleTime ' milliseconds
            _originalSystemTimeout = _system.TimeoutValue
            If (_waitHostSettleTime > _originalSystemTimeout) Then
                _system.TimeoutValue = _waitHostSettleTime
            End If
            _session = _system.ActiveSession
            _screen = _session.Screen
        Catch ex As Exception
            Return False
        End Try

        Return True
    End Function

#Reflection
#Desktop

6 replies

D

We are transitioning from EXTRA Basic to Reflection later this year, and are just beginning the process of testing and validating our existing processes with the new Reflection software. We have a large volume of VBA (Excel) and .NET applications that we use for automation with EXTRA Basic. Typically, these applications connect to EXTRA Basic using the code block below (or something similar).

In VBA, this code (or the VBA equivalent) works fine as-is with Reflection without changing anything. However, it doesn't work in VB.NET - it's unable to create the "EXTRA.System" COM object, which causes the rest of the process to fail. It's strange to me that VBA is able to create the COM object, but .NET isn't.

Is there anything we can do to get this code working as-is in VB.NET? Obviously Reflection has a newer .NET API available, but we would prefer not to have to modify every existing application we have (there's a lot of them!) with the new code.

    Dim _system As Object
    Dim _screen As Object
    Dim _sessions As Object
    Dim _session As Object
    Dim _waitHostSettleTime As Object
    Dim _originalSystemTimeout As Integer

    Public Function Connect(Optional waitHostSettleTime As Integer = 50) As Boolean
        Try
            _system = CreateObject("EXTRA.System")
            _sessions = _system.Sessions
            _waitHostSettleTime = waitHostSettleTime ' milliseconds
            _originalSystemTimeout = _system.TimeoutValue
            If (_waitHostSettleTime > _originalSystemTimeout) Then
                _system.TimeoutValue = _waitHostSettleTime
            End If
            _session = _system.ActiveSession
            _screen = _session.Screen
        Catch ex As Exception
            Return False
        End Try

        Return True
    End Function

#Reflection
#Desktop
Hi,

When you install Reflection Desktop, the .NET API component is not selected by default. So just run the installer again and make sure this is selected:
[INDENT] [/INDENT]

For deployment, you should make sure to use a customised installation which activates this feature.

VBA is integrated with our software so it doesn't need to have this component installed in order to run and access the interface.

Also, as a developer, in order to make sure that the API class library assembly files are integrated with Microsoft Visual Studio, confirm that Visual Studio is installed before you install Reflection.

You can find further information here.
D
Hi,

When you install Reflection Desktop, the .NET API component is not selected by default. So just run the installer again and make sure this is selected:
[INDENT] [/INDENT]

For deployment, you should make sure to use a customised installation which activates this feature.

VBA is integrated with our software so it doesn't need to have this component installed in order to run and access the interface.

Also, as a developer, in order to make sure that the API class library assembly files are integrated with Microsoft Visual Studio, confirm that Visual Studio is installed before you install Reflection.

You can find further information here.
Thanks for the reply. We got the API component installed, but still not having any luck with our legacy code. It appears to create the "EXTRA.System" object correctly, but anything that references a public property/method on that object throws an exception ("Public member XYZ on type MarshalByRefObject not found"). Should the code in my original post be capable of working in Reflection?
D
Thanks for the reply. We got the API component installed, but still not having any luck with our legacy code. It appears to create the "EXTRA.System" object correctly, but anything that references a public property/method on that object throws an exception ("Public member XYZ on type MarshalByRefObject not found"). Should the code in my original post be capable of working in Reflection?
Yes, the Extra-compatibility interface in Reflection is not designed to be used with Visual Studio .Net applications. You will get a little farther if you use "early binding" i.e., make a reference to the Extra.tlb and declare Extra variables as their specific type, but you will still run into problems with "WaitFor..." methods. It may take some time and effort to re-do old code to use the Reflection .Net interfaces, but there are many advantages. For one thing, you will be able then to do all sorts of fancy things if you wanted to with Reflection that are not possible with the old Extra-compatibility interface. Your code will run much faster if you are doing bulk-updates or data harvesting, where performance is key - the Extra-compatibility interface has terrible performance. The Reflection API is not all that different, and you may find that converting old code may go much quicker than anticipated.
D
Yes, the Extra-compatibility interface in Reflection is not designed to be used with Visual Studio .Net applications. You will get a little farther if you use "early binding" i.e., make a reference to the Extra.tlb and declare Extra variables as their specific type, but you will still run into problems with "WaitFor..." methods. It may take some time and effort to re-do old code to use the Reflection .Net interfaces, but there are many advantages. For one thing, you will be able then to do all sorts of fancy things if you wanted to with Reflection that are not possible with the old Extra-compatibility interface. Your code will run much faster if you are doing bulk-updates or data harvesting, where performance is key - the Extra-compatibility interface has terrible performance. The Reflection API is not all that different, and you may find that converting old code may go much quicker than anticipated.
Thanks for the help - it sounds like we have some code to update! I still don't fully understand the VBA vs .NET aspect of it. Our VBA code seems to run fine, but it's Excel VBA, not the integrated Reflection VBA. I would think that Excel VBA would run into the same issues as .NET, but perhaps I just don't understand the nuances of what's going on in the background there.
D
Thanks for the help - it sounds like we have some code to update! I still don't fully understand the VBA vs .NET aspect of it. Our VBA code seems to run fine, but it's Excel VBA, not the integrated Reflection VBA. I would think that Excel VBA would run into the same issues as .NET, but perhaps I just don't understand the nuances of what's going on in the background there.
The difference is that Visual Studio .Net applications are "managed code". .Net applications have all sorts of restrictions and limitations that do not affect "native" code (like Excel and Reflection VBA), and getting access to native, unmanaged interfaces from managed .Net projects sometimes can leave various features inaccessible or non-functional. Microsoft has traditionally said it created the "managed" .Net programming environment for your safety and protection, however this continues to be debated in uncountable forums across the internet.
D
The difference is that Visual Studio .Net applications are "managed code". .Net applications have all sorts of restrictions and limitations that do not affect "native" code (like Excel and Reflection VBA), and getting access to native, unmanaged interfaces from managed .Net projects sometimes can leave various features inaccessible or non-functional. Microsoft has traditionally said it created the "managed" .Net programming environment for your safety and protection, however this continues to be debated in uncountable forums across the internet.
Makes sense - thanks again for the help!

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement