I am hitting a stumbling block here. I have an INI file that I created from within TestComplete using the Storages object to export and save some variable settings.I was able to add the file to the stores so that it can copy over when we duplicate the project suite to other directories.The problem that I seem to be getting is that while I am able to import the INI file using an absolute path to the ini file I am unable to get the script or objects to recognize the file when i use the Files.tc_ini coding. All I get in the log message for it is that it declares it as empty. and nothing that i have tried can resolve it.The file is there. I can view it. I can open it in a script using an absolute path. The problem with using the absolute path is that I will then have to edit the script file each time I need to run on a separate machine using TestExecute.Please help. Thanks,Jeremy Bertrand.

Hi Jeremy, instead ofStorages.INI(Files.tc_ini)tryStorages.INI(Files.FileNameByName("tc_ini"))Regards,Phil Baird

I'm not entirely sure that I understand what's going on here (having never worked with Stores|File nor INI files), but for what it's worth I use this code to identify a file using a relative path: currentFolderPath = aqFileSystem.GetFolderInfo(aqFileSystem.GetCurrentFolder()).Path; This gives me the directory of the script file itself, and then I can drill to whatever file I need. For instance: ..\..\New Folder\file1.txt becomes: aqFileSystem.GetFolderInfo(aqFileSystem.GetCurrentFolder()).ParentFolder.ParentFolder.Path + "\\New Folder\\file1.txt"; I hope that helps, good luck.

Hi Jeremy, would it be possible to post the INI file and code you are using to access it to have a look at what might be wrong?Regards,Phil Baird

Ok. I've cleaned up the code a little bit. I had a lot of log message statements in so I could see where things were happening and where stuff would break.This is what is in the INI file.; IMPORTANT: The Root section is mandatory[Root][paths]version=102progpath=j:\ezwin\joel\102j\netpath=k:\ezwin\102j\clinicpath=j:\ezwin\joel\102j\clinic1\This is the script that I try to get the values stored in the INI file.Sub Test4 Dim ini, tempini set ini = Storages.INI("this is the full path\Files\tc.ini") Set tempini = ini.GetSubSection("paths") ProjectSuite.Variables.version = tempini.GetOption("version", "something") ProjectSuite.Variables.progpath = tempini.GetOption("progpath", "something") ProjectSuite.Variables.netpath = tempini.GetOption("netpath", "something") ProjectSuite.Variables.clinicpath = tempini.GetOption("clinicpath", "something")End Sub

The full path to the file in question is a total of 62 characters long.Part of that is also the path to the Test Complete Project file.26 characters is the length after where the project is stored.Would it be possible to use a path relative from where the project is stored?Using the full absolute path I can read the file. and write to the project variables.that's what I put in the previous post.

Using an INI file stored in the project suite

20 Replies

jeremy_bertrand
Contributor
12 years ago
Thanks for all the help. But since I posted this I have gotten some great feedback here.

But the project that we are using this for is so that my and my co-workers could copy the entire project and have the referenced file be unique incase one person changes the INI file in their copied project.

This is so that when we can specialize the different versions that we test manually without having to edit the project suite variables each time a new version comes out.

Our current solution for this problem is going to be machine dependant where I have a file on "C:\Local_directory\test_Variables.ini" and this seems to be the easiest program because the path will be the same for each machine and we can still have the default variables in the project suite incase the ini file is not there.

Thanks,

Jeremy
howie_
Contributor
12 years ago
Out of curiosity, are either the machine names or user names unique? If they are you might be able to create individual ini files for each scenario, and then use Sys.HostName or Sys.UserName (possibly in combination with Sys.DomainName) in order to identify the correct file...

switch(Sys.HostName)

{

case "EN_Win7x32": iniName = "english.ini"; break;

case "FR_Win7x64": iniName = "french.ini"; break;

}

var path = <relative path to directory embedded within your project> + "\\" + iniName;

or, hypothetically, if you named the ini files to match the machine names you could just do this:

var path = <relative path> + "\\" + Sys.HostName + ".ini";
jeremy_bertrand
Contributor
12 years ago
We are on a Windows Domain, the computer names are not really important because the ini file was on a shared network drive.

Since we run TestComplete in RDP because of the system where it is installed at and we only have one node locked license. We are also licensed for TestExecute. We were looking for a solution to be able to have 2 testers run the automated tests at the same time. But because of some preset variables they would be running the tests with the same data and screw up one test or another.

So the thought of being able to A) copy the file with the suite so the settings could be changed per suite sounded appealing. B) the other possibility was machine dependent. Where I have the script which is on a mapped drive point to a local drive ( eg. C:\ ) that way everyone has a C:\ drive then all they need to do is copy the INI file to be able to have different testing variables and not mess with another's test run.

This is because unless the values were changed in TestComplete before running it in TestExecute the copied suite would still have the same variables as the previous suite and screw the automate test up for both testers.
Philip_Baird
Community Hero
12 years ago
Hi Jeremy, when you type:

Storages.INI(Files.tc_ini)

does "tc_ini" appear in the intellisense after entering "Files." ?

Regards,

Phil Baird
jeremy_bertrand
Contributor
12 years ago
It shows up in the window with the functions and modules. Like the FileNameByName, FileNameByIndex, CreateEmpty, etc.

in coding this line -- Storages.INI ( Files.tc_ini )

I get an error:

Type mismatch: 'Storages.ini' Error location: Unit: "test1111\filing\Script\Unit4" Line: 16 Column: 3.

Type mismatch: 'Storages.ini'

Error location:

Unit: "test1111\filing\Script\Unit4"

Line: 16 Column: 3.
TanyaYatskovska
Alumni
12 years ago
Hi Jeremy,

The Storages.INI method accepts only the string. That's why, you get an error when trying to pass the File object (Files.tc_ini returns it).

Actually, this code suggested by Phil should work:

Storages.INI(Files.FileNameByName("tc_ini"))

Could you please describe what happens when you execute this code? What is the expected and the actual behavior?
jeremy_bertrand
Contributor
12 years ago

Tanya,

OK,

Could you please describe what happens when you execute this code?

When I use the line that you and Phil have suggested I do not get anything. No error, No file, no Sections, no SubSections, no options.

It is like it's there but it finds nothing but empty values.

See Attached image.

What is the expected and the actual behavior?

This was supposed to be able to allow me to set project suite variables to values from the ini file. You open the file, read the values associated to the subsection/section, read the options in the only section besides "[Root]" then assign the values to the corresponding project suite variable.

The actual behavior for when I have the script get the file with the absolute path as opposed to the shortcut by using the Files.Filename or Files.FileNameByName("string") or Files.GetFileName("string"), etc.

I get nothing back its is like it does not recognize the file. or that the file is empty.

I have tried to log the name of the file in stores, I get no name.

The only way to that I have found to do what I need it to do is have the "String" be the full and absolute path to the ini file. I have not tried to use the project or project suit path as a starting point so that may be a possible workaround. but I have already got my scripts to recognize the file place on the "C" drive. that way it is machine dependant not project suite dependant.
Philip_Baird
Community Hero
12 years ago
Hi Jeremy, all the details of the Files referenced in the Stores are found in the Projects "Files.tcFiles" (XML format) file.

The "tc_ini" that is the Name that is viewed in the Files screen appears to be a key to locate the details in the XML tree, as such:

<Node name="item0000000001">

<Node name="item data">

<Node name="settings"/>

<Prp name="caption" type="S" value="tc_ini"/>

<Prp name="filename" type="S" value="General\tc.ini"/>

<Prp name="id" type="S" value="{FD24111E-DBC9-432E-8EEF-3A36A7BFE74C}"/>

<Prp name="signature" type="S" value="{FC92F8D9-8A57-4D74-B8B4-479AA50BF647}"/>

<Prp name="update" type="B" value="0"/>

<Prp name="version" type="S" value="10.0"/>

</Node>

<Prp name="index" type="I" value="1"/>

<Prp name="key" type="S" value="{FD24111E-DBC9-432E-8EEF-3A36A7BFE74C}"/>

<Prp name="pluginname" type="S" value="Stores"/>

<Prp name="type" type="S" value="{FC92F8D9-8A57-4D74-B8B4-479AA50BF647}"/>

<Prp name="typename" type="S" value="File"/>

</Node>

From what I have observed, the call Files.FileNameByName("tc_ini") works as such:

1. Go to the Files.tcFiles file

2. Find the node that has a "Prp" element with the value attribute of "tc_ini" where the "name" attribute is "caption"

3. Retrieve the "value" attribute of the "Prp" element with the "name" attribute of "filename"

I qualified this by manually editing the "filename" "Prp" element and Files.FileNameByName("tc_ini") returned the path I entered.

It also showed that it does not read the file at all that file name I changed to did not exists but Files.FileNameByName("tc_ini") still functioned without error.

As I said, this is how I have observed this to work, I have no idea of the actual inner workings of the function code.

Regards,

Phil Baird
jeremy_bertrand
Contributor
12 years ago
So instead of the program acknowledging that my file stored in the project is an ini file and being able to access it through the storage ini methods and protocols I would have to instead access it via storage xml? This makes no sense.
Philip_Baird
Community Hero
12 years ago
Hi Jeremy, no, not at all, what I posted was how the Files.FileNameByName() method appears to work.

Store.Files and Storages are two completely different objects.

As per the documentation, Stores.Files is simply a "collection named Files and stores references to different kinds of files (graphic, text, HTML files and others) that can be used in tests"

whereas, as per the documentation, the Storages object is a mechanism to store and retrieve data in INI, XML or Binary files.

The Storages object itself has no knowledge of the files referenced by the File.Stores collection nor their file types.

Storage.INI() only knows to parse the file specified by a fully qualified path, it is during parsing that Storages.INI() will determine if the file is a valid ini file.

Regards,

Phil Baird

Forum Discussion

Using an INI file stored in the project suite

20 Replies

Recent Discussions

Hover Button...

“TestComplete PKCE Handler – Failed to verify the login request”

ADO Pipeline Execution Fail issue after TC\TE upgrade

Related Content

Storing project properties

In which files are project variables stored?

Project-level custom properties unable to store locally