SmartGwt and Gwt-Highcharts - sizing issue

[Anthony McCulley]

I've managed to work around several of the rough edges:
1) Clicking on points by using the slightly altered .js you have provided until Highcharts releases their update with the fix
2) Hiding / showing charts on tabs and layouts without bleeding through other tabs

However, I'm having an issue with sizing and ensuring charts fill 100% of their container layout. The width works fine, but I can't seem to get the height to change unless I set the height manually with some int value which is difficult to do on resizing due to calculations with borders, padding, etc.

If I do nothing and simply allow Gwt-Highcharts to apply whatever default sizing it has, it still only fills the width of the containing layout (VLayout), not the height. Of course, by default, resizing the browser or layout causes issue... almost as if reflow isn't working correctly.

To fix this, I've created a custom Layout called HCLayout that extends a VLayout and has a couple of callbacks (this is how I fixed hide/show and fixed resizing the browser / layout). This has setReflow set to false for the chart since I handle it manually. On resize events, I call setSizeToMatchContainer() on the chart but, again, this seems to only work for the width and not the height.

I'm using SmartGwt 3.1p
Gwt 2.5
Firefox 10 ESR, Chrome
I've used the highstock.src.js you have posted in other threads to fix the click issue on charts.

[Aleksandar]

Same problem(s) to me. About the sizing, the problem is that at the moment of creation of smart gwt panels, gwt will return back zero height, so highcharts will automatically compute default chart height which is 400px.
Some work around that worked for me was to set size of Chart object with gwt Scheduler.get().scheduleDeferred, something like this:

Scheduler.get().scheduleDeferred(new Scheduler.ScheduledCommand() {
        @Override
        public void execute() { 
            chart.setSize(chartWrapper.getWidth(), chartWrapper.getHeight());
        }
    });

For future resizing, I had to to register handler in smart gwt widget resizing events, and then update chart size:

chartWrapper.addResizedHandler(new ResizedHandler() {

        @Override
        public void onResized(ResizedEvent event) {
            chart.setSize(chartWrapper.getWidth(), chartWrapper.getHeight());

I think that gwt highcharts creates its on container div to hold the chart, which doesn't know how to handle with smart gwt widgets (and doesn't know how to read parent container size) ...

        }
    });

[Anthony McCulley]

Yes, I thought of doing this as well but it gets complicated when the container has decorations and/or css applied (borders, padding, etc).

[Anthony McCulley]

Made some progress on this.
SmartGwt has a very helpful function in the API:
getInnerContentWidth() and getInnerContentHeight()

These calls return exactly what we are looking for - the amount of space available to things inside the container with space for padding, borders, decorations, etc already accounted for.

Once using this, I then noticed a couple of new nuances with the gwt-highcharts api.
Calls to setWidth and setHeight separately doesn't work as desired. I'm now calling setSize on the chart and this is working much better than before.

The only issue I'm seeing now is that some charts don't resize correctly if I press the maximize button on the browser (FF10 ESR - haven't tested with others). If I slowly drag the window, it seems to work fine and the calcs are right. If I just press the min/max button on the browser, it doesn't always work. It definitely changes size, but some stuff is cut off or a scrollbar is present. I'm going to toy around with calling this using a deferred command or something and see if that clears it up.

My approach:
Created a custom class called HCLayout which extends VLayout (could be HLayout just the same). In there, I've added 3 listeners: resizedHandler, drawHandler, and visibilityChangedHandler. In each of these, I make a call to resize the chart to the innercontentWidth and height of the HCLayout. I also perform hide/show on the chart in the visibilityChangedHandler and this seems to work fine without having to mess with z-index or moving the offset of the charts. Tested on tabs and panes at least with no problems.

Will try doing this with deferredCommands and see if it clears up the final glitch.

[Shawn Quinn]

Have you given the "ResizeableChartCanvas" noted in this thread a try? That's the technique we use here for keeping chart sizes consistent within a SmartGWT application, and have had fairly good results:

http://sourceforge.net/p/gwt-highcharts/discussion/general/thread/c06210f1

[Anthony McCulley]

Hadn't seen the thread but this is essentially exactly what we did. I'll try extending WidgetCanvas as you have instead of the heavier Layout.

Not sure what the difference is but this works. We were using the exact same handlers and logic and the only difference being that we extended from WidgetCanvas like your code and it works.

Brilliant! Cheers.

[Shawn Quinn]

Good deal. Yeah, WidgetCanvas is the magic sauce within SmartGWT for embedding external "regular" GWT widgets within a SmartClient managed container. Glad that solution is working for you!