Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Safe to call layout() out of controllistener#controlResized()?
Safe to call layout() out of controllistener#controlResized()? [message #451119] Wed, 23 February 2005 17:28 Go to next message
Benjamin Pasero is currently offline Benjamin PaseroFriend
Messages: 337
Registered: July 2009
Senior Member
Hi,

I am making a layout() call on a control when it gets resized. I need to
do so, because
line-wrapping (its a Hyperlink Widget) is not working automatically.
This is working in
most cases, but from time to time I am seeing a StackOverFlowException
from Linux users.

These result, because the call to layout() causes the Hyperlink widget
to resize, which
again triggers the controllistener in which layout() is called
(=infinite recursion).

But when looking at this Snippet:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup

a call to shell.layout() is made out of a Listener for SWT.Resize.

Now is it safe to listen for SWT.Resize and unsafe to use a
ControlListener, or should
there be no difference?

Ben
Re: Safe to call layout() out of controllistener#controlResized()? [message #451127 is a reply to message #451119] Wed, 23 February 2005 22:27 Go to previous messageGo to next message
Veronika Irvine is currently offline Veronika IrvineFriend
Messages: 1272
Registered: July 2009
Senior Member
In Snippet 150, it is possible for the user to resize the Coolbar by
dragging around CoolItems. This changes the preferred size of the CoolBar.
The Shell is unaware that this has been done and therefore needs to be
triggered to update the position of its children.

Consider:

[ shell [ c1 [ button ] ] ]

The order of events is this:

shell resize
shell -> Layout.layout
c1 resize if required else stop
c1 -> Layout.layout
button resize if required

The key thing is that the process stops when the children stop changing
size. If you hook resize on button, change something about button so that
it will ALWAYS have to be resized when the parent lays it out and then call
shell.layout, you will have an infinite loop.

e.g.
button.addListener(SWT.Resize, new Listener() {
public void handleEvent (event e) {
GridData data = (GridData)c2.getLayoutData();
data.widthHint += 10;
shell.layout();
}
});

What you end up with is:

shell resize
shell -> Layout.layout
c1 resize if required else stop
c1 -> Layout.layout
button resize if required
shell -> Layout.layout
c1 resize if required else stop
c1 -> Layout.layout
button resize if required
shell -> Layout.layout
c1 resize if required else stop
c1 -> Layout.layout
button resize if required
shell -> Layout.layout
c1 resize if
required else stop
c1 ->
Layout.layout
button
resize if required
....


Note that this is also a common problem with scrollbars. When a scrollbar
appears or disappears it results in a Layout.layout and a Resize event
because the client area of the parent has changed. If in a resize listener
you adjust the size based on the presence or absence of scrollbars, if you
get this calculation a little bit wrong you may end up in an infinite loop.

"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
news:cvief5$8kg$1@www.eclipse.org...
> Hi,
>
> I am making a layout() call on a control when it gets resized. I need to
> do so, because
> line-wrapping (its a Hyperlink Widget) is not working automatically. This
> is working in
> most cases, but from time to time I am seeing a StackOverFlowException
> from Linux users.
>
> These result, because the call to layout() causes the Hyperlink widget to
> resize, which
> again triggers the controllistener in which layout() is called (=infinite
> recursion).
>
> But when looking at this Snippet:
>
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup
>
> a call to shell.layout() is made out of a Listener for SWT.Resize.
>
> Now is it safe to listen for SWT.Resize and unsafe to use a
> ControlListener, or should
> there be no difference?
>
> Ben
Re: Safe to call layout() out of controllistener#controlResized()? [message #451128 is a reply to message #451127] Wed, 23 February 2005 22:53 Go to previous messageGo to next message
Benjamin Pasero is currently offline Benjamin PaseroFriend
Messages: 337
Registered: July 2009
Senior Member
Thanks for this detailed explanation.

I am having this construct:

[Composite] containing a [Hyperlink] widget

[Composite] having a ControlListener performing [method] on
#controlResized()

[method] changing the GridData.widthHint for the [Hyperlink] widget and
calling a layout() operation

Its interesting that the infinite recursion is not happening on Windows or
Mac and even on Linux it only seem to occur in rare situations.

Seems that I have to find another solution to have the Hyperlink wrap to the
next line, as soon as it is required.

Ben

>In Snippet 150, it is possible for the user to resize the Coolbar by
>dragging around CoolItems. This changes the preferred size of the CoolBar.
>The Shell is unaware that this has been done and therefore needs to be
>triggered to update the position of its children.
>
>Consider:
>
>[ shell [ c1 [ button ] ] ]
>
>The order of events is this:
>
>shell resize
> shell -> Layout.layout
> c1 resize if required else stop
> c1 -> Layout.layout
> button resize if required
>
>The key thing is that the process stops when the children stop changing
>size. If you hook resize on button, change something about button so that
>it will ALWAYS have to be resized when the parent lays it out and then call
>shell.layout, you will have an infinite loop.
>
>e.g.
>button.addListener(SWT.Resize, new Listener() {
> public void handleEvent (event e) {
> GridData data = (GridData)c2.getLayoutData();
> data.widthHint += 10;
> shell.layout();
> }
>});
>
>What you end up with is:
>
>shell resize
> shell -> Layout.layout
> c1 resize if required else stop
> c1 -> Layout.layout
> button resize if required
> shell -> Layout.layout
> c1 resize if required else stop
> c1 -> Layout.layout
> button resize if required
> shell -> Layout.layout
> c1 resize if required else stop
> c1 -> Layout.layout
> button resize if required
> shell -> Layout.layout
> c1 resize if
>required else stop
> c1 ->
>Layout.layout
> button
>resize if required
> ....
>
>
>Note that this is also a common problem with scrollbars. When a scrollbar
>appears or disappears it results in a Layout.layout and a Resize event
>because the client area of the parent has changed. If in a resize listener
>you adjust the size based on the presence or absence of scrollbars, if you
>get this calculation a little bit wrong you may end up in an infinite loop.
>
>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>news:cvief5$8kg$1@www.eclipse.org...
>
>
>>Hi,
>>
>>I am making a layout() call on a control when it gets resized. I need to
>>do so, because
>>line-wrapping (its a Hyperlink Widget) is not working automatically. This
>>is working in
>>most cases, but from time to time I am seeing a StackOverFlowException
>>from Linux users.
>>
>>These result, because the call to layout() causes the Hyperlink widget to
>>resize, which
>>again triggers the controllistener in which layout() is called (=infinite
>>recursion).
>>
>>But when looking at this Snippet:
>>
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup
>>
>>a call to shell.layout() is made out of a Listener for SWT.Resize.
>>
>>Now is it safe to listen for SWT.Resize and unsafe to use a
>>ControlListener, or should
>>there be no difference?
>>
>>Ben
>>
>>
>
>
>
>
Re: Safe to call layout() out of controllistener#controlResized()? [message #451181 is a reply to message #451128] Thu, 24 February 2005 12:16 Go to previous messageGo to next message
Veronika Irvine is currently offline Veronika IrvineFriend
Messages: 1272
Registered: July 2009
Senior Member
In 3.1 GridLayout was rewritten to support wrapping widgets. Are you sure
that you still need to modify the widthHint to get the effect you require?

The following example shows how to have text wrap without modifying the
GridData.widthHint in the resize event.

public static void main (String [] args) {
String string = "Mary Mac's mother's making Mary Mac marry me, "+
"My mother's making me marry Mary Mac, "+
"I'm goin' to marry Mary for my Mary to take care o' me; "+
"We'll all be feelin' merry when I marry Mary Mac.";
Display display = new Display ();
Shell shell = new Shell (display);
shell.setLayout(new FillLayout());
Composite c = new Composite(shell, SWT.NONE);
c.setLayout(new GridLayout(2, false));
Text t = new Text(c, SWT.WRAP | SWT.MULTI | SWT.H_SCROLL |
SWT.V_SCROLL);
GridData data = new GridData(SWT.FILL, SWT.TOP, true, false);
data.minimumWidth = 100; //optional - ensures it won't be less than
100 wide
data.widthHint = 200; // optional - used in shell pack to determine
initial size
t.setLayoutData(data);
t.setText(string);
Button b = new Button(c, SWT.PUSH);
b.setText ("button");
shell.pack();
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}

"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
news:cvj1f4$32b$1@www.eclipse.org...
> Thanks for this detailed explanation.
>
> I am having this construct:
>
> [Composite] containing a [Hyperlink] widget
>
> [Composite] having a ControlListener performing [method] on
> #controlResized()
>
> [method] changing the GridData.widthHint for the [Hyperlink] widget and
> calling a layout() operation
>
> Its interesting that the infinite recursion is not happening on Windows or
> Mac and even on Linux it only seem to occur in rare situations.
>
> Seems that I have to find another solution to have the Hyperlink wrap to
> the
> next line, as soon as it is required.
>
> Ben
>
>>In Snippet 150, it is possible for the user to resize the Coolbar by
>>dragging around CoolItems. This changes the preferred size of the
>>CoolBar. The Shell is unaware that this has been done and therefore needs
>>to be triggered to update the position of its children.
>>
>>Consider:
>>
>>[ shell [ c1 [ button ] ] ]
>>
>>The order of events is this:
>>
>>shell resize
>> shell -> Layout.layout
>> c1 resize if required else stop
>> c1 -> Layout.layout
>> button resize if required
>>
>>The key thing is that the process stops when the children stop changing
>>size. If you hook resize on button, change something about button so that
>>it will ALWAYS have to be resized when the parent lays it out and then
>>call shell.layout, you will have an infinite loop.
>>
>>e.g.
>>button.addListener(SWT.Resize, new Listener() {
>> public void handleEvent (event e) {
>> GridData data = (GridData)c2.getLayoutData();
>> data.widthHint += 10;
>> shell.layout();
>> }
>>});
>>
>>What you end up with is:
>>
>>shell resize
>> shell -> Layout.layout
>> c1 resize if required else stop
>> c1 -> Layout.layout
>> button resize if required
>> shell -> Layout.layout
>> c1 resize if required else stop
>> c1 -> Layout.layout
>> button resize if required
>> shell -> Layout.layout
>> c1 resize if required else stop
>> c1 -> Layout.layout
>> button resize if required
>> shell -> Layout.layout
>> c1 resize if
>> required else stop
>> c1 ->
>> Layout.layout
>> button
>> resize if required
>> ....
>>
>>
>>Note that this is also a common problem with scrollbars. When a scrollbar
>>appears or disappears it results in a Layout.layout and a Resize event
>>because the client area of the parent has changed. If in a resize
>>listener you adjust the size based on the presence or absence of
>>scrollbars, if you get this calculation a little bit wrong you may end up
>>in an infinite loop.
>>
>>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>>news:cvief5$8kg$1@www.eclipse.org...
>>
>>>Hi,
>>>
>>>I am making a layout() call on a control when it gets resized. I need to
>>>do so, because
>>>line-wrapping (its a Hyperlink Widget) is not working automatically. This
>>>is working in
>>>most cases, but from time to time I am seeing a StackOverFlowException
>>>from Linux users.
>>>
>>>These result, because the call to layout() causes the Hyperlink widget
>>>to resize, which
>>>again triggers the controllistener in which layout() is called (=infinite
>>>recursion).
>>>
>>>But when looking at this Snippet:
>>>
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup
>>>
>>>a call to shell.layout() is made out of a Listener for SWT.Resize.
>>>
>>>Now is it safe to listen for SWT.Resize and unsafe to use a
>>>ControlListener, or should
>>>there be no difference?
>>>
>>>Ben
>>
>>
>>
Re: Safe to call layout() out of controllistener#controlResized()? [message #451286 is a reply to message #451181] Thu, 24 February 2005 15:54 Go to previous messageGo to next message
Benjamin Pasero is currently offline Benjamin PaseroFriend
Messages: 337
Registered: July 2009
Senior Member
That is true, but my situation in this case is a bit more complicated.
The Hyperlink
widget sits inside the Top of a ViewForm (applied via setTopLeft()). Now
I noticed,
that the top-left widget of a ViewForm does not resize the Top-Area of a
ViewForm,
even if it requires more space (as when the Hyperlink is wrapping to the
next line).

Now I found an easy solution: Placing the Hyperlink into the Top-Center
of the ViewForm
(applied via setTopCenter()) is resizing the Top-Area of the ViewForm if
required.

Ben

>In 3.1 GridLayout was rewritten to support wrapping widgets. Are you sure
>that you still need to modify the widthHint to get the effect you require?
>
>The following example shows how to have text wrap without modifying the
>GridData.widthHint in the resize event.
>
>public static void main (String [] args) {
> String string = "Mary Mac's mother's making Mary Mac marry me, "+
> "My mother's making me marry Mary Mac, "+
> "I'm goin' to marry Mary for my Mary to take care o' me; "+
> "We'll all be feelin' merry when I marry Mary Mac.";
> Display display = new Display ();
> Shell shell = new Shell (display);
> shell.setLayout(new FillLayout());
> Composite c = new Composite(shell, SWT.NONE);
> c.setLayout(new GridLayout(2, false));
> Text t = new Text(c, SWT.WRAP | SWT.MULTI | SWT.H_SCROLL |
>SWT.V_SCROLL);
> GridData data = new GridData(SWT.FILL, SWT.TOP, true, false);
> data.minimumWidth = 100; //optional - ensures it won't be less than
>100 wide
> data.widthHint = 200; // optional - used in shell pack to determine
>initial size
> t.setLayoutData(data);
> t.setText(string);
> Button b = new Button(c, SWT.PUSH);
> b.setText ("button");
> shell.pack();
> shell.open ();
> while (!shell.isDisposed ()) {
> if (!display.readAndDispatch ()) display.sleep ();
> }
> display.dispose ();
>}
>
>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>news:cvj1f4$32b$1@www.eclipse.org...
>
>
>>Thanks for this detailed explanation.
>>
>>I am having this construct:
>>
>>[Composite] containing a [Hyperlink] widget
>>
>>[Composite] having a ControlListener performing [method] on
>>#controlResized()
>>
>>[method] changing the GridData.widthHint for the [Hyperlink] widget and
>> calling a layout() operation
>>
>>Its interesting that the infinite recursion is not happening on Windows or
>>Mac and even on Linux it only seem to occur in rare situations.
>>
>>Seems that I have to find another solution to have the Hyperlink wrap to
>>the
>>next line, as soon as it is required.
>>
>>Ben
>>
>>
>>
>>>In Snippet 150, it is possible for the user to resize the Coolbar by
>>>dragging around CoolItems. This changes the preferred size of the
>>>CoolBar. The Shell is unaware that this has been done and therefore needs
>>>to be triggered to update the position of its children.
>>>
>>>Consider:
>>>
>>>[ shell [ c1 [ button ] ] ]
>>>
>>>The order of events is this:
>>>
>>>shell resize
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>>
>>>The key thing is that the process stops when the children stop changing
>>>size. If you hook resize on button, change something about button so that
>>>it will ALWAYS have to be resized when the parent lays it out and then
>>>call shell.layout, you will have an infinite loop.
>>>
>>>e.g.
>>>button.addListener(SWT.Resize, new Listener() {
>>> public void handleEvent (event e) {
>>> GridData data = (GridData)c2.getLayoutData();
>>> data.widthHint += 10;
>>> shell.layout();
>>> }
>>>});
>>>
>>>What you end up with is:
>>>
>>>shell resize
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>> shell -> Layout.layout
>>> c1 resize if
>>>required else stop
>>> c1 ->
>>>Layout.layout
>>> button
>>>resize if required
>>> ....
>>>
>>>
>>>Note that this is also a common problem with scrollbars. When a scrollbar
>>>appears or disappears it results in a Layout.layout and a Resize event
>>>because the client area of the parent has changed. If in a resize
>>>listener you adjust the size based on the presence or absence of
>>>scrollbars, if you get this calculation a little bit wrong you may end up
>>>in an infinite loop.
>>>
>>>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>>>news:cvief5$8kg$1@www.eclipse.org...
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I am making a layout() call on a control when it gets resized. I need to
>>>>do so, because
>>>>line-wrapping (its a Hyperlink Widget) is not working automatically. This
>>>>is working in
>>>>most cases, but from time to time I am seeing a StackOverFlowException
>>>>
>>>>
>>>>from Linux users.
>>>
>>>
>>>>These result, because the call to layout() causes the Hyperlink widget
>>>>to resize, which
>>>>again triggers the controllistener in which layout() is called (=infinite
>>>>recursion).
>>>>
>>>>But when looking at this Snippet:
>>>>
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup
>>>>
>>>>a call to shell.layout() is made out of a Listener for SWT.Resize.
>>>>
>>>>Now is it safe to listen for SWT.Resize and unsafe to use a
>>>>ControlListener, or should
>>>>there be no difference?
>>>>
>>>>Ben
>>>>
>>>>
>>>
>>>
>>>
>
>
>
>
Re: Safe to call layout() out of controllistener#controlResized()? [message #451287 is a reply to message #451181] Thu, 24 February 2005 16:27 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: bob.objfac.com

Interesting snippet. If you resize the shell to be more narrow, the
height of the text box grows to accomodate all the text. I've been
looking for a widget like that for ages! However...

- If you type text into the box causing the last line to flow, the box
starts scrolling instead of growing further, even though it could.

- Sometimes, typing/flowing causes the box to shrink!

- If you make the shell too narrow and short to accomodate showing the
full text, only the top part of the text box is displayed, with no
scrollbar.

Does this snippet need more code to make it behave better, or are these
bugs? Thanks.

Bob Foster

Veronika Irvine wrote:
> In 3.1 GridLayout was rewritten to support wrapping widgets. Are you sure
> that you still need to modify the widthHint to get the effect you require?
>
> The following example shows how to have text wrap without modifying the
> GridData.widthHint in the resize event.
>
> public static void main (String [] args) {
> String string = "Mary Mac's mother's making Mary Mac marry me, "+
> "My mother's making me marry Mary Mac, "+
> "I'm goin' to marry Mary for my Mary to take care o' me; "+
> "We'll all be feelin' merry when I marry Mary Mac.";
> Display display = new Display ();
> Shell shell = new Shell (display);
> shell.setLayout(new FillLayout());
> Composite c = new Composite(shell, SWT.NONE);
> c.setLayout(new GridLayout(2, false));
> Text t = new Text(c, SWT.WRAP | SWT.MULTI | SWT.H_SCROLL |
> SWT.V_SCROLL);
> GridData data = new GridData(SWT.FILL, SWT.TOP, true, false);
> data.minimumWidth = 100; //optional - ensures it won't be less than
> 100 wide
> data.widthHint = 200; // optional - used in shell pack to determine
> initial size
> t.setLayoutData(data);
> t.setText(string);
> Button b = new Button(c, SWT.PUSH);
> b.setText ("button");
> shell.pack();
> shell.open ();
> while (!shell.isDisposed ()) {
> if (!display.readAndDispatch ()) display.sleep ();
> }
> display.dispose ();
> }
>
> "Benjamin Pasero" <bpasero@rssowl.org> wrote in message
> news:cvj1f4$32b$1@www.eclipse.org...
>
>>Thanks for this detailed explanation.
>>
>>I am having this construct:
>>
>>[Composite] containing a [Hyperlink] widget
>>
>>[Composite] having a ControlListener performing [method] on
>>#controlResized()
>>
>>[method] changing the GridData.widthHint for the [Hyperlink] widget and
>> calling a layout() operation
>>
>>Its interesting that the infinite recursion is not happening on Windows or
>>Mac and even on Linux it only seem to occur in rare situations.
>>
>>Seems that I have to find another solution to have the Hyperlink wrap to
>>the
>>next line, as soon as it is required.
>>
>>Ben
>>
>>
>>>In Snippet 150, it is possible for the user to resize the Coolbar by
>>>dragging around CoolItems. This changes the preferred size of the
>>>CoolBar. The Shell is unaware that this has been done and therefore needs
>>>to be triggered to update the position of its children.
>>>
>>>Consider:
>>>
>>>[ shell [ c1 [ button ] ] ]
>>>
>>>The order of events is this:
>>>
>>>shell resize
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>>
>>>The key thing is that the process stops when the children stop changing
>>>size. If you hook resize on button, change something about button so that
>>>it will ALWAYS have to be resized when the parent lays it out and then
>>>call shell.layout, you will have an infinite loop.
>>>
>>>e.g.
>>>button.addListener(SWT.Resize, new Listener() {
>>> public void handleEvent (event e) {
>>> GridData data = (GridData)c2.getLayoutData();
>>> data.widthHint += 10;
>>> shell.layout();
>>> }
>>>});
>>>
>>>What you end up with is:
>>>
>>>shell resize
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>> shell -> Layout.layout
>>> c1 resize if required else stop
>>> c1 -> Layout.layout
>>> button resize if required
>>> shell -> Layout.layout
>>> c1 resize if
>>>required else stop
>>> c1 ->
>>>Layout.layout
>>> button
>>>resize if required
>>> ....
>>>
>>>
>>>Note that this is also a common problem with scrollbars. When a scrollbar
>>>appears or disappears it results in a Layout.layout and a Resize event
>>>because the client area of the parent has changed. If in a resize
>>>listener you adjust the size based on the presence or absence of
>>>scrollbars, if you get this calculation a little bit wrong you may end up
>>>in an infinite loop.
>>>
>>>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>>>news:cvief5$8kg$1@www.eclipse.org...
>>>
>>>
>>>>Hi,
>>>>
>>>>I am making a layout() call on a control when it gets resized. I need to
>>>>do so, because
>>>>line-wrapping (its a Hyperlink Widget) is not working automatically. This
>>>>is working in
>>>>most cases, but from time to time I am seeing a StackOverFlowException
>>>
>>>>from Linux users.
>>>
>>>>These result, because the call to layout() causes the Hyperlink widget
>>>>to resize, which
>>>>again triggers the controllistener in which layout() is called (=infinite
>>>>recursion).
>>>>
>>>>But when looking at this Snippet:
>>>>
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup
>>>>
>>>>a call to shell.layout() is made out of a Listener for SWT.Resize.
>>>>
>>>>Now is it safe to listen for SWT.Resize and unsafe to use a
>>>>ControlListener, or should
>>>>there be no difference?
>>>>
>>>>Ben
>>>
>>>
>>>
>
>
Re: Safe to call layout() out of controllistener#controlResized()? [message #451292 is a reply to message #451287] Thu, 24 February 2005 17:20 Go to previous messageGo to next message
Veronika Irvine is currently offline Veronika IrvineFriend
Messages: 1272
Registered: July 2009
Senior Member
> - If you type text into the box causing the last line to flow, the box
> starts scrolling instead of growing further, even though it could.
Just layout in a modifier listener

> - If you make the shell too narrow and short to accomodate showing the
> full text, only the top part of the text box is displayed, with no
> scrollbar.
Grab in the vertical direction

The following works except for a minor bug in Text.computeSize. I will
enter a bug report for this.

public static void main (String [] args) {
String string = "Mary Mac's mother's making Mary Mac marry me, "+
"My mother's making me marry Mary Mac, "+
"I'm goin' to marry Mary for my Mary to take care o' me; "+
"We'll all be feelin' merry when I marry Mary Mac.";
Display display = new Display ();
final Shell shell = new Shell (display);
shell.setLayout(new FillLayout());
Composite c = new Composite(shell, SWT.NONE);
c.setLayout(new GridLayout(2, false));
final Text t = new Text(c, SWT.WRAP | SWT.MULTI | SWT.H_SCROLL |
SWT.V_SCROLL);
GridData data = new GridData(SWT.FILL, SWT.TOP, true, true);
data.minimumWidth = 100; //optional - ensures it won't be less than
100
data.widthHint = 200; // optional - used in shell pack to determine
initial size
t.setLayoutData(data);
t.setText(string);
t.addModifyListener(new ModifyListener() {
public void modifyText(ModifyEvent e) {
shell.layout(new Control[] {t});
}

});
Button b = new Button(c, SWT.PUSH);
b.setText ("button");
shell.pack();
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}

"Bob Foster" <bob@objfac.com> wrote in message
news:421E005A.7050601@objfac.com...
> Interesting snippet. If you resize the shell to be more narrow, the height
> of the text box grows to accomodate all the text. I've been looking for a
> widget like that for ages! However...
>
> - If you type text into the box causing the last line to flow, the box
> starts scrolling instead of growing further, even though it could.
>
> - Sometimes, typing/flowing causes the box to shrink!
>
> - If you make the shell too narrow and short to accomodate showing the
> full text, only the top part of the text box is displayed, with no
> scrollbar.
>
> Does this snippet need more code to make it behave better, or are these
> bugs? Thanks.
>
> Bob Foster
>
> Veronika Irvine wrote:
>> In 3.1 GridLayout was rewritten to support wrapping widgets. Are you
>> sure that you still need to modify the widthHint to get the effect you
>> require?
>>
>> The following example shows how to have text wrap without modifying the
>> GridData.widthHint in the resize event.
>>
>> public static void main (String [] args) {
>> String string = "Mary Mac's mother's making Mary Mac marry me, "+
>> "My mother's making me marry Mary Mac, "+
>> "I'm goin' to marry Mary for my Mary to take care o' me;
>> "+
>> "We'll all be feelin' merry when I marry Mary Mac.";
>> Display display = new Display ();
>> Shell shell = new Shell (display);
>> shell.setLayout(new FillLayout());
>> Composite c = new Composite(shell, SWT.NONE);
>> c.setLayout(new GridLayout(2, false));
>> Text t = new Text(c, SWT.WRAP | SWT.MULTI | SWT.H_SCROLL |
>> SWT.V_SCROLL);
>> GridData data = new GridData(SWT.FILL, SWT.TOP, true, false);
>> data.minimumWidth = 100; //optional - ensures it won't be less
>> than 100 wide
>> data.widthHint = 200; // optional - used in shell pack to
>> determine initial size
>> t.setLayoutData(data);
>> t.setText(string);
>> Button b = new Button(c, SWT.PUSH);
>> b.setText ("button");
>> shell.pack();
>> shell.open ();
>> while (!shell.isDisposed ()) {
>> if (!display.readAndDispatch ()) display.sleep ();
>> }
>> display.dispose ();
>> }
>>
>> "Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>> news:cvj1f4$32b$1@www.eclipse.org...
>>
>>>Thanks for this detailed explanation.
>>>
>>>I am having this construct:
>>>
>>>[Composite] containing a [Hyperlink] widget
>>>
>>>[Composite] having a ControlListener performing [method] on
>>>#controlResized()
>>>
>>>[method] changing the GridData.widthHint for the [Hyperlink] widget and
>>> calling a layout() operation
>>>
>>>Its interesting that the infinite recursion is not happening on Windows
>>>or
>>>Mac and even on Linux it only seem to occur in rare situations.
>>>
>>>Seems that I have to find another solution to have the Hyperlink wrap to
>>>the
>>>next line, as soon as it is required.
>>>
>>>Ben
>>>
>>>
>>>>In Snippet 150, it is possible for the user to resize the Coolbar by
>>>>dragging around CoolItems. This changes the preferred size of the
>>>>CoolBar. The Shell is unaware that this has been done and therefore
>>>>needs to be triggered to update the position of its children.
>>>>
>>>>Consider:
>>>>
>>>>[ shell [ c1 [ button ] ] ]
>>>>
>>>>The order of events is this:
>>>>
>>>>shell resize
>>>> shell -> Layout.layout
>>>> c1 resize if required else stop
>>>> c1 -> Layout.layout
>>>> button resize if required
>>>>
>>>>The key thing is that the process stops when the children stop changing
>>>>size. If you hook resize on button, change something about button so
>>>>that it will ALWAYS have to be resized when the parent lays it out and
>>>>then call shell.layout, you will have an infinite loop.
>>>>
>>>>e.g.
>>>>button.addListener(SWT.Resize, new Listener() {
>>>> public void handleEvent (event e) {
>>>> GridData data = (GridData)c2.getLayoutData();
>>>> data.widthHint += 10;
>>>> shell.layout();
>>>> }
>>>>});
>>>>
>>>>What you end up with is:
>>>>
>>>>shell resize
>>>> shell -> Layout.layout
>>>> c1 resize if required else stop
>>>> c1 -> Layout.layout
>>>> button resize if required
>>>> shell -> Layout.layout
>>>> c1 resize if required else stop
>>>> c1 -> Layout.layout
>>>> button resize if required
>>>> shell -> Layout.layout
>>>> c1 resize if required else stop
>>>> c1 -> Layout.layout
>>>> button resize if required
>>>> shell ->
>>>> Layout.layout
>>>> c1 resize if
>>>> required else stop
>>>> c1 ->
>>>> Layout.layout
>>>> button
>>>> resize if required
>>>> ....
>>>>
>>>>
>>>>Note that this is also a common problem with scrollbars. When a
>>>>scrollbar appears or disappears it results in a Layout.layout and a
>>>>Resize event because the client area of the parent has changed. If in a
>>>>resize listener you adjust the size based on the presence or absence of
>>>>scrollbars, if you get this calculation a little bit wrong you may end
>>>>up in an infinite loop.
>>>>
>>>>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>>>>news:cvief5$8kg$1@www.eclipse.org...
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I am making a layout() call on a control when it gets resized. I need
>>>>>to do so, because
>>>>>line-wrapping (its a Hyperlink Widget) is not working automatically.
>>>>>This is working in
>>>>>most cases, but from time to time I am seeing a StackOverFlowException
>>>>
>>>>>from Linux users.
>>>>
>>>>>These result, because the call to layout() causes the Hyperlink widget
>>>>>to resize, which
>>>>>again triggers the controllistener in which layout() is called
>>>>>(=infinite recursion).
>>>>>
>>>>>But when looking at this Snippet:
>>>>>
>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup
>>>>>
>>>>>a call to shell.layout() is made out of a Listener for SWT.Resize.
>>>>>
>>>>>Now is it safe to listen for SWT.Resize and unsafe to use a
>>>>>ControlListener, or should
>>>>>there be no difference?
>>>>>
>>>>>Ben
>>>>
>>>>
>>>>
>>
Re: Safe to call layout() out of controllistener#controlResized()? [message #451295 is a reply to message #451292] Thu, 24 February 2005 19:02 Go to previous message
Eclipse UserFriend
Originally posted by: bob.objfac.com

Very nice snippet! Thanks.

Bob

Veronika Irvine wrote:
>>- If you type text into the box causing the last line to flow, the box
>>starts scrolling instead of growing further, even though it could.
>
> Just layout in a modifier listener
>
>
>>- If you make the shell too narrow and short to accomodate showing the
>>full text, only the top part of the text box is displayed, with no
>>scrollbar.
>
> Grab in the vertical direction
>
> The following works except for a minor bug in Text.computeSize. I will
> enter a bug report for this.
>
> public static void main (String [] args) {
> String string = "Mary Mac's mother's making Mary Mac marry me, "+
> "My mother's making me marry Mary Mac, "+
> "I'm goin' to marry Mary for my Mary to take care o' me; "+
> "We'll all be feelin' merry when I marry Mary Mac.";
> Display display = new Display ();
> final Shell shell = new Shell (display);
> shell.setLayout(new FillLayout());
> Composite c = new Composite(shell, SWT.NONE);
> c.setLayout(new GridLayout(2, false));
> final Text t = new Text(c, SWT.WRAP | SWT.MULTI | SWT.H_SCROLL |
> SWT.V_SCROLL);
> GridData data = new GridData(SWT.FILL, SWT.TOP, true, true);
> data.minimumWidth = 100; //optional - ensures it won't be less than
> 100
> data.widthHint = 200; // optional - used in shell pack to determine
> initial size
> t.setLayoutData(data);
> t.setText(string);
> t.addModifyListener(new ModifyListener() {
> public void modifyText(ModifyEvent e) {
> shell.layout(new Control[] {t});
> }
>
> });
> Button b = new Button(c, SWT.PUSH);
> b.setText ("button");
> shell.pack();
> shell.open ();
> while (!shell.isDisposed ()) {
> if (!display.readAndDispatch ()) display.sleep ();
> }
> display.dispose ();
> }
>
> "Bob Foster" <bob@objfac.com> wrote in message
> news:421E005A.7050601@objfac.com...
>
>>Interesting snippet. If you resize the shell to be more narrow, the height
>>of the text box grows to accomodate all the text. I've been looking for a
>>widget like that for ages! However...
>>
>>- If you type text into the box causing the last line to flow, the box
>>starts scrolling instead of growing further, even though it could.
>>
>>- Sometimes, typing/flowing causes the box to shrink!
>>
>>- If you make the shell too narrow and short to accomodate showing the
>>full text, only the top part of the text box is displayed, with no
>>scrollbar.
>>
>>Does this snippet need more code to make it behave better, or are these
>>bugs? Thanks.
>>
>>Bob Foster
>>
>>Veronika Irvine wrote:
>>
>>>In 3.1 GridLayout was rewritten to support wrapping widgets. Are you
>>>sure that you still need to modify the widthHint to get the effect you
>>>require?
>>>
>>>The following example shows how to have text wrap without modifying the
>>>GridData.widthHint in the resize event.
>>>
>>>public static void main (String [] args) {
>>> String string = "Mary Mac's mother's making Mary Mac marry me, "+
>>> "My mother's making me marry Mary Mac, "+
>>> "I'm goin' to marry Mary for my Mary to take care o' me;
>>>"+
>>> "We'll all be feelin' merry when I marry Mary Mac.";
>>> Display display = new Display ();
>>> Shell shell = new Shell (display);
>>> shell.setLayout(new FillLayout());
>>> Composite c = new Composite(shell, SWT.NONE);
>>> c.setLayout(new GridLayout(2, false));
>>> Text t = new Text(c, SWT.WRAP | SWT.MULTI | SWT.H_SCROLL |
>>>SWT.V_SCROLL);
>>> GridData data = new GridData(SWT.FILL, SWT.TOP, true, false);
>>> data.minimumWidth = 100; //optional - ensures it won't be less
>>>than 100 wide
>>> data.widthHint = 200; // optional - used in shell pack to
>>>determine initial size
>>> t.setLayoutData(data);
>>> t.setText(string);
>>> Button b = new Button(c, SWT.PUSH);
>>> b.setText ("button");
>>> shell.pack();
>>> shell.open ();
>>> while (!shell.isDisposed ()) {
>>> if (!display.readAndDispatch ()) display.sleep ();
>>> }
>>> display.dispose ();
>>>}
>>>
>>>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>>>news:cvj1f4$32b$1@www.eclipse.org...
>>>
>>>
>>>>Thanks for this detailed explanation.
>>>>
>>>>I am having this construct:
>>>>
>>>>[Composite] containing a [Hyperlink] widget
>>>>
>>>>[Composite] having a ControlListener performing [method] on
>>>>#controlResized()
>>>>
>>>>[method] changing the GridData.widthHint for the [Hyperlink] widget and
>>>> calling a layout() operation
>>>>
>>>>Its interesting that the infinite recursion is not happening on Windows
>>>>or
>>>>Mac and even on Linux it only seem to occur in rare situations.
>>>>
>>>>Seems that I have to find another solution to have the Hyperlink wrap to
>>>>the
>>>>next line, as soon as it is required.
>>>>
>>>>Ben
>>>>
>>>>
>>>>
>>>>>In Snippet 150, it is possible for the user to resize the Coolbar by
>>>>>dragging around CoolItems. This changes the preferred size of the
>>>>>CoolBar. The Shell is unaware that this has been done and therefore
>>>>>needs to be triggered to update the position of its children.
>>>>>
>>>>>Consider:
>>>>>
>>>>>[ shell [ c1 [ button ] ] ]
>>>>>
>>>>>The order of events is this:
>>>>>
>>>>>shell resize
>>>>> shell -> Layout.layout
>>>>> c1 resize if required else stop
>>>>> c1 -> Layout.layout
>>>>> button resize if required
>>>>>
>>>>>The key thing is that the process stops when the children stop changing
>>>>>size. If you hook resize on button, change something about button so
>>>>>that it will ALWAYS have to be resized when the parent lays it out and
>>>>>then call shell.layout, you will have an infinite loop.
>>>>>
>>>>>e.g.
>>>>>button.addListener(SWT.Resize, new Listener() {
>>>>> public void handleEvent (event e) {
>>>>> GridData data = (GridData)c2.getLayoutData();
>>>>> data.widthHint += 10;
>>>>> shell.layout();
>>>>> }
>>>>>});
>>>>>
>>>>>What you end up with is:
>>>>>
>>>>>shell resize
>>>>> shell -> Layout.layout
>>>>> c1 resize if required else stop
>>>>> c1 -> Layout.layout
>>>>> button resize if required
>>>>> shell -> Layout.layout
>>>>> c1 resize if required else stop
>>>>> c1 -> Layout.layout
>>>>> button resize if required
>>>>> shell -> Layout.layout
>>>>> c1 resize if required else stop
>>>>> c1 -> Layout.layout
>>>>> button resize if required
>>>>> shell ->
>>>>>Layout.layout
>>>>> c1 resize if
>>>>>required else stop
>>>>> c1 ->
>>>>>Layout.layout
>>>>> button
>>>>>resize if required
>>>>> ....
>>>>>
>>>>>
>>>>>Note that this is also a common problem with scrollbars. When a
>>>>>scrollbar appears or disappears it results in a Layout.layout and a
>>>>>Resize event because the client area of the parent has changed. If in a
>>>>>resize listener you adjust the size based on the presence or absence of
>>>>>scrollbars, if you get this calculation a little bit wrong you may end
>>>>>up in an infinite loop.
>>>>>
>>>>>"Benjamin Pasero" <bpasero@rssowl.org> wrote in message
>>>>>news:cvief5$8kg$1@www.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I am making a layout() call on a control when it gets resized. I need
>>>>>>to do so, because
>>>>>>line-wrapping (its a Hyperlink Widget) is not working automatically.
>>>>>>This is working in
>>>>>>most cases, but from time to time I am seeing a StackOverFlowException
>>>>>
>>>>>>from Linux users.
>>>>>
>>>>>
>>>>>>These result, because the call to layout() causes the Hyperlink widget
>>>>>>to resize, which
>>>>>>again triggers the controllistener in which layout() is called
>>>>>>(=infinite recursion).
>>>>>>
>>>>>>But when looking at this Snippet:
>>>>>>
>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.sni ppets/src/org/eclipse/swt/snippets/Snippet150.java?rev=HEAD& amp;content-type=text/vnd.viewcvs-markup
>>>>>>
>>>>>>a call to shell.layout() is made out of a Listener for SWT.Resize.
>>>>>>
>>>>>>Now is it safe to listen for SWT.Resize and unsafe to use a
>>>>>>ControlListener, or should
>>>>>>there be no difference?
>>>>>>
>>>>>>Ben
>>>>>
>>>>>
>>>>>
>
Previous Topic:OLE events without id
Next Topic:Key event problem on PocketPC
Goto Forum:
  


Current Time: Sat Oct 31 08:28:36 GMT 2020

Powered by FUDForum. Page generated in 0.01543 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top