#2 CLICKAT: click at a point with real mouse messages instead of calling Click

[Thomas Mueller]

CLICK calls the control's Click method. That is right for a button and wrong for anything whose behaviour comes out of the mouse message itself: hit-testing inside a grid, list or tree view, a control that reads the shift state, drag handling, or a click that has to land on a particular pixel.

Seen in practice: the page tree of the IDE's Options dialog (TTreeView) cannot be switched to another page with GxInspect, so a test had to click it with real mouse input from outside.

Proposed: CLICKAT <form-id> <control-name> <x> <y> [<shift-state>], posting WM_LBUTTONDOWN/WM_LBUTTONUP at a point given in control coordinates.

• A TGraphicControl has no window handle, so the message has to go to its parent with the point translated.
• Posted messages are not the same as real input for some controls; if that turns out to matter, real input (SendInput) needs the same foreground handling as the proposed KEYS command.
• Risk: real input can put the IDE into a state a script cannot get it out of, which Click cannot.