Forum Discussion

xylian's avatar
xylian
Occasional Contributor
13 years ago

Using large numbers of Evaluate methods in the project

I'm currently researching something on the big project for my company. 



I currently ran into the problem of catching errors in the Evaluate method, which made me thinking about different solutions.



@Robert Martin - I can't post you exact example of my code, because I'm not in the work place anymore, however I'll do that right away tommorrow morning. Concerning this thread of course.



Back to the point anyway. I'm doing a lot of customization in my project. I'm creating a .NET application that communicates with TestComplete (it's basically creating ODT test structure and sending it to the TestComplete). I have to make my tests as fast as possible, and don't want to "kill" the testing machine either. So, should I even consider the idea of sending EVERYTHING to TestComplete as a string and make him evaluate each such string? (I know it sounds crazy, will probably cost a lot of resources, and is overally stupid - but just making sure)



About the second idea, which sound more reasonable:

For now I was creating objects by evaluating Sys.Process.[rest_of_the_path]. It gives me a refference to the object. However I was thinking about using Aliases instead. To do that I need to map a lot of objects for testing. What worries me is that I'll need to use Evaluate method every time I'm calling the object (it's because the path to the mapped object is like Aliases.Form1.Panel1.TabList1.Tab1.TextBox and I'll be building that path programically every time). I was wondering if I should ever consider that due to large resource costs (because large numbers of evaluate would cost a lot right?)

1 Reply

Sort By
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    13 years ago
    Instead of using Evaluate, consider FindChild.  What you can do is pass in a list of properties and a list of values, create arrays of the properties and values, and then use FindChild to find and return your object.  The bonus with this is that, if the object is not found, FindChild returns an empty "stub" object with the Exists property set to FALSE so you can still detect whether or not the object exists before you attempt to interact with it.



    For the lists of properties and values, you can pass in two delimited strings and use methods like aqString.GetListItem and the related methods to take the delimited string and parse it out into the individual pieces.  That will allow you to target your "FindChild" call to the specific object you're looking for without having to do any major mapping.



    Now, you might still want to do some basic mapping of your application and, perhaps, the main forms.  But you may not need to map everything, just a basic level and then use FindChild for the specific detail bits.