Any idea how I can fire the blur even just after the focus event, such that it doesn't occur "loosly coupled" (the actions are send one-by-one to the selenium server).
Let me explain:
In Selenium RC you fire the blur and focus through fireEvent(locator, "blur") and fireEvent(locator, "focus"). However, after the blur event is send to the browser the focus event doesn't directly follow the blur event in the javascript command stack. This is a problem is in the following case: detecting the blur of a group of widgets, like a group of textboxes.
What I do: all text boxes share the same listener and when a blur occurs I simple run an additional command that checks if a focus event was captured by one of the textboxes, if so, you ignore the blur. This additional command that I run in javascript is automatically executed after all waiting commands are run, in this case, a focus command is one of these waiting commands.
Back to Selenium RC: after the blur event is fired by the Selenium server, it waits for the next command, in this case the focus event and will fire it. However, as you can understand, in the mean time, the addiontal command already has been fired and no new focus event has been detected. As such, a group-blur is detected and handled, in this case however the blur is incorrectly handled as the focus isn't fired directly after the blur, such as a browser would do....
I hope you understand my problem as it's a bit hard to explain.
Any idea's on how to solve this? so I can test the correct behavior? (no my validation takes place too early as a group-blur isn't correctly captured)
I think the way to solve this: send a piece of javascript to the Selenium server that will be evaluated and will fire both events after eachother. Or not?... And you how would I do this?
I belive you are looking for:
selenium.getEval("[my JavaScript here]");
You can send a javascript snippet of your choice to get evaluated by the browser, this should enable you to chain a focus and blur into one command.
Related
I'm trying to make a program which can send mouse input to a Runescape applet. Before you ask what I want this for, it isn't a bot. I'm making a "Twitch Plays Pokemon" program for Runescape which has been confirmed to be allowed.
Anyway, I have created a loader which will pull the game jar from the website and open it in a JFrame, meaning that I have an Applet instance which contains the game. I need to somehow dispatch mouse events to this applet. I've looked everywhere but whenever I search for this, I just find pages about listening for mouse clicks instead of dispatching them...
I should note that the Robot class isn't what I'm looking for; the mouse actions must be virtual and run within the application. I know this is possible but I'm struggling to find out how it's done.
How can I accomplish this? I want to be able to send mouse hover events as well as right/left click events.
I've found my answer, guys. It was quite simple. This is what I did to perform a mouse click on the applet:
applet.getComponent(0).dispatchEvent(new MouseEvent(applet,
MouseEvent.MOUSE_PRESSED,
System.currentTimeMillis() + 10,
MouseEvent.BUTTON1,
x,y,
0,
false));
applet.getComponent(0).dispatchEvent(new MouseEvent(applet,
MouseEvent.MOUSE_RELEASED,
System.currentTimeMillis() + 10,
MouseEvent.BUTTON1,
x,y,
0,
false));
The thing to note here is the applet.getComponent(0) part which was actually directed at the game canvas.
You can probably do this with the java.awt.Robot class. I've never done it but it seems like it would work.
You could use JNI and the Windows API (assuming this is all running on windows, other platforms probably have similar corollaries) to send simulated mouse events to just that window.
You can use Spy++ to monitor the messages being sent to that window. You can use FindWindow to get the window's hWnd, and then use SendMessage or PostMessage to send the simulated mouse events.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633499(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx
Hi zk provide Drop event, but we need drag event for Calendar.When user drag content in that time some available field will be display, after drop it will be remove.
Zk doesn't provide a drag event at all.
So you have to use jquery to a add one to your component and fire
a zk event your self. Here is a short jq guide for dragging. Number 6
looks like the stuff you want to do.
Now, you could send an zk event in the callback method.
But, I think if you try to update the UI at server side, you
could get problems, because of zks repainting. I never
done this my self, so you have to try. But for sure, you
could mark the droppable areas at client side so you won't
have this problems.
If you try what I just discribed, please tell us your experiences
or problems, so that I/we can help.
GXT 3.x only.
It is becoming apparent to me that Sencha had deliberately designed FileUploadField to shunt off all key press events from ever being detected.
I tried to intercept onBrowserEvent(Event) and could not detect any key press events which I would have generated by keypresses while having focus on the FileUploadField component.
Where is the key-press event shunt?
I could not find any keypress handler insertion methods.
I wish to allow triggering the file upload by either press on the space-bar or enter key.
Short of rewriting a whole new component from scratch, could someone advise me what I could do to achieve my goal of a keyboard activated file upload?
onBrowserEvent won't recieve any events unless you sink them - did you make sure to call sinkEvents? How are you adding handlers? If you use addDomHandler, it will sink them for you, but addHandler either assumes that they are not dom events, or that you already called sinkEvents. Without sinking an event, the browser doesn't know to pass that event on to a GWT widget. If all events were sunk automatically, then every time you moved the mouse across the page you would see a firestorm of events as mousemove fired for every widget you passed, and all of its parents.
If you override onBrowserEvent, then you are building the method that describes how to handle the actual event that comes from the browser - that is where the com.google.gwt.user.client.DOM class wires into the Widget to give it events. Short of making that method final, there is no way to prevent you, the widget user, from getting those events as long as the browser is generating them and passing them through the event listener.
Even if onBrowserEvent has been overridden and made final, you can still get access to many events by creating a NativePreviewHandler and checking where the event is occurring. This gets you in to the event before it even goes to the widget itself - there you can call NativePreviewEvent.cancel() to prevent it from happening on the widget itself, or you can handle it early in the handler.
I have a design related question that I am trying to find an answer to.
Here is the scenario.
Suppose that you want to do something expensive (time-consuming) as a result of user input (e.g. loading huge amounts data from some database, reading large files). The strongly recommended way is to do the time-consuming work in a separate thread and never ever block the EDT, or else the GUI will become unresponsive.
There are scenarios however when you should not provide inputs to the GUI unless the background task is finished. In my specific case, only after the background work is finished, I can determine which GUI elements should be visible and enabled/disabled. Only those GUI elements which should be visible and enabled should respond to the user inputs otherwise the behavior may be unpredictable in my specific case.
This is what I am doing to handle such a scenario.
Step 1: Before I am about to start a time-consuming operation.
Change the cursor to a busy cursor.
Add mouse listeners to the glasspane of component's top-level frame.
Make the glasspane visible so that it can receive mouse events. The glasspane doesn't do anything as a result of mouse inputs.
Step 2: Execute the time-consuming operation in a background thread. The background thread has a finally block that notifies the event thread when the job is finished (completed or aborted due to an error).
Step 3:
Switch the mouse cursor back to normal.
Remove listeners from the glass pane.
Make the glasspane invisible, so that mouse events go to their intended recipients.
Is this the correct approach to handle such situations?
What do you guys recommend?
SwingWorker can be used in this context. Related controls can be disabled when the background task is started and re-enabled in done(). In this related example, the run button is conditioned to toggle between "Run" and "Cancel".
Addendum: A back-port to Java 1.5 is available here.
I'm experiencing some strange behaviour when using a stylus with swing.
I am interpreting pressing the button on the side of the stylus(RIGHT) and pressing the stylus down(LEFT) as a "Grab" event, but occasionally (more often than 0), events are just being dropped.
The JavaDocs for MouseEvent are pretty explicit about how multibutton presses are handled if executed one at a time (left down, right down, right up, left up) but say nothing about simultaneous button presses.
I'm left to wonder, would they be emitted as two mousePressed events, or as one with the button mask set for both buttons, or something else entirely?
Thanks.
I'd interpret the API doc as simultaneous button presses being simply not possible:
When multiple mouse buttons are pressed, each press, release, and click results in a separate event.
So there should be separate events. The problems you observe could be due to errors in your code, the stylus' driver, the hardware, or Swing (this is in decreasing order of likelihood as I see it :)
I'd try to diagnose the problem by logging events at different levels, if possible.
Simultaneous button presses are processed as two separate mousePressed events. Run the Mouse Events Demo to see them processed separately.
As I recall, there's no way to handle simultaneous button presses. What I used to do to ensure that multiple buttons being pressed at once were treated as such was I would have a boolean variable for each button and when it was pressed, I would set it to true and when it was released, I would set the boolean to false. Then when it came time to perform an action, I would check for the boolean variables (sometimes I would have the actionlistener redirect to the method call for determining what action was to happen next after setting the booleans). This doesn't work if the only thing you want to do is them being pressed at the exact same time, but if you're just trying to get combinations to work, then that's how I did it. This was about 4 years ago, before Java 5, so I may be wrong about that.