This question already exists:
Closed 10 years ago.
Possible Duplicate:
in Chrome not getting an onClick() on a FocusPanel when focus was on a TextArea that has registered onChange and onBlur handlers
In my GWT app I register a BlurHandler on a TextArea so that I can save the changes and go from edit mode back to view mode if the focus moves elsewhere. This works, but also seems to defeat the effect of the event that moved the focus, at least on Chrome in devmode. For example, if the user clicks on an Anchor, the TextBox gets the onBlur() and then the Anchor does not get the onClick(); whereas before I registered the onBlur, the Anchor would get the onClick(). This seems to be quite reliable (again, in Chrome in devmode). I am being careful to not call event.stopPropagation() or event.preventDefault(). Any ideas how I can get the onBlur and also the onClick() ?
I had a similar issue. I was not able to track the source problem though. I did enable dev toolbar / firebug and set event breakpoints to test; it does look like the click event was not triggered after the blur action. After playing around for many hours (and I'm not quite sure what inspired me to try this), I dropped the onblur action in a timer with executed delay at about 300ms. That seemed to work for me. I think it might have something to do with the fact that my action slightly modified the page and visibility of items, witch re-rendered the page and I can only guess that the single-threaded browser model killed the click event which was not longer on the right area.
textBox.addBlurHandler(new BlurHandler()
{
#Override
public void onBlur(BlurEvent event)
{
Timer delayTimer = new Timer()
{
#Override
public void run()
{
//do stuff
}
};
delayTimer.schedule(300);
}
});
anchor.addClickHandler(....)
Related
I want to set the focus to a certain field (org.gwtbootstrap3.client.ui.Input) in a dialog (org.gwtbootstrap3.client.ui.Modal) before the dialog shows up. The use case seem quite common, if you have a dialog with a single field like the Upload text or Add feed dialogs right here. However I could not figure out how to set the focus to this particular gwtbootstrap3 component.
The Input component does have a setFocus(true) method. I assumed that setting the focus before showing the dialog would not work, which it doesn't. So the logical solution is to put the method call inside a ScheduledCommand. Like this:
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
#Override
public void execute() {
textField.setFocus(true);
}
});
That usually works with GWT standard components, but does not seem to help in this case. I found a way to get notified once the dialog is shown through a ModalShowHandler. Like this:
modal.addShowHandler(new ModalShowHandler() {
#Override
public void onShow(ModalShowEvent evt) {
textField.setFocus(true);
}
});
I even tried to combine both, adding a deferred call to the handle. No luck. Any ideas?
You should be listening on the ModalShownEvent (note: Shown, not Show).
ModalShowEvent is fired when the modal is requested (for example, programmatically) to be shown.
ModalShownEvent is fired when the modal is actually shown.
This somewhat confusing naming is based on the events of the native Bootstrap Modal's events: show.bs.modal and shown.bs.modal.
ModalShownEvent combined with the usual Scheduler#scheduleDeferred should do the trick.
can anyone please explain to me why the html SELECT control (or any other control like BUTTON) placed inside the div (that is registered with dojox/gesture/swipe events) cannot be opened? I'd welcome any workarounds pls
require({
}, [ 'dojo/dom', 'dojox/gesture/swipe', 'dojo/on', 'dojo/_base/event' ], function(dom, swipe, on, event) {
var div = dom.byId('testSwipe');
var isSwipe = false;
on(div, swipe.end, function(e) {
console.log("### SWIPE");
});
});
http://jsfiddle.net/zLyck884/
based on the documentation here, particularly the image : http://dojotoolkit.org/reference-guide/1.10/dojox/gesture.html
the image depicts how the dojo standardizes the events (also for desktops) and how the swipe is just another layer of the touch events. so I reckoned if the mouse events are replaced by touchstart or something, then it most likely blocks the default mouse action...
once I've stopped propagating the event (on the SELECT) further, then it worked ok.
query("select", this.domNode).on(touch.press, function(e){e.stopPropagation()});
where this.domNode is the element on which the swipe is enabled
on(this.domNode, swipe, lang.hitch(this, "_onSwipe"));
Unfortunately the swipe (touch) event overriding the default behaviour is not very handy, I just left dojox/gesture/swipe or touch for now. Seems like I'll rather implement my own touch event handling.
Does anybody have an idea on how I can accomplish this using Wicket?
I want to display a Wicket odal window automatically when no user activity has been detected for a certain amount of time. I'm thinking of using an AjaxSelfUpdatingBehavior in some way, but I have no clear ideas actually.
Is this possible with Wicket?
Also, you can use some js library not to catch all ajax calls and to be sure, that your user is really afk (even does not touching his mouse).
For example, see this free framework and it's demo.
And (if you using this js framework) in wicket you must handle
ifvisible.idle(function(){
Wicket.Ajax.get({u: '${callbackUrl}'})// This code will work when page goes into idle status
});
You must set ${callbackUrl} from wicket code to let js know what action to proceed in java code. It is not hard to do this. Look here.
This approach is more tricky, but if you implement this, you don't have to worry about users actions at all (he can read site's info and don't click any ajax links, but suddenly he will see modal window).
Yes you can, I use this as autologout function
public class MyTimer extends AbstractAjaxTimerBehavior {
public MyTimer(int seconds) {
this(Duration.seconds(seconds));
}
#Override
protected void onTimer(AjaxRequestTarget target) {
// show your window magic
}
}
Add this to you page (add(new MyTimer(300));) and this will be called after the number of seconds you specify. Make sure to replace the timer with a new one when doing ajax calls, or reset it.
First off, before the flames start, I do know that trying to hinder the back button in the browser is a dumb idea. I would not try to do this, but my business partners are very insistent on it. We are porting an existing .exe to the web and their definition of this is 'run it in a browser' and not "make it a web site". So, fact that it's a bad idea (I agree), here's the question:
Is there a way to ignore or trick the GWT PlaceController / History manager mechanisms so that when the back button is pressed, it just stays on the same page?
I have used Window.addWindowClosingHandler to add a handler which will prompt the user if they want to leave the page and overriden the newItem() method of the defaultHistorian so that no history is tracked at all, but this isn't quite what the business people want.
What they'd like is to just ignore the back button so that nothing happens when it is clicked.
If anyone knows how to do this with GWT, I'd be very grateful.
And I"ve done a lot of google searching and haven't found anything exactly like this question. At least, not close enough to help.
I was able to get GWT to not accumulate any history so that when the user presses the BACK button, they cause an onWindowClosing event to happen and the Browser will prompt them if they want to stay or leave. This will accomplish the goal of not allowing the BACK button to take them back, but it's a bit Draconian. This code does that:
class TvHistorian extends PlaceHistoryHandler.DefaultHistorian
{
#Override
public void newItem(String token, boolean issueEvent) {
// don't do anything - this will prevent history from accumulating
}
}
final PlaceHistoryHandler historyHandler = new PlaceHistoryHandler(historyMapper, new TvHistorian());
I've tried a bunch of stuff including extending the PlaceController.goTo() to save the "lastNormalFlowPlace". Then, I tried to override the History.onValueChange to use this saved Place if it was different than what the event specified. But I think I missed some subtlety because that didn't work as expected.
With the above exception, my code looks almost exactly like what is documented here: http://www.gwtproject.org/doc/latest/DevGuideMvpActivitiesAndPlaces.html#Putting_it_all_together
I have already posted an answer in the same context.
Please have a look at below links:
promt user on backspace and browser backbutton in gwt
how can i get a prompt on url change
Disable back button in GWT
Try with any option:
History.addValueChangeHandler
WindowClosingHandler
Event.addNativePreviewHandler
$wnd.onbeforeunload
--EDIT--
Sample code: (It's working perfectly fine in Firefox, Chrome as well as IE9)
Note: add below code in the beginning of the onModuleLoad() method.
final String initToken = "Place";
History.addValueChangeHandler(new ValueChangeHandler<String>() {
#Override
public void onValueChange(ValueChangeEvent<String> event) {
String token = event.getValue();
if (!initToken.equalsIgnoreCase(token)) {
History.newItem(initToken);
}
}
});
// fire the initial history state.
History.fireCurrentHistoryState();
Note: add checks for other allowed history tokens.
I have a question regarding the event handling on client side in GWT.
In our application we have a quite complex structure of different modules and pages which are communicating via the gwt eventbus on client side. Now the amount of events is growing to fast for my opinion. E.g. I am opening a popup I need:
An event for opening the popup
An event for asking some data within the client
An event for getting back the data and fill in the dialog
An event for closing the popup
An event for handling the save Button
Am I thinking a little bit to complicated or missing something in the EventBus implementation? I just wanted to have some feedback out of the community as you are facing the same issues.
For what it's worth, I have lots of events and more growing. And yes, I wonder if I can do with less, but when I skip an event and link elements directly, I regret it.
Here's an example that I just fixed up yesterday. I have a DataGrid widget. I also support re-ordering of columns, hiding of columns, re-sizing columns, and coloring columns with a popup dialog. You click on a configure button, and a popup with the columns listed shows, and the user can click checkboxes to show or hide columns, click on a Move Up / Move Down button to re-order columns, and so on. Hit Apply on the popup and the popup disappears and the DataGrid re-configures.
Except that it didn't. You'd click on Apply and the popup would just sit there, the user would wonder what was going on, the DataGrid would re-configure underneath, and then the popup would go away. We're only talking a short amount of time -- maybe a second or a bit more -- but it was so so noticeable. Why was it happening? Because I got lazy and tied the popup directly to the configure button, and the Apply button directly to the DataGrid. You'd hit Apply, for example, and the call would be made to the DataGrid with the new configuration information. Only when the call returned would the popup would be torn down.
I knew it was bad when I did it, but I was being lazy. So I took the 20 minutes I needed to write up two messages and associated handlers in my mediator singleton. One message is issued by the DataGrid to start the configuration dialog, and one is issued by the popup to configure the DataGrid. Now the widgets are de-coupled, and the performance is much snappier. There is no sense of "stickiness".
Now to your example, can you not combine (1) and (2)? And also (3), (4), and (5)? When the user clicks the configure button on my app, the event carries with it the current configuration information (including a reference to the DataGrid that originated the request). You can call this information the "payload". When the user clicks the Apply button on the popup, the event payload includes all the new configuration information (including a reference to that original target DataGrid) that the event handler feeds to the target DataGrid when the event is handled. Two events -- one to kick off the configuration and one to apply the end result.
Yes there are a plethora of events in any app that does something interesting, but events can carry a lot of information, so I would look at whether your event organization is too fractured.
As a extra bit, here is the code I use. I shamelessly copied elements of this pattern from one of Google's examples.
The user can ask for help using a menu item:
#UiField
MenuItem help;
help.setCommand(new Command() {
#Override
public void execute() {
BagOfState.getInstance().getCommonEventBus().fireEvent(new MenuHelpEvent());
}
});
For the event (in this case, the event fired when the user clicks on the Help menu item):
public class MenuHelpEvent extends GwtEvent<MenuHelpEvent.Handler> {
private static final Type<Handler> TYPE = new Type<Handler>();
public interface Handler extends EventHandler {
void doMenuHelp();
}
#Override
public GwtEvent.Type<Handler> getAssociatedType() {
return TYPE;
}
#Override
protected void dispatch(Handler handler) {
handler.doMenuHelp();
}
public static HandlerRegistration register(EventBus eventBus, Handler handler) {
return eventBus.addHandler(TYPE, handler);
}
}
I have a singleton called Mediator in which ALL events are registered:
MenuHelpEvent.register(BagOfState.getInstance().getCommonEventBus(),
new MenuHelpEvent.Handler() {
#Override
public void doMenuHelp() {
new MenuHelp().execute();
}
});
Every event is mated with a Command object to do the work:
public class MenuHelp implements Command {
#Override
public void execute() {
new InfoMessage(BagOfState.APP_MSG.unimplementedFeatureCaption())
.setTextAndCenter(BagOfState.APP_MSG.unimplementedFeature());
}
}
Everything is decoupled. The menu widget is bound to a command that executes and then completes. The command fires the event on the bus then completes. The event fires off the execution of a Command and the completes. The Command shows the popup help panel (in this case, an "unimplemented" message to the user -- yeah, I'll get to it soon). Every interaction with a user's input is handled extremely quickly and resolves. It can kick off a series of events to perform a long action, but never tying up the GUI to do so. And of course, since the elements are decoupled, I can call the same elements in other places (for instance, call the help Command through a button push as well as a menu item).