Open GoogleCodeExporter opened 9 years ago
Original comment by Brad.Ryd...@gmail.com
on 1 Jun 2010 at 9:40
Marking this as low priority because there is a workaround.
You can use the OpenEvent and Double click for PC / Mac / Linux. For IPad you
can use the SelectionEvent, which is triggered by a single click. Use deferred
binding to handle selection events as if they were OpenEvents for user agents
that match IPad
Original comment by Brad.Ryd...@gmail.com
on 22 Jun 2010 at 8:06
Workaround is not usable; it is not possible to distinguish drag from click,
even with a timer.
Further, gwt-cal does not distinguish selection of already-selected
appointments from initial selection.
Having said that, an alternative implementation will provide the needed
capabilities. Specifically, implement ONCLICK events in exactly the same way as
ONDBLCLICK, i.e.:
* In InteractiveWidget, sink ONCLICK (and process similarly to ONDBLCLICK, i.e. abstract onClick).
* In CalendarWidget, implement onClick as per double click.
* In CalendarView, provide abstract onClick as per double click.
* In DayView/MonthView/AgendaView, provide onClick similar to double click. This can fireOpenEvent or (my preference) fire a new event. Do not perform timeBlockClick if the click is not on an appointment.
Event superstructure is required, of course.
A suggested, albeit untested, patch is attached. (It has been tested in a
different form, using subclassing of gwt-cal instead of patching the source.)
Original comment by grmcdor...@gmail.com
on 14 Jan 2013 at 4:41
Attachments:
To add to the above comment: gwt-dnd inhibits click events as soon as a drag is
initiated. Specifically, ONCLICK does not fire if the user starts dragging the
appointment.
As such, ONCLICK is perfect for the requested functionality.
Original comment by grmcdor...@gmail.com
on 14 Jan 2013 at 4:47
I have noticed that the implementation in the patch has an issue; specifically,
it uses the name 'click' (ClickEvent, ClickHandler, HasClickHandler). This
causes ambiguities with the standard GWT ClickEvent & friends.
Renaming it to CalendarClickHandler resolves the problem.
Original comment by grmcdor...@gmail.com
on 14 Jan 2013 at 7:20
Original issue reported on code.google.com by
doom777
on 30 May 2010 at 3:37