Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Safe to call layout() out of controllistener#controlResized()?
|
| Re: Safe to call layout() out of controllistener#controlResized()? [message #451127 is a reply to message #451119] |
Wed, 23 February 2005 22:27   |
 Veronika Irvine
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 |
Benjamin Pasero
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 |
Veronika Irvine
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 |
Benjamin Pasero
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 |
Eclipse User |
|
|
|
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 |
Veronika Irvine
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 |
| Eclipse User |
|
|
|
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
>>>>>
>>>>>
>>>>>
>
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:39:20 GMT 2024
Powered by FUDForum. Page generated in 0.03447 seconds |
] 
Search
Help
Register
Login
Home
