Client-side GChart 2.6 Release Notes

Except for several bugfixes, this release is functionally equivalent to GChart 2.5. However, it replaces the deprecated ClickListeners with the equivalent but syntactically different ClickHandlers introduced in GWT 1.6. So, the main advantage of 2.6 over 2.5 is that it lets you eliminate the use of deprecated ClickListeners that will be dropped completely in GWT 2.0.

Developers upgrading from a previous GChart release will have to convert any GChart ClickListeners to ClickHandlers. This is exactly the same set of code changes you would require, say, for a standard button Widget. Specifically:

Replace:
  ClickListener
with:
  ClickHandler

Replace:
  onClick(Widget sender) {...}
with
  onClick(ClickEvent event) {Widget sender = event.getSource(); ...}


Replace:
  addClickListener
with
  addClickHandler

The above mechanical process works for the most common situation in which you never used removeClickListener. If you did, you will also have to save the HandlerRegistration reference returned by addClickHandler and invoke its removeHandler method in lieu of your previous call to removeClickListener. See this Chart Gallery code for an example. See the the GWT 1.6 upgrade docs for more info on these listener to handler conversions.

This release has been tested with GWT 1.7, and only works with GWT 1.6 or higher. GChart 2.5 is the last GWT 1.5 compatible release. The listener methods of GChart 2.5 are no longer supported at all in 2.6, even though ordinary GWT 1.7 still supports listeners via deprecated methods. I decided on this approach to save time, and to assure that early adopters of GWT 2.0 (which will finally drop the listeners altogether) would be able to use GChart 2.6 without error.

Detailed change log:

GChart now implements HasClickHandlers (SourcesClickEvents is no longer implemented)

The GWT 1.6 interface HasClickHandlers replaces the GWT-deprecated SourcesClickEvents interface, which GChart now no longer supports. Specifically, addClickListener and removeClickListener were dropped, and the new addClickHandler method (which, via its returned HandlerRegistration object, in effect provides a 'removeClickHandler', too) has been added.

See discussion above for further details on the specific changes you'll need to make to existing GChart click-event-related code.

Bugfix 1: Dropped widgets in unusual widget-reference-reuse scenarios

Using the exact same widget reference repeatedly (rather than creating a new Widget reference each time) could, in some usage scenarios, cause widget-based annotations, chart footnotes, or similar widget-defined features to be incorrectly dropped off the chart. Note that because, for efficiency, GChart can hold onto such references from deleted points, such repeated references/dropped annotations could occur without the developer creating them explicitly.

The problem occured because GChart did not account for the fact that, when a widget is added to the DOM in two different places, GWT automatically nulls out the first such reference (effectively, it moves the widget to the new DOM position). But this resulted in a situation in which what GChart thought was in the DOM, and what was actually in the DOM, were inconsistent. Because (to save time) GChart won't re-add a widget to the DOM if it thinks that widget is already there, this could result in dropped widgets.

GChart now explicitly checks for such inconsistencies and re-adds the widget to the DOM if that is needed.

However, using the same widget reference for two different annotations is still a bad idea, because there is no simple way to determine which point the widget will end up annotating, and such "implicit" nulling of DOM references won't set GChart's "needs update" flag. Therefore, an explanation of how GChart (now reasonably) handles, and how and why to avoid making, such repeated references was added to the setAnnotationWidget javadocs.

Tip: Users of earlier GChart versions can workaround the bug, if they have trouble, by creating a brand new Widget and assigning it to the annotation in question, rather than reusing the same widget reference.

Bugfix 2: Border around area charts was always 1px

Due to a bug, the stroked border around a polygonal area was always 1px wide.

This stroked border width is now correctly defined by the symbol's setBorderWidth setting.

Bugfix 3: IE 'color washout' when chart moved in DOM

In IE only, moving a GChart to a different position in the DOM resulted in previously rendered fill color, stroke color, and stroke thickness being reset to white, black, and 1px.

In the case in which a chart is inserted, removed, and then reinserted in the DOM, and the chart's rendering is up-to-date (its isUpdateNeeded method returns false) GChart will automatically re-render just those curves that are GWTCanvas rendered, so as to eliminate the washout effect.

Note that this bugfix generates a performance penalty associated with moving a GChart to a different DOM "slot" when that GChart does not require an update. If you are planning to make changes to the GChart after re-insertion, you can avoid this penalty by making those changes before re-insertion, and then updating the chart after re-insertion. Better, when it makes sense to do so, you can place the GChart onto an AbsolutePanel and change it's position on that panel, rather than changing its DOM "slot", to avoid these re-insertion related renderings entirely.

This bug was due to a bug in GWTCanvas (see issue #293 in the GWT incubator issue tracker). See TestGChart55.java and TestGChart55a.java for more information about this bugfix.