I don't think performing automated testing based on mouse location is a good idea either. I only suggested using the DisplayHost because Sandro mentioned simulating mouse events in his original email. If we all agree that it isn't a good approach, it is probably not worth pursuing.

On Sep 23, 2009, at 9:49 AM, Todd Volkert wrote:

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


Reply via email to