Forum Discussion

asadc's avatar
New Contributor
5 years ago

.NET Connected.TestedApps["Items"]("appName") execute well in TC IDE, but giving null exception in C

This code execute successfully in TC-IDE

function Test1()


var appName = "TestApp";

var appObj = TestedApps["Items"](appName);

if (appObj != null)






but  giving null exception in C# ConnectedApp:

using tcVar = AutomatedQA.script.var;

using AutomatedQA.TestComplete;


public static void StartApp(string AppName)


  tcVar app = AppNAme;

  tcVar appObj = Connect.TestedApps["Items"](app);

  if (appObj != null)


       tcVar str = "The project contains following TestedApps: " + objApp["FileName"];


      str = "Full Name with Path of Application: " + objApp["FullFileName"];




What is wrong with my code. I had write the same code using VBScripts in TC-IDE, it runs OK, but same error if i tried to run in VB.NET connected app.

An early response will be appreciated.

  • Hi,


    Well, I don't know all your details, but my personal opinion is "Why not to provide a client with TestComplete project that already does what is needed?".

    While providing TestComplete project to the client you may warn them that if they change something in test code this will be on their own and you will not support this. What you will support is their change requests in response to which they will get updated TestComplete project.

    Or your expectation was not to support provided .dll?


    What you are trying to implement sounds to me like connected self-testing application where TestComplete is supposed to act as this self-testing application. Not sure to what extent this is supported in TestComplete.

    Slightly different approach that you may consider: when your test code is running, it may call Sys.OleObject("TestComplete.Application") and get an access to the COM object of the current TestComplete instance. This COM object provides some child objects like Integration and others (if I remember their names correctly) that can be used from test code.

    The problem is that these child objects are not well documented and it will not be easy to figure out how this or that can be done. If ever can.

    I would recommend to ask Support for their comments directly via the form and reference this thread.


7 Replies

  • AlexKaras's avatar
    Champion Level 3



    Preliminary remark: I assume that you are aware that Connected Applications are deprecated in favor of TestLeft, aren't you?


    giving null exception in C# ConnectedApp

    Without knowing at least what line of your code throws the exception, my first wild guess is that TestComplete is not in script-running mode:


    • asadc's avatar
      New Contributor

      Hi Alex,

      Now I changed the Connected App scenario, I put my code in a VB.Net Dll, and I added the Dll in TC using CLR_Bridge. It was successfully registered in, I write following code 

      Sub TstXlsRdr
         Dim p
         p = dotNET.CMSIntergrationLib.DriverTC.ProcessBatchFile("D:\TestComplete\BatchRN2.xlsx", "CTA")

      End Sub

      The subroutine reads an excel file successfully, Connect.Log.Message can also successfully write the strings in TC log. But as I try to read following statement it give error [Object variable or With block variable not set]


      Private Function CheckRegApps(appName As String) As String

        Dim AppName As String = appName

        Dim tstAppObj


            tstAppObj = Connect.TestedApps.Items(AppName)

        Catch ex As Exception

           Throw ex

        End Try

      End Function

      What is wrong with this code, looks like tstAppObj is unable to get TestedApp type of object. 

      I am new to TC environment, please need guideness in this matter.

      • AlexKaras's avatar
        Champion Level 3



        Can you describe for what and how you are going to use TestComplete? What type(s) of tested application(s) are you going to work with?

        The case is that the initial idea and the purpose of Connected applications support in TestComplete was to provide support for self-testing applications while make it possible for them to use some functionality of TestComplete in order to not invent the same just for the testing purposes. For example - use test log provided by TestComplete and not create custom logging.

        Self-testing applications are applications that do some test actions from within their own code using full access to application's code - a kind of highly extended unit testing. For example, your application, if started with some additional parameter, may expose additional toolbar with buttons that trigger some business workflows that regular human users are expected to follow, but without user interface and additional messages (like 'Do you really want to delete this order?').

        Considering the above, some functionality provided by TestComplete may be irrelevant for self-testing applications and might be not supported. (This should be checked with TestComplete's documentation.) For example, what for your self-testing application might need to get the list of the Tested Applications from TestComplete's project while it (application) is already running and has all information about itself?

        If for any reason you need to have self-testing application then, as I wrote it in my initial reply, I would recommend you to consider TestLeft as it better suits this testing scenario.

        The primary area for TestComplete is external control of the tested application from the point of view of the human user. This means that (primarily) TestComplete has no idea about application it will drive. That is why this is specified as the Tested Application. When TestComplete starts the Tested Application, it analyses started application in order to control it more efficently. In certain cases, it is possible to call native internal public methods of the tested application from TestComplete's test code, but this is an exceptional case, not the usual recommended approach. The usual approach with TestComplete is to emulate end-user's actions via sending operating system messages to the tested application (like type some keys, click mouse button, etc.) like the human user, who has no access to source code and application's internals, does.