Finding Objects Delphi
Sometimes Test complete can't find the right object.
The correct name of the object (marked in red in attachment) is DBText12.
Every x-th time TC says "No the name isn't DBText ...... The name is shape1"
On these times TC also couldn't "see" buttons, but only the Panel behind
Do anyone have an idea how to handle.
Cancelling this teststep is no idea if you click on the object, a window appears.
Searching for DBText OR shape is no good idea too.
Seems like it is a timeproblem
Standart autowait timeout is set at 1 minutes .
Maybe i will make a delay.
Checkpoints: In case of failor its not possible do reach any button or text.
By the way. i tested my program in midday, I dind't change anything, and it worked.
Thanks to you two
OK, first of all... AVOID hardcoded delays if at all possible... aqUtils.Delay is nice... but if the circumstances chance, you'll end up having to change code... again... that's why you should use WaitNNN methods and set the wait time sufficiently high to cover all contingencies... it avoids hardcoded delays and yet still allows your tests to work around synchronization issues.
As for your last statement, DEFINITELY a performance issue in your environment. Something slowed down your machine early on so that, now, it's working better. I'd suggest investigating that line of things as well that, if you know you're going to be running your tests during a particular time frame, make sure that nothing is going to impact performance.
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
+1 to @tristaanogre
Hardcoded delays = bad.
Validate the item, with escape clauses, before use.
A hardcoded delay will either:
1. Slow things down more than they need to be.
2 Come back and bite you on the bum one day when you hardcoded delay length turns out not be long enough.
Or possibly both.
Either way, validate, don't hardcode!
if it's a timeout issue and you're waiting for an object to appear, you'll need to implement this function (that is in SmartBear's sample files)
function WaitAliasChildFunction(object: AliasObj; Name: string, time: integer):Boolean;
// Specifies the Alias object
AliasObj := object;
// Checks whether the Font window has appeared within 10 seconds
if (AliasObj.WaitAliasChild(Name, time).Exists) then
Log.Message('Element found : ' + Name)
Log.Message('Elément not found : ' + Name);
if you want to use this short script you write :
if (WaitAliasChildFunction(Aliases.Kasse.ArtBei, 'DBText12', 15000)) then
in this script, you could put everything as a child. and you won't need to wait for 15 seconds (in this example) : when the DB will be in memory, the counter will stop and it will do the "then" block
That will not work 100% of the time.
It depends how your developers are removing or hiding objects.
My application is Delphi. Some objects, when they are not in use, are hidden. Some are destroyed. So I can't rely solely on exists. It's not enough. I have to check Exists, VisibleOnScreen, and for one particular control (I can't remember what type off the top of my head) I have to check a Field value as well as VisibleOnScreen is not accurate for it either.
I'm part of the dev team, and we don't specialy hide objects. but... this script is an example. In my toolbox, in TestComplete, I implemented several scripts that wait for particular properties. but the logic is the same.
enabled and visible
you could wait several properties one after the other by doing loop into loop.
but again, as a dev I don't hide controls. I just act on some of its properties, and I have the source code to know what I am testing.
Just pointing out that the example snippet won't guarantee you 100% accurate results. In case the person asking the question didn't realise that.
You're very much at the mercy of the development team with stuff like this. Especially as most Delphi applications these days tend to be fairly mature. So various different devs will have worked on them. Each with slightly different ideas about how things should be done. So you end up with 6 different ways of achieving the same thing! That's certainly been my experience with a mature Delphi application .....