Window.addWindow() - window not opening

I have a basic pattern for opening a Form in a popup Window that will give a warning if being closed when the form is modified (dirty), so they can either resume editing or close. The same Form can also be displayed in the lower half of a SplitWindow – with the Form being populated by selecting an Item in my Table. This is done with an Action so I can right-click to open in a new window.

Most of the time, this works. But I have a few instances where the popup window does not appear ever. My logs that show my Form being built, appear normal (and same while debugging).

Is there a way to track down why a Window would not open in the call to addWindow()? What am I looking for to have the popup Window become visible? The code where it works and where it doesn’t work seem to be the same, so I’m hopeful there are some tips on how best to debug this.

I am running Vaadin 6.4.5 in Eclipse.

Thanks for any advice…

Okay, I tried debugging with ?debug=quiet and now I see a stack trace on the popup windows. It’s clearly unhappy about my VGridLayout somehow, but not sure what is wrong. Note that this does not occur if the Form is displayed in a SplitPanel, only in a popup window.

What might this mean?

(TypeError): this.com_vaadin_terminal_gwt_client_ui_VGridLayout_minRowHeights is null
com_vaadin_terminal_gwt_client_ui_VGridLayout_requestLayout__Ljava_util_Set_2Z([object Object]
com_vaadin_terminal_gwt_client_Util_componentSizeUpdated__Ljava_util_Set_2V([object Object]
com_vaadin_terminal_gwt_client_Util_notifyParentOfSizeChange__Lcom_vaadin_terminal_gwt_client_Paintable_2ZV([object Object]
org_vaadin_henrik_drawer_widgetset_client_ui_VDrawer_updateFromUIDL__Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_layout_ChildComponentContainer_$renderChild__Lcom_vaadin_terminal_gwt_client_ui_layout_ChildComponentContainer_2Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2IV([object Object]
,[object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_VGridLayout$Cell_$render__Lcom_vaadin_terminal_gwt_client_ui_VGridLayout$Cell_2V([object Object]
com_vaadin_terminal_gwt_client_ui_VGridLayout_$renderRemainingComponentsWithNoRelativeHeight__Lcom_vaadin_terminal_gwt_client_ui_VGridLayout_2Ljava_util_LinkedList_2V([object Object]
com_vaadin_terminal_gwt_client_ui_VGridLayout_updateFromUIDL__Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_VForm_updateFromUIDL__Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_layout_ChildComponentContainer_$renderChild__Lcom_vaadin_terminal_gwt_client_ui_layout_ChildComponentContainer_2Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2IV([object Object]
,[object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_VOrderedLayout_updateFromUIDL__Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_VPanel_updateFromUIDL__Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_VWindow_updateFromUIDL__Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_VView_$updateFromUIDL__Lcom_vaadin_terminal_gwt_client_ui_VView_2Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Object]
,[object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ui_VView_updateFromUIDL__Lcom_vaadin_terminal_gwt_client_UIDL_2Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2V([object Array]
,[object Object]
com_vaadin_terminal_gwt_client_ApplicationConnection$8_$execute__Lcom_vaadin_terminal_gwt_client_ApplicationConnection$8_2V([object Object]
com_vaadin_terminal_gwt_client_ApplicationConnection_$handleReceivedJSONMessage__Lcom_vaadin_terminal_gwt_client_ApplicationConnection_2Lcom_google_gwt_http_client_Response_2V([object Object]
,[object Object]
com_vaadin_terminal_gwt_client_ApplicationConnection$2_$onResponseReceived__Lcom_vaadin_terminal_gwt_client_ApplicationConnection$2_2Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_Response_2V([object Object]
,[object Object]
com_google_gwt_http_client_Request_$fireOnResponseReceived__Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_RequestCallback_2V([object Object]
,[object Object]
com_google_gwt_http_client_RequestBuilder$1_onReadyStateChange__Lcom_google_gwt_xhr_client_XMLHttpRequest_2V([object XMLHttpRequest]
([object Event]
com_google_gwt_core_client_impl_Impl_entry0__Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2((function () {handler.onReadyStateChange__Lcom_google_gwt_xhr_client_XMLHttpRequest_2V(_this);}),[object XMLHttpRequest]
,[object Object]
([object Event]
handleEvent([object Event]

 fileName: http://localhost/open-eSignFormsVaadin/VAADIN/widgetsets/
 lineNumber: 24492
Line 661

When I saw the stack trace including the Drawer component, it made me wonder about the 1.1.8 version of Drawer. So when I reverted back to the 1.1.7 version, my Windows open fine. So apparently, that null issue is in fact causing it to not appear.

@Henrik – Sorry to report this, but apparently that stack trace above is related to something that changed in the Drawer from 1.1.7 to 1.1.8. I think you maybe fixed something like this for me before, but it’s all getting fuzzy these days.


Oh you Drawer you… I’d need to take a check on where the fault is at this time. I’m starting to really really regret this Drawer thingie :smiley: Although, I have my fingers crossed that the fault lies in the GridLayout this time :slight_smile: Anyways, I’ll take a look-see as soon as I have the extra time to concentrate on this. Maybe tomorrow, but on Friday the latest.

Yet, as always, bug reports are always appreciated, and you’re my personal mini-hero for sticking to the component, considering all these adventures.

Thanks, Henrik. The curse of sharing through the Directory, eh? :wink:

Your Drawer is really nice for putting extra configuration options that are not always needed to be so visible on a Form. My Form does use a GridLayout and has multiple Drawers in it. I found one Form that only has one Drawer in a VerticalLayout, and it is okay even under 1.1.8. But that exception is thrown using the 1.1.8 Drawer (multiple) in a Form using a GridLayout.

I also continue to see some odd errors where not all subwindows are opening correctly. Sometimes, I am getting the window frame, with my icon showing, but the page is blank. I see no exceptions in my logs, and no exceptions in the ?debug=quiet console area either. If I open that same window a new browser window, it appears okay, and it appears fine in a new Tab, or in the regular Form area of my SplitPanel. Very odd… In fact, when I look at the DOM, it even appears that the contents are really in there, just not visible.

Okay, I’ve discovered why I get a window showing up now, with the icon showing, but the rest of the page is not visible even though I can see it’s in the DOM. The “window not opening” seems to be related to the Drawer 1.1.8 getting a GridLayout null exception, but for popup windows that do not have this bug, the contents are still not right.

In our popup Window code, we create a Panel, set it to full size and scrollable, then get it’s content (VerticalLayout) where when we set it to full size, the contents appear. But we don’t get scrollbars when the window is smaller than the content.

So we changed the VerticalLayout to setWidth 100% and setHeight to undefined (-1). At this point, the contents are not being rendered.

So, the question is how do I create a popup window that will hold whatever view I am putting in there AND allow scrollbars to appear? We tried setting the layout to undefined, but while this allows both horizontal and vertical scrollbars, the contents often do not render correctly.

Our popup window (inherits from Window) basically has:

super.setWidth(80, UNITS_PERCENTAGE);
super.setHeight(80, UNITS_PERCENTAGE);
// We'll create a full size panel to replace the default VerticalLayout of the Window so we can have scrollbars for our content (the view)
Panel windowPanel = new Panel();
VerticalLayout panelLayout = (VerticalLayout)windowPanel.getContent();
//panelLayout.setWidth(100, UNITS_PERCENTAGE);
//panelLayout.setHeight(-1, UNITS_PIXELS);
super.setContent(windowPanel); // Set this before we set our view since that routine will expect the Panel to be our window's content.

So, if we use setSizeFull(), whatever views we put in there render fine, but we get no scrollbars.

If we use setSizeUndefined(), the views often look odd, either with much missing, or UI components set to 100% wide are really narrow rather than fill the popup window’s width.

If we use the combination of setWidth(100%) and setHeight(-1), the view widths are fine, but again most of the content does not appear though it’s in the DOM.

For now, we’re back to setSizeFull() since that we’re happier to have the views render correctly even though they get no scrollbars, which is really not very nice.

Is there a better scheme for what I’m trying to do with a popup window where the view fills the window as much as possible (like it does when shown on our main window), yet will allow a scrollbar if the window is made smaller than its contents?

Ack, sorry for not checking in to this thread earlier. And it’s pretty late into the friday too, although I thought to dedicate the whole day for this. Oh well, oh well…

So, let me get this straight: it seems like the automatic height seems to be a problem here. Actually, as I read the stacktrace with additional scrutiny, it does very clearly say “(TypeError): this.com_vaadin_terminal_gwt_client_ui_VGridLayout_minRowHeights is null” which would very well indicate to the fact that the implicit height of the panel’s content makes GridLayout calculate some minRowHeights-value incorrectly. And all this happens when the Drawer tries to notify the parent of a size change.

Here’s a few things that I’d try in your situation: Assuming that the Panel doesn’t contain anything else than the GridLayout, try with windowPanel.setContent(theGridLayout). Another thing that I’d try is to disable Drawer’s animation (shouldn’t make a difference, but you never know). As a last resort, you could try and put an explicit height for the Drawer, if you don’t already.

On my end, I’ll try to duplicate this problem and see where exactly the problem lies.

I also noticed that you’re using a Panel as a Window’s content. But Window extends Panel already, so I wonder whether that tautology might inflict some additional pain, in this case?

Ok, I’ve identified this as a Drawer/GridLayout combination bug. The following code is enough to replicate this.

final Layout gridLayout = new GridLayout(1, 1);
final Drawer drawer = new Drawer("button", new Button("foo"));

It’s now up to me to start fighting with dev whether Drawer is wrong, or GridLayout is wrong ;). While I’ll keep you updated, today is running out, so, unfortunately, this will be delayed further. I’m sorry about that, I’ll try to fix all this asap nevertheless.

Thanks to Artur, I think I nailed the problem fingerscrossed.

Try 1.1.9 and see if it works better (and doesn’t come with further regressions):

Awesome! Is this checked in at I did an update and it still just shows 1.1.8.

I just tested the 1.1.9 from the Directory download and yes, indeed, that seems to resolve this issue. Many thanks!

(I ran a couple of tests I know had issues before, and they all worked: a) a browser refresh works, showing the all 3 drawers on my page in the same open/close state as before the refresh; and b) when I select new Items from the Table that populates the associated Form, the values are changed without any animation side-effects.)

What a nice end to my Friday work week! How can I buy you and Artur a drink? :slight_smile:

Ah, no, it wasn’t there. I updated the directory version literally seconds before I left the office, so I forgot to update the SVN. It’s there now.

try doing something creative with the postal office… :wink:

Has nobody invented DrinkPal yet? Seriously, though, thanks again for fixing this.

Sounds like it’s almost ready to become a supported component to me – it’s a useful and common UI component that the core really should have (as does GWT itself).

Sounds like an intriguing alternative to the various donation systems :). Maybe you’ll buy us some if you come and visit our HQ someday. Nevertheless, you’re very welcome.

I fully support this initiative! This way I wouldn’t have to support it anymore :wink: