Why does Mouse.ClickControl not automatically gain focus?

[Duncan Scott]

Hi,

I've just been having a look at Ranorex as a potential replacement for our old automation software.

I had a look through the VS2005 sample with the calculator and had a tinker.

Having looked a bit more into it, it looks like the best way of clicking something is to actually cast the clickable object from Control and then call the Click method, which bypasses the mouse. This way of doing it means you don't have to have the application in displayed. So shouldn't this be used in the example instead of the error prone "Mouse.ClickControl"?

If the application is minimised for some reason, Mouse.ClickControl just clicks where the Control used to be, and even returns a value indicating that the click was successful. So I was also just wondering why "Mouse.ClickControl" doesn't make sure the Control is there for it to click before it does the action? Otherwise whenever you use it, to be safe, you have to check Focused and the call Show() if the application is minimised (calling Focus() doesn't seem to bring the application up from the taskbar).

Many thanks.

Duncan

[Support Team]

Hi Duncan,

the question is what you are using Ranorex for. If you just want to automate your GUI, you're right, the Mouse.Click should bring the control to foreground then. However, if you use Ranorex to test a GUI application, the automation should act as realistic as possible, just as if a human user would control mouse and keyboard.

Imagine a bug in the tested application that randomly minimizes the application. Your Ranorex test code assumes that the application stays in foreground as it should. If the application minimizes itself during the test letting the mouse click go somewhere, either a validation or one of the next automation steps should fail indicating the bug. If Mouse.Click would bring the application/control to foreground, this bug would never be found.

Having looked a bit more into it, it looks like the best way of clicking something is to actually cast the clickable object from Control and then call the Click method, which bypasses the mouse.

The same is true for this issue. The Button.Click method is nice, because it works even if the button is not visible (by sending a window message to it), it is not realistic, though. You can't be sure that a physical mouse click (simulated by Mouse.Click) has the same effect on the button as the Button.Click method. The method is provided for automation, not for testing purposes.

I hope this answers your question

Regards,
Alex
Ranorex Support Team

[Duncan Scott]

Ok, that seems fair enough I guess .

But think what surprised me was that there was no error code either or perhaps an Exception.

The function says it returns an error code, so I thought this would perhaps indicate if the Click had failed to activate the Control it was targetted at. Otherwise, I'm not sure what the point of it is. It seems like a useful error to return, otherwise you end up having to put "if" statements everywhere in your code to see if controls are accessible, when the ClickControl function could integrate this check for you and return an error code if it couldn't see the Control to click on it.

Cheers,
Duncan

[Support Team]

The Mouse.Click(Control) method returns an error if the control's screen rectangle cannot be determined, for example, if the control does not exist any more.
But you are right, the method could/should indeed check if the control is clickable, i.e. if it is in the foreground. I added this issue to our wanted features list.

Regards,
Alex
Ranorex Support Team

[Duncan Scott]

Thanks very much .