Well, I guess the question is... why do you need so many globally scoped persistent variables that persist from test run to test run? To be honest, that seems like an excessive number of globally scoped variables, persistent or otherwise. What are you using them for?
If this is a limitation built in to TestComplete, then I don't think there's a "work around" available... however, I just tried this... I was able to add 65 variables and I still haven't hit a "max limit". So... I guess the question is, how are you adding the variables? In my quick test, I just right clicked on the Persistent Variables section of my project suite and selected "new item".
Thank You
There are so many screens in our application under test has controls with dynamic identification properties, more over there are multiple instances of same control will be present on same screen. Direct name mapping of each control is tedious here, instead name map one of the control from a group of similar controls and use the project level variables to identify varying properties to distinguish which GUI control to access by run time decision. Added more persistent variables to distinguish each control type and screen.
I am also adding new variable just by right clicking and picking the New Item menu. However I am loosing existing variables when I add new one.
(My project had 33 Project level temporary variables in use)
I would suggest there is a better way of handling the namemapping issues than creating a new persistent variable every time you need to add a varying property. Consider not having to map all your objects, for example. In our application under test, we have some tables that show up in our web application that are long, dynamic lists of data. From run to run, this list varies in length. So, mapping all the rows and columns in this table doesn't make sense. So, we use various "Find" functions to find what we want. FindChild, Find, NativeWebObject.Find, etc, all come into play. You can build a library of such functions to call within your tests that you can just pass in the parameters rather than having to put them in any set of variables.
There are other ways of dealing with dynamic properties... conditional namemapping is one, using wildcards is another. But honestly, if you're hitting 58+ variables just to handle your mapping, I'd really suggest going a different direction.
That said... there is no upper limit that I can find to adding variables to a project or project suite. So, why you're "losing" some is curious. There has to be something unique about how you're doing stuff. Keep in mind that the variables are stored in the PJS (for project suite) and MDS (for project) files. So, if you're adding variables and someone else is adding variables, and you check in changes to your source control, you could be accidentally over-writing changes that the other person made, resulting in variables "disappearing".
Thank you for suggestions, I would consider it for long run. We are also using Find functions to certain extend to identify controls, but realizing it is having very minimal scope in our automation. Should expand Find function approach as you said rather than persistent variables.
I was experiencing this variable removal strange behavior at my machine almost for a week. Somehow it got resolved just now , I am not sure what action got fixed the problem. Added few more variables to Temporary section and Saved all files, then deleted these temporary variables, Saved all files. Added a persistent variable on right clicking the last Empty Row in Persistent variable section and saved files. Variables were sorted in the order of Name column and I was right clicking in any row earlier to add new item. Once I picked the last row for right clicking, it started working; now I can able to add new variables from any row without loosing existing ones.
