I’m terribly sorry, but no matter how hard I try, I don’t seem to be able to replicate your symptoms.
While a round of “drawer.setVisible()” toggling before and after the content replacements might throw Vaadin’s dimension calculations off (since the drawer is removed from the DOM, thus having undefined dimensions), that doesn’t seem to be the problem here, since I haven’t been able to make that fail in my experiments.
If that makes them behave better, I must suggest you do that instead. It’s not elegant, and it’s definitely a workaround, but it seems to be the best I can offer at the moment. :-/
I’m starting to fear some weird black magic here. Again, no hits for me.
That margin thing got me thinking if you hit on a particular theme bug,
#5077 . This has caused me grief in other applications, since Vaadin seems to be unable to account for the inherited margin - pushing content too far down/right, causing clipping. It’s a bit of a long shot, but it’s the only thing that comes to mind.
How about disabling your custom theme (go with vanilla Reindeer), and see if it still clips? It does strike me odd, however, that resizing the window would fix the bug, but it’s worth a shot.
I’m trying to have a drawer component opened by default. However with this code the only thing open is the arrow but the content of drawer is not shown. Is there a workaround for this ?
final Layout layout = new GridLayout();
layout.setHeight("100px");
layout.addComponent(new Button("First"));
layout.addComponent(new Button("Second"));
final Drawer drawer = new Drawer("Button drawer", layout);
drawer.setDrawerHeight(100);
drawer.setAnimationDurationMillis(100);
drawer.setDrawerOpen(true);
// Drawer is designed to work best with explicitly defined widths.
drawer.setWidth("20em");
MyApplication.getCurrent().myForm.addComponent(drawer);
Hi Denis, and thanks for posting this. Sorry for taking so long to getting back to you, with the vacation and all. Oh, and thanks for the code.
Yeah, there seems to be a problem with having a drawer open at the first rendering. I also noticed another problem, which doesn’t fix a VerticalLayout’s height if the drawer is closed without an animation (probably unrelated to this problem). I wonder if this has something to do with David’s problem that I never got caught…
Drawer is, yet again, updated with bug fixes. Pre-opened Drawers work now better, a closing drawer’s animation doesn’t glitch graphically anymore, and closing a drawer without an animation has now a correct height.
I fixed the problem in
VDrawer#updateFromUIDL by setting disabled=false as default in the if-statement where checking for the attribute
VAADIN_DISABLED__BOOLEAN .
However, I am not sure, if this is the proper way to do this (I so far didn’t do any own client components)…
Sorry for not noticing your post, and thanks for reporting the problem!
That’s pretty weird behavior. I have very little time to check out the Drawer nowadays, but I’ll see if I can squeeze some time to sit down and check that out. But that might take a couple of weeks :(.
If that workaround seems to work for you, that might be your best bet right now. It seems (as David Wall very well knows) that when something is fixed in the Drawer, something else breaks. I’ve had troubles understanding how Drawer would work best with Vaadin in all situations
first of all: great component, very usefull!
one enhancement request though: it would be awesome if not only labels but also layouts would be supported as drawer caption…
Yeah, having an arbitrary component as the caption/header woud be nice, and you’re not the first one to request that. Although, with the problems I’ve experienced with having just the drawer component, I probably will not add that feature in the foreseeable future. Sorry for that
If you like, you could try
Jouni’s Animator and do a similar component on your own. I’ve heard only positive things about it!
You should be able to do a generic drawer component with server composition only (using the AnimatorProxy), and you can use the Disclosure component (packaged with the Animator add-on) as a base to add support for layout captions.
This is now fixed with Drawer 1.1.10. Your code worked perfectly, and I didn’t notice any regressions. Thanks for the bug info, and for the proposed fix.
I use the drawer to hide/show a search form. The problem is, after the user changes the language of my application,
everything is translated except the content of the drawer (= the actual search form). After a debugging session I saw a suspicious if block (line 264) in the VDrawer widget class:
// get the drawer Component
if (uidl.getChildCount() > 0) {
final UIDL drawerUIDL = uidl.getChildUIDL(0);
final Paintable paintable = client.getPaintable(drawerUIDL);
final Widget widgetCopyOfPaintable = (Widget) paintable;
if (widgetCopyOfPaintable != drawer.getWidget()) { // <---------
//in this block the content is updated
....
The problem is, that my search form is still the same instance but only the caption of the fields changed, so the code in the if block is never executed.
I have never seen a similar if block in any other widget class so I think this might be a bug in the VDrawer class.
This sounds weird, yet very plausible. I’ll try to find some time for looking into this, but unfortunately I can make no promises. If you are in a hurry, I suggest you to clone
https://github.com/wolfie/Drawer and try out the changes manually.
