If the display host reported its position on the screen, then you could get around the screen resolution issues, because the display host's screen position would be your starting point, then you could combine that with component locations to know where to place the mouse. Greg can comment on how tough it'd be to report the display host's screen position (or if we we already do).
-T On Wed, Sep 23, 2009 at 9:32 AM, Sandro Martini <[email protected]>wrote: > Hi to all, > > > I forgot about that class! > Me too :-) , I've never used directly but now I remember this could help. > > > It literally takes over the mouse and lets you do things with anywhere > > on your desktop, not just Java apps. To make it really useful you'd > > have to work out where the Pivot components you wanted to click were > > relative to your desktop space which might be tricky if running in a > > Web browser, but probably less tricky when running directly on the > > desktop. > Ok, but with this approach I don't like the click on a certain screen > position ... many tools use this way but there are problems, for > example the screen (and application, and fonts, etc) resolution has to > be fixed, etc ... > > But my idea was more in line on how Pivot expose objects (I hope to be > right here :) ), like from my Test Runner (or more in general from an > external application, that for some things could be Javascript in the > Browser if I'm running one or more Applets) if i could refer to any > Pivot element by using its ID as defined in WTK files, and them call > its public methods to make some automatic work. > For example: in a wtk file I have a Form with id "form1" containing a > List with id "list1", a TextInput with id "text1", and a Button with > id "button1". > So from my application if i could get an handle to the Pivot > Application/Applet, then i could get a reference to the form1, call > its load method to make it load data from servers, then get a > reference to list1 , and call its method to select the second element, > then get a reference to text1 and via its methods, move the focus to > it and set some text inside it, and finally, get a reference to > button1 and make submit ... then send a keystroke to select another > element (for example another Tab), etc ... > > This could also be an interactive work, like in a Console ... or better: > could also be an interactive Test Mode for our future GUI Builder. > What do you think ? > > > In this way we could also expose a sort of Macro/Scriptable System for > Pivot (without a macro language, ok but this is a detail at the > moment) ... cool. > > > This idea is a little rough at the moment, maybe after some discussion > could be more clear ... > > > > We don't currently allow a caller to simulate mouse clicks via a Pivot > API, though you might be able to do so from the DisplayHost. > Interesting. > > > An automated testing framework for Pivot would certainly be valuable, > though I personally don't see it as a high priority in the short term. > However, you are more than welcome to pursue it if it is something that > interests you. > Ok, also for me is a low priority, If this interests I could add a > ticket in JIRA under tools, for 1.5 (minimum ...). > > > > Thanks, > Sandro >
