Home » Eclipse Projects » Remote Application Platform (RAP) » TextSizeDeterminationHandler sets and resets the size of a widget
| TextSizeDeterminationHandler sets and resets the size of a widget [message #120721] |
Fri, 06 February 2009 07:29  |
Eclipse User |
|
|
|
Hi,
in method TextSizeDeterminationHandler.afterPhase, there's the following
code:
WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
WidgetTreeVisitor.accept( shells[ i ], clearLayout );
shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
WidgetTreeVisitor.accept( shells[ i ], clearLayout );
shells[ i ].setSize( buffer );
WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
Why setting size buffer+1000 and then reset to buffer?
Is needed to calculate something?
If yes, can I avoid this "adjusting"?
Thanks
Enrico
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #120862 is a reply to message #120721] |
Fri, 06 February 2009 09:09  |
| Eclipse User |
|
|
|
Hi Enrico,
you discovered one of the pieces of magic in RAP ;-)
This code triggers a resize of all widgets after the results of the text
measurements arrive from the client. As the layout is already done
before (with estimated text sizes), we need to trigger a re-calculation
of widget's preferred sizes at this point.
This trick turned out to work rather well, that's why it's still there.
In which respect does it hurt in your case?
Best regards, Ralf
Enrico Zanaga wrote:
> Hi,
>
> in method TextSizeDeterminationHandler.afterPhase, there's the following
> code:
>
> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
> shells[ i ].setSize( buffer );
> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>
>
> Why setting size buffer+1000 and then reset to buffer?
> Is needed to calculate something?
> If yes, can I avoid this "adjusting"?
>
> Thanks
> Enrico
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #120905 is a reply to message #120862] |
Fri, 06 February 2009 09:48 |
| Eclipse User |
|
|
|
Hi Ralf,
in my application every table has a custom column auto size algorithm.
The first time a table is shown, the columns spreads to the 100% of
table's width. When the table's width increase the columns' width
increase too, spreading to 100%. When the table's width decrease, the
columns' width don't decrease.
This algorithm works in SWT, but in RWT when I open a shell with a table
the columns go directly out of the table, because "setSize( buffer.x +
1000, buffer.y + 1000 )" increase the table's width. The result is
having a table with columns so large that's not visible.
Example in SWT:
+-- Shell ----------+
|+Col1----+Col2-+C3+|
|| | | ||
||________|_____|__||
+-------------------+
Example in RWT:
+-- Shell ----------+
|+Col1------------+Col2------+C3--+
|| | | | |
||________________|_|________|____|
+-------------------+
In this case I wish to disable the TextSizeDeterminationHandler, perhaps
setting manually some properties in the control...
Have any ideas or hints?
Thanks
Enrico
Ralf Sternberg ha scritto:
> Hi Enrico,
>
> you discovered one of the pieces of magic in RAP ;-)
>
> This code triggers a resize of all widgets after the results of the text
> measurements arrive from the client. As the layout is already done
> before (with estimated text sizes), we need to trigger a re-calculation
> of widget's preferred sizes at this point.
>
> This trick turned out to work rather well, that's why it's still there.
> In which respect does it hurt in your case?
>
> Best regards, Ralf
>
> Enrico Zanaga wrote:
>> Hi,
>>
>> in method TextSizeDeterminationHandler.afterPhase, there's the following
>> code:
>>
>> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>> shells[ i ].setSize( buffer );
>> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>>
>>
>> Why setting size buffer+1000 and then reset to buffer?
>> Is needed to calculate something?
>> If yes, can I avoid this "adjusting"?
>>
>> Thanks
>> Enrico
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #120948 is a reply to message #120905] |
Fri, 06 February 2009 11:39 |
| Eclipse User |
|
|
|
Originally posted by: evolanakis.innoopract.com
Enrico,
you wondering, have you tried using the TableColumnLayout?
It does automatically resize columns based on weights (i.e. 10/5/5 ->
50%, 25%, 25%) and works well with RAP too.
Here's a snippet:
http://eclipsenuggets.blogspot.com/2007/11/one-of-less-promi nent-novelties-in.html
Elias.
have you looked into the TableColumnLayout lay
Enrico Zanaga wrote:
> Hi Ralf,
>
> in my application every table has a custom column auto size algorithm.
>
> The first time a table is shown, the columns spreads to the 100% of
> table's width. When the table's width increase the columns' width
> increase too, spreading to 100%. When the table's width decrease, the
> columns' width don't decrease.
>
> This algorithm works in SWT, but in RWT when I open a shell with a table
> the columns go directly out of the table, because "setSize( buffer.x +
> 1000, buffer.y + 1000 )" increase the table's width. The result is
> having a table with columns so large that's not visible.
>
> Example in SWT:
> +-- Shell ----------+
> |+Col1----+Col2-+C3+|
> || | | ||
> ||________|_____|__||
> +-------------------+
>
> Example in RWT:
> +-- Shell ----------+
> |+Col1------------+Col2------+C3--+
> || | | | |
> ||________________|_|________|____|
> +-------------------+
>
> In this case I wish to disable the TextSizeDeterminationHandler, perhaps
> setting manually some properties in the control...
>
> Have any ideas or hints?
>
> Thanks
> Enrico
>
>
> Ralf Sternberg ha scritto:
>> Hi Enrico,
>>
>> you discovered one of the pieces of magic in RAP ;-)
>>
>> This code triggers a resize of all widgets after the results of the text
>> measurements arrive from the client. As the layout is already done
>> before (with estimated text sizes), we need to trigger a re-calculation
>> of widget's preferred sizes at this point.
>>
>> This trick turned out to work rather well, that's why it's still there.
>> In which respect does it hurt in your case?
>>
>> Best regards, Ralf
>>
>> Enrico Zanaga wrote:
>>> Hi,
>>>
>>> in method TextSizeDeterminationHandler.afterPhase, there's the following
>>> code:
>>>
>>> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>> shells[ i ].setSize( buffer );
>>> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>>>
>>>
>>> Why setting size buffer+1000 and then reset to buffer?
>>> Is needed to calculate something?
>>> If yes, can I avoid this "adjusting"?
>>>
>>> Thanks
>>> Enrico
--
---
Elias Volanakis
Innoopract, Inc.
http://www.innoopract.com
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #120963 is a reply to message #120905] |
Fri, 06 February 2009 11:52 |
| Eclipse User |
|
|
|
Hi Enrico,
I understand your case but I'm afraid there is currently no cure for it
(unless you find some hack on your side ;-). Calculating layouts
depending on previous states is not common, thus we didn't expect such a
case.
Best regards, Ralf
Enrico Zanaga wrote:
> Hi Ralf,
>
> in my application every table has a custom column auto size algorithm.
>
> The first time a table is shown, the columns spreads to the 100% of
> table's width. When the table's width increase the columns' width
> increase too, spreading to 100%. When the table's width decrease, the
> columns' width don't decrease.
>
> This algorithm works in SWT, but in RWT when I open a shell with a table
> the columns go directly out of the table, because "setSize( buffer.x +
> 1000, buffer.y + 1000 )" increase the table's width. The result is
> having a table with columns so large that's not visible.
>
> Example in SWT:
> +-- Shell ----------+
> |+Col1----+Col2-+C3+|
> || | | ||
> ||________|_____|__||
> +-------------------+
>
> Example in RWT:
> +-- Shell ----------+
> |+Col1------------+Col2------+C3--+
> || | | | |
> ||________________|_|________|____|
> +-------------------+
>
> In this case I wish to disable the TextSizeDeterminationHandler, perhaps
> setting manually some properties in the control...
>
> Have any ideas or hints?
>
> Thanks
> Enrico
>
>
> Ralf Sternberg ha scritto:
>> Hi Enrico,
>>
>> you discovered one of the pieces of magic in RAP ;-)
>>
>> This code triggers a resize of all widgets after the results of the text
>> measurements arrive from the client. As the layout is already done
>> before (with estimated text sizes), we need to trigger a re-calculation
>> of widget's preferred sizes at this point.
>>
>> This trick turned out to work rather well, that's why it's still there.
>> In which respect does it hurt in your case?
>>
>> Best regards, Ralf
>>
>> Enrico Zanaga wrote:
>>> Hi,
>>>
>>> in method TextSizeDeterminationHandler.afterPhase, there's the following
>>> code:
>>>
>>> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>> shells[ i ].setSize( buffer );
>>> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>>>
>>>
>>> Why setting size buffer+1000 and then reset to buffer?
>>> Is needed to calculate something?
>>> If yes, can I avoid this "adjusting"?
>>>
>>> Thanks
>>> Enrico
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #121070 is a reply to message #120963] |
Mon, 09 February 2009 12:32 |
| Eclipse User |
|
|
|
We ran into the same problems with our resize listeners. We were getting
weird results due to the spurious resize events, not to mention the
flicker problems. Our solution was to create a custom resize listener that
we call WellBehavedControlAdapter. It tracks the previous size of the
control's shell and detects the resize events caused by the
TextSizeDetermination. Below is the code for those that are interested.
Cole
=== Begin WellBehavedControlAdapter.java ===
public abstract class WellBehavedControlAdapter extends ControlAdapter
{
@Override
public void controlResized(ControlEvent e)
{
Shell shell = ((Control)e.widget).getShell();
Point shellSize = shell.getSize();
Point previousSize =
(Point)e.widget.getData("previousShellSize"+this.hashCode());
e.widget.setData("previousShellSize"+this.hashCode(), shellSize);
if(previousSize != null){
int dx = Math.abs(Math.abs(shellSize.x - previousSize.x) - 1000);
int dy = Math.abs(Math.abs(shellSize.y - previousSize.y) - 1000);
if((dx <= 2 || dy <= 2)){
// This came from the TextSizeDetermination
return;
}
}
handleControlResized(e);
}
protected abstract void handleControlResized(ControlEvent e);
}
=== End WellBehavedControlAdapter.java ===
Ralf Sternberg wrote:
> Hi Enrico,
> I understand your case but I'm afraid there is currently no cure for it
> (unless you find some hack on your side ;-). Calculating layouts
> depending on previous states is not common, thus we didn't expect such a
> case.
> Best regards, Ralf
> Enrico Zanaga wrote:
>> Hi Ralf,
>>
>> in my application every table has a custom column auto size algorithm.
>>
>> The first time a table is shown, the columns spreads to the 100% of
>> table's width. When the table's width increase the columns' width
>> increase too, spreading to 100%. When the table's width decrease, the
>> columns' width don't decrease.
>>
>> This algorithm works in SWT, but in RWT when I open a shell with a table
>> the columns go directly out of the table, because "setSize( buffer.x +
>> 1000, buffer.y + 1000 )" increase the table's width. The result is
>> having a table with columns so large that's not visible.
>>
>> Example in SWT:
>> +-- Shell ----------+
>> |+Col1----+Col2-+C3+|
>> || | | ||
>> ||________|_____|__||
>> +-------------------+
>>
>> Example in RWT:
>> +-- Shell ----------+
>> |+Col1------------+Col2------+C3--+
>> || | | | |
>> ||________________|_|________|____|
>> +-------------------+
>>
>> In this case I wish to disable the TextSizeDeterminationHandler, perhaps
>> setting manually some properties in the control...
>>
>> Have any ideas or hints?
>>
>> Thanks
>> Enrico
>>
>>
>> Ralf Sternberg ha scritto:
>>> Hi Enrico,
>>>
>>> you discovered one of the pieces of magic in RAP ;-)
>>>
>>> This code triggers a resize of all widgets after the results of the text
>>> measurements arrive from the client. As the layout is already done
>>> before (with estimated text sizes), we need to trigger a re-calculation
>>> of widget's preferred sizes at this point.
>>>
>>> This trick turned out to work rather well, that's why it's still there.
>>> In which respect does it hurt in your case?
>>>
>>> Best regards, Ralf
>>>
>>> Enrico Zanaga wrote:
>>>> Hi,
>>>>
>>>> in method TextSizeDeterminationHandler.afterPhase, there's the following
>>>> code:
>>>>
>>>> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
>>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>>> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
>>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>>> shells[ i ].setSize( buffer );
>>>> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>>>>
>>>>
>>>> Why setting size buffer+1000 and then reset to buffer?
>>>> Is needed to calculate something?
>>>> If yes, can I avoid this "adjusting"?
>>>>
>>>> Thanks
>>>> Enrico
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #121102 is a reply to message #120862] |
Tue, 10 February 2009 03:33 |
| Eclipse User |
|
|
|
Hi Ralf,
the problem with this piece of magic is that it triggers additional
Resize-Events which results in different behaviour between SWT and RWT
(see https://bugs.eclipse.org/bugs/show_bug.cgi?id=231751).
Why doesn't a Shell#layout(true, true) work, instead?
Regards,
Stefan.
Ralf Sternberg schrieb:
> Hi Enrico,
>
> you discovered one of the pieces of magic in RAP ;-)
>
> This code triggers a resize of all widgets after the results of the text
> measurements arrive from the client. As the layout is already done
> before (with estimated text sizes), we need to trigger a re-calculation
> of widget's preferred sizes at this point.
>
> This trick turned out to work rather well, that's why it's still there.
> In which respect does it hurt in your case?
>
> Best regards, Ralf
>
> Enrico Zanaga wrote:
>> Hi,
>>
>> in method TextSizeDeterminationHandler.afterPhase, there's the following
>> code:
>>
>> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>> shells[ i ].setSize( buffer );
>> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>>
>>
>> Why setting size buffer+1000 and then reset to buffer?
>> Is needed to calculate something?
>> If yes, can I avoid this "adjusting"?
>>
>> Thanks
>> Enrico
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #121169 is a reply to message #121070] |
Wed, 11 February 2009 04:09 |
| Eclipse User |
|
|
|
Hi Cole,
Cole Markham wrote:
> We ran into the same problems with our resize listeners. We were getting
> weird results due to the spurious resize events, not to mention the
> flicker problems. Our solution was to create a custom resize listener
> that we call WellBehavedControlAdapter. It tracks the previous size of
> the control's shell and detects the resize events caused by the
> TextSizeDetermination. Below is the code for those that are interested.
I'm sorry to hear about those ugly hacks being necessary. As Stefan
pointed out, there is already a bug for the resize events problem. Feel
free to vote and comment on this one.
Unfortunately, the problem isn't trivial. The text size determination
gets the result when the layout is already done, so we need to trigger a
re-layout. I'm afraid we'll have to live with that until someone comes
up with an improvement that does not involve regressions in some other
cases.
Best regards,
Ralf
> === Begin WellBehavedControlAdapter.java ===
> public abstract class WellBehavedControlAdapter extends ControlAdapter
> {
> @Override
> public void controlResized(ControlEvent e)
> {
> Shell shell = ((Control)e.widget).getShell();
> Point shellSize = shell.getSize();
> Point previousSize =
> (Point)e.widget.getData("previousShellSize"+this.hashCode());
> e.widget.setData("previousShellSize"+this.hashCode(), shellSize);
> if(previousSize != null){
> int dx = Math.abs(Math.abs(shellSize.x - previousSize.x) - 1000);
> int dy = Math.abs(Math.abs(shellSize.y - previousSize.y) - 1000);
> if((dx <= 2 || dy <= 2)){
> // This came from the TextSizeDetermination
> return;
> }
> }
> handleControlResized(e);
> }
> protected abstract void handleControlResized(ControlEvent e);
> }
> === End WellBehavedControlAdapter.java ===
>
> Ralf Sternberg wrote:
>
>> Hi Enrico,
>
>> I understand your case but I'm afraid there is currently no cure for it
>> (unless you find some hack on your side ;-). Calculating layouts
>> depending on previous states is not common, thus we didn't expect such a
>> case.
>
>> Best regards, Ralf
>
>> Enrico Zanaga wrote:
>>> Hi Ralf,
>>>
>>> in my application every table has a custom column auto size algorithm.
>>>
>>> The first time a table is shown, the columns spreads to the 100% of
>>> table's width. When the table's width increase the columns' width
>>> increase too, spreading to 100%. When the table's width decrease, the
>>> columns' width don't decrease.
>>>
>>> This algorithm works in SWT, but in RWT when I open a shell with a table
>>> the columns go directly out of the table, because "setSize( buffer.x +
>>> 1000, buffer.y + 1000 )" increase the table's width. The result is
>>> having a table with columns so large that's not visible.
>>>
>>> Example in SWT:
>>> +-- Shell ----------+
>>> |+Col1----+Col2-+C3+|
>>> || | | ||
>>> ||________|_____|__||
>>> +-------------------+
>>>
>>> Example in RWT:
>>> +-- Shell ----------+
>>> |+Col1------------+Col2------+C3--+
>>> || | | | |
>>> ||________________|_|________|____|
>>> +-------------------+
>>>
>>> In this case I wish to disable the TextSizeDeterminationHandler, perhaps
>>> setting manually some properties in the control...
>>>
>>> Have any ideas or hints?
>>>
>>> Thanks
>>> Enrico
>>>
>>>
>>> Ralf Sternberg ha scritto:
>>>> Hi Enrico,
>>>>
>>>> you discovered one of the pieces of magic in RAP ;-)
>>>>
>>>> This code triggers a resize of all widgets after the results of the
>>>> text
>>>> measurements arrive from the client. As the layout is already done
>>>> before (with estimated text sizes), we need to trigger a re-calculation
>>>> of widget's preferred sizes at this point.
>>>>
>>>> This trick turned out to work rather well, that's why it's still there.
>>>> In which respect does it hurt in your case?
>>>>
>>>> Best regards, Ralf
>>>>
>>>> Enrico Zanaga wrote:
>>>>> Hi,
>>>>>
>>>>> in method TextSizeDeterminationHandler.afterPhase, there's the
>>>>> following
>>>>> code:
>>>>>
>>>>> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
>>>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>>>> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
>>>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>>>> shells[ i ].setSize( buffer );
>>>>> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>>>>>
>>>>>
>>>>> Why setting size buffer+1000 and then reset to buffer?
>>>>> Is needed to calculate something?
>>>>> If yes, can I avoid this "adjusting"?
>>>>>
>>>>> Thanks
>>>>> Enrico
>
|
|
|
| Re: TextSizeDeterminationHandler sets and resets the size of a widget [message #121196 is a reply to message #121102] |
Wed, 11 February 2009 04:55 |
| Eclipse User |
|
|
|
Hi Stefan,
Stefan Roeck wrote:
> the problem with this piece of magic is that it triggers additional
just to make this clear: the smiley was meant to indicate that we're not
really proud of this "magic". Actually, I don't think that magic is ever
a good thing in software design.
> Resize-Events which results in different behaviour between SWT and RWT
> (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=231751).
>
> Why doesn't a Shell#layout(true, true) work, instead?
As Rüdiger pointed out in the bug, there is code around that does the
layout based on resize events. This would not work anymore.
Best regards,
Ralf
> Ralf Sternberg schrieb:
>> Hi Enrico,
>>
>> you discovered one of the pieces of magic in RAP ;-)
>>
>> This code triggers a resize of all widgets after the results of the text
>> measurements arrive from the client. As the layout is already done
>> before (with estimated text sizes), we need to trigger a re-calculation
>> of widget's preferred sizes at this point.
>>
>> This trick turned out to work rather well, that's why it's still there.
>> In which respect does it hurt in your case?
>>
>> Best regards, Ralf
>>
>> Enrico Zanaga wrote:
>>> Hi,
>>>
>>> in method TextSizeDeterminationHandler.afterPhase, there's the following
>>> code:
>>>
>>> WidgetTreeVisitor.accept( shells[ i ], saveSCOrigins );
>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>> shells[ i ].setSize( buffer.x + 1000, buffer.y + 1000 );
>>> WidgetTreeVisitor.accept( shells[ i ], clearLayout );
>>> shells[ i ].setSize( buffer );
>>> WidgetTreeVisitor.accept( shells[ i ], restoreSCOrigins );
>>>
>>>
>>> Why setting size buffer+1000 and then reset to buffer?
>>> Is needed to calculate something?
>>> If yes, can I avoid this "adjusting"?
>>>
>>> Thanks
>>> Enrico
|
|
|
Goto Forum:
Current Time: Sun May 04 12:28:05 EDT 2025
Powered by FUDForum. Page generated in 0.09395 seconds |
Home