Even if screen resolution varies, if you can get the size of the buttons that are visible, and the size of the container ribbon, you should be able to calculate it.
I have to do similar with some grids I use. I don't know how many rows there are, how many will be visible, and how tall each row will be. I simply have to iterate through them adding all the heights together, and then relate that to the overall size of the container grid. It's a bit of a pain, but I have no other way of doing it. But it works regardless of the resolution the application is run at. The grid accepts click events, but cells don't. So I have to calculate the relative position within the grid to apply the click to. Same with a non-standard tree checkbox object. Get the node. Get it's size. Calculate an offset to hit the checkbox.
"I don't mind having to do it, but the tool, TestComplete in this case, should be able to do it by itself when needed."
Which is true, and fair enough.
But the test tool can only get the information available to it. And controls can only accept the methods allowable to them. If something (in my case, a Delphi "cell" object within a grid) does not accept click as a method, then it doesn't. Not much you, I, or TestComplete can do about it. Throw a control an unknown method, and it'll throw you an error back.
Same with properties. If a control does not expose certain properties, then there isn't much you can do about.
It's a hassle. But sometimes you need to doo calcs like that. I spoke to our Delphi devs and even they have to calculate relative co-ordinates and offsets to activate certain event triggers in parent objects and so on.
Still, as you say, keeps life interesting! :)
