Tuesday, October 28, 2008

Mouse Capture and IFrames in GWT

In our application, we have some split panels... On one side is some nice, happy GWT content, and on the other is an iframe. Well, when you move the splitter, and your mouse gets out over the iframe, the splitter stops moving. Huh?

It turns out that the split panel is capturing the mouse when you start the resize. After a bit of digging, I noticed that for we just stop getting the mouse events when the mouse moves over the iframe. Googling turns up something kinda similar: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/36f70df2a52f42d2.

It was pointed out to me that if you drag a MyGWT-derived dialog box over the iframe, all is good. However, dragging a regular GWT-derived dialog box over the iframe exhibits the same problem.

Do some digging, and I find out that MyGWT is covering the entire browser window with a transparent panel. The dialog is parented to this panel. The panel adds an event preview, and only allows events to go through to the dialog.

Sounds ugly, but I give that a shot...when the split panel resize starts, create a panel, make it as big as the browser window, and then only allow events through if they're destined for the splitter:
RootPanel root = RootPanel.get();
setPixelSize( root.getOffsetWidth(), root.getOffsetHeight() );
DOMHelpers.setZIndex( getElement(), DOMHelpers.getTopmostZIndex() );
root.add( this, 0, 0 );
setVisible( true );
DOMHelpers.setZIndex( splitElem, DOMHelpers.getTopmostZIndex() );
DOM.addEventPreview( this );

Inside the onEventPreview() method for this panel:
public boolean onEventPreview( Event event ) {
  Element target = DOM.eventGetTarget(event);
   // Cancel the event if the target is not the splitter...
  return ( target == splitElem );
}


Finally, when the resizing is done, clean up:
DOM.removeEventPreview( this );
RootPanel root = RootPanel.get();
root.remove( this );
setVisible( false );

Since, of course, this is only a problem in FireFox, compile, deploy, and test it out. And, it still doesn't work. :-(

Left over from a previous attempt at solving this problem, I had changed the split panel class to implement EventPreview. Once I added code in there to duplicate the handling of Event.MOUSEMOVE and Event.MOUSEUP from the onBrowserEvent()....voila! It all works!

Tuesday, October 7, 2008

Label + Link + Label

Once again, this took way too long to figure out. Inspired by http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/953262516e9d664b?hl=en, but since I can't use GWT 1.5 (yet), I came up with another way of making this work.

The whole problem (as pointed out in that discussion thread) is that a <div> is rendered with "display:block;", thus forcing newlines... The fix is to sprinkle in a style that forces "display:inline;"...
Label prefix = new Label( "prefix " );
prefix.addStyleName( "inline-label" );

Label link = new Label( "foo bar" );
link.addStyleName( "hyperlink" );
link.addStyleName( "inline-label" );

Label suffix = new Label( " suffix" );
suffix.addStyleName( "inline-link" );

Panel flow = new FlowPanel();
flow.add( prefix );
flow.add( link );
flow.add( suffix );

And in the CSS:
.hyperlink {
  color: blue;
  text-decoration: underline;
  cursor: pointer;
}

.inline-label {
  display: inline !important;
}



Thursday, October 2, 2008

onAttach vs onLoad

Always getting these confused...

onAttach() is invoked when the widget is attached to the document. It can be called in the following situations:
  • The widget's parent (which implements HasWidgets) is calling it's own doAttachChildren()
  • The widget's parent is being set (e.g., setParent())
The last thing that onAttach() does is to invoke onLoad().

By default, onLoad() does nothing. So, this is the best place to insert code that has to be run whenever the widget is actually hooked up to the document.

Personally, I think this might be less confusing if the names were chosen better. Perhaps, onAttach() should have been private, and the first thing it could do is call beforeAttach(), and the last thing would be to call afterAttach(). 

Oh well.

P.S.: My suggestion wouldn't quite work because of Composite...it doesn't want/need the base behavior. See, it's not simple...

GWT ScrollPanels

Urgh. Nothing's easy. I just want some widget to scroll, so I add it into a ScrollPanel. Right? Yeah, dream on.

Unless you set a specific height on the ScrollPanel (as in "150px"), you won't get the scroll bars. 

In other words, setting the height to "100%" won't work. :-(

Debugging GWT

Finally figured out this nifty little trick to help with debugging GWT apps. Since the only way to work with CSS issues is in FireBug, and GWT generates so many tables, and divs, and so forth, how can you easily map from the generated HTML back to your code?

Add styles everywhere! Name the styles similar (the same?) as the Java class, and you now know exactly which <div> corresponds to which Java class!