Hi,
Not a solution for you but I have seen this behavior. My interpretation
is that "after event loop" doesn't necessarily includes browser reflows.
Firefox 27 ships with reflow logging in the console so you can test if
that holds true for your case.
Unfortunately I don't know any way around it. A onReflow event would be
handy and logical but this is the browser's world where [my] common
logic is twisted beyond repair...
Vassilis
On 02/26/14 15:34, William Davis wrote:
I have had some problems with getting the size of widgets, I have been
looking around for answers to my questions and have found a solution
that I am not 100% happy with. My hope is that someone knows a better
solution to my problem.
In my layout I am using a DockLayoutPanel, in the north I have a label
that holds a title that will change depending on the place I am at in
my application. In the center panel I have some scrollable content
(Tables, trees, etc). I don't want the title and the content in the
same panel because if I scroll down I will lose sight of the title,
this is the reason for the separation. My problem occurs whenever I
have a really long title that will need to wrap in order to fit on the
screen. With a DockLayoutPanel you have to give a fixed height to the
north panel, in my case I need this height to increase should the
title wrap to the second line. What I want to be able to do is in the
method that I set the text for the title label, I need to calculate
the height of the label, and set the north panel to that height so
that the entire title will be visible.
Now that sounds simple enough, but if you just set the text of the
label and then call getOffsetHeight() it will return 0. What I learned
is that you have to wait until the widget is rendered before getting
the height. In the past I used a deferred command like this:
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
@Override
public void execute() {
// TODO Auto-generated method stub
}
});
A deferred command is executed after the browser event loop returns.
This has worked for me every time in the past until now. For some
reason the command was firing before the label was displayed. If
someone could enlighten me as to why this doesn't work I would
appreciate it.
What I found that works, although I am not 100% happy with it is
scheduling a command on a fixed delay like this:
Scheduler.get().scheduleFixedDelay(new Scheduler.RepeatingCommand() {
@Override
public boolean execute() {
if (northPanel.getOffsetHeight() != 0) {
centerDock.setWidgetSize(northPanel,
northPanel.getOffsetHeight());
return false;
} else {
return true;
}
}
}, 100);
This schedules a repeating command that is scheduled with a constant
delay. That is, the next invocation of the command will be scheduled
for |100| milliseconds after the last invocation completes in this
example.
So I just had the thing run this command until the offset height gave
me a positive number, then it gets stopped by returning false in the
execute method.
While this works it seems a bit sloppy, if anyone knows a better
solution I would be happy to hear about it.
Thanks,
Will
--
You received this message because you are subscribed to the Google
Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Google
Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.