You should be able to refer to any Java class from within JS. The JS
engine automatically provides the wrappers.
On Sep 25, 2009, at 8:39 AM, Sandro Martini wrote:
Ok, I'll try, but don't know if Robot is callable from the Javascript
engine ... or if a wrapper is needed.
I'll try and say som
Ok, I'll try, but don't know if Robot is callable from the Javascript
engine ... or if a wrapper is needed.
I'll try and say something ...
Bye,
Sandro
Yeah - Robot is the way to go for low-level events like keyboard and
mouse. For semantic events, you can just invoke the appropriate Pivot
API methods.
On Sep 25, 2009, at 6:42 AM, Todd Volkert wrote:
Again, I'd use java.awt.Robot for that. It defines keyPress() and
keyRelease().
-T
On F
Again, I'd use java.awt.Robot for that. It defines keyPress() and
keyRelease().
-T
On Fri, Sep 25, 2009 at 6:37 AM, Sandro Martini wrote:
> Hi Greg,
> thanks for having already implemented this feature, i hope to find
> some time soon to try it !!
>
> Only one question, on this:
> do you think
Hi Greg,
thanks for having already implemented this feature, i hope to find
some time soon to try it !!
Only one question, on this:
do you think it's possible from an "automation client" (for example in
Javascript, and for simplicity running in the same process) to send
also other events, like key
Hi Greg,
>> I've seen that Greg has just entered a JIRA ticket for this.
>> Is needed some comment inside ?
>
> If you think the ticket requires additional detail, feel free to add some.
Ok, I'll think at something for tomorrow.
> You don't need to run an application in the browser to script it
I've seen that Greg has just entered a JIRA ticket for this.
Is needed some comment inside ?
If you think the ticket requires additional detail, feel free to add
some.
Rather than creating a new macro language, why not simply take
advantage of the existing scripting facilities in the JVM?
Hi to all,
thanks for your comments, and I'm happy you like the idea ...
I've used products that used mouse positioning and clicks, but many
problems occurred.
So, from my experience, i think too that the approach of the
(optional) automationID could be the right approach.
I've seen that Greg has
>
> With Pivot the testing tool should just be able to introspect the
>> component hierarchy to find whatever it likes anyway (I want to say
>> XPath, but you know what I mean).
>>
>
> The main problem with this approach is that, if the layout changes (such
> that a button no longer exists at a par
Depends what you're doing, I suppose, but I wouldn't want to litter my
code/WTKX with automation names, or at least it should be optional.
I agree - this property should be optional. I imagine it would be
added by QA teams during testing.
With Pivot the testing tool should just be able to i
2009/9/23 Greg Brown :
> WTKX IDs are not exposed outside the serializer (except via the serializer's
> Dictionary interface). We could try to repurpose them to suit this use case
> as well, but I don't think that's the right approach, since it would
> preclude performing automated testing on UIs t
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 Se
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 t
WTKX IDs are not exposed outside the serializer (except via the
serializer's Dictionary interface). We could try to repurpose them to
suit this use case as well, but I don't think that's the right
approach, since it would preclude performing automated testing on UIs
that were created in cod
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 comp
I forgot about that class!
Yes, it absolutely does let you do mouse events and key presses - I've
used it for some quite dangerous things over the years! ;)
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
Why not just use java.awt.Robot? I'm not 100% sure, but I think it has the
ability to simulate mouse events and key events.
-T
On Wed, Sep 23, 2009 at 7:55 AM, Greg Brown wrote:
> All component behaviors in Pivot are invoked by public APIs. So, from your
> examples, you could do:
>
> button.req
All component behaviors in Pivot are invoked by public APIs. So, from
your examples, you could do:
button.requestFocus();
button.press();
listView.setSelectedIndex(0);
menuItem.press();
textInput.setText("foo");
We don't currently allow a caller to simulate mouse clicks via a Pivot
API, thou
Btw, sorry for the typos, was replying on my phone.
Cheers,
Chris
2009/9/23 Christopher Brind :
> It's a good idea, I think. Flex has this, so or wouldn't be unique to Pivot.
>
> Probably the Pivot component set should be atom atable (that a word?), and
> all ow custom components to be automtable
It's a good idea, I think. Flex has this, so or wouldn't be unique to Pivot.
Probably the Pivot component set should be atom atable (that a word?), and
all ow custom components to be automtable if they want through a help API
that Pivot provides.
We could even write an automated testing tool usi
20 matches
Mail list logo
