Forum Discussion

IuliaVascan's avatar
IuliaVascan
Occasional Contributor
4 years ago

Passing variables from TC

Hi,

 

I want to pass some variables from a TC script to another tool. I run the script from TC via command prompt. Now I have a variable called 'battery_colour' which I want to read it and also call it from this tool. 

For now I write that variable in a excel file through TC, and after that I read that variable from the other tool. But I want to know which is the best way to do that.

 

Also I saw that is possible to do this via cmd, but I don't know exactly how it works:

 - first you have to define that in TC like: Project.Variables.battery_colour = BuiltIn.ParamStr(<positionOfArgument>).split("=")[1]

 -  and second how you call that in cmd?

Or maybe is a better way to do that..

 

  • AlexKaras's avatar
    AlexKaras
    4 years ago

    Hi,

     

    Or it can be done directly [...] but in an opposite way?

    No, basically not.

    There are two ways (scenarios) how applications can interact with one another. And each way has several options.

    First way is when first application (app A) generates some result data, terminates and another application (app B) is started then somehow and expects to process the data from the first application. This is your case if I got you right.

    With this scenario, app A must provide resulting data to some persistent or temporary storage provided by OS. Usually this is either file, or environment variable, or a pipe (redirection).

    In order the pipe can be used, app A must output its data to standard OS output. Like dir command does. In this case pipe can be used like this: dir c: | sort. However TestComplete does not provide data to standard OS output and thus this option is not available to you.

    So basically you are left with either file or environment variable ones.

     

    The second way is when app A does not terminate after result data are generated but continues to run and calls/spawns app B from within the code.

    Usual options for this scenario are either process spawning (using generated command line for app B) or interaction with app B via COM calls or some queue. As options for this scenario are implemented in code within app A, code in app A can directly get and use values of its internal variables (project variables in your case) to create proper command-line strings or required data structures.

    But this scenario is not your one and thus we do not consider it.

     

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3

    Hi,

     

    Writing variable's value to Excel file in TC and reading this file in your another tool is a valid approach.

    However, Excel seems to be an overkill for such task and I would recommend to consider plain text file that you can read from / write to using methods provided by the aqFile object.

    Another possible option is to use environment variable, but while TC provides the means to get the value of the environment variable via aqEnvironment object, this object does not have a method to set a value to the environment variable. Thus I would not recommend this approach to you.

     

    Project.Variables.battery_colour = BuiltIn.ParamStr(<positionOfArgument>).split("=")[1]

    This code gets value of command-line parameter and assigns it to the project variable in TestComplete code. You need the opposite - to assign the value of TestComplete variable to something external. Thus this code is not applicable to your task.

     

    • IuliaVascan's avatar
      IuliaVascan
      Occasional Contributor

      For the first answer:

      I already switch to txt file. Thank you!! 

       

      For the second answer:

      In order to do that "You need the opposite - to assign the value of TestComplete variable to something external." it means that I have to use also a txt file to store that value? Or it can be done directly via something similar to Project.Variables.battery_colour = BuiltIn.ParamStr(<positionOfArgument>).split("=")[1] but in an opposite way? Because I don't understand exactly how something from exterior of TC will recognize the TC variable..maybe if I use that environment variable but as you said not recommended. 

       

      AlexKaras Thank you for all of you answers, for me as a beginner are very helpful! 

      Also thanks sonya_m  for the heads up!  

       

      • AlexKaras's avatar
        AlexKaras
        Champion Level 3

        Hi,

         

        Or it can be done directly [...] but in an opposite way?

        No, basically not.

        There are two ways (scenarios) how applications can interact with one another. And each way has several options.

        First way is when first application (app A) generates some result data, terminates and another application (app B) is started then somehow and expects to process the data from the first application. This is your case if I got you right.

        With this scenario, app A must provide resulting data to some persistent or temporary storage provided by OS. Usually this is either file, or environment variable, or a pipe (redirection).

        In order the pipe can be used, app A must output its data to standard OS output. Like dir command does. In this case pipe can be used like this: dir c: | sort. However TestComplete does not provide data to standard OS output and thus this option is not available to you.

        So basically you are left with either file or environment variable ones.

         

        The second way is when app A does not terminate after result data are generated but continues to run and calls/spawns app B from within the code.

        Usual options for this scenario are either process spawning (using generated command line for app B) or interaction with app B via COM calls or some queue. As options for this scenario are implemented in code within app A, code in app A can directly get and use values of its internal variables (project variables in your case) to create proper command-line strings or required data structures.

        But this scenario is not your one and thus we do not consider it.