Home » Eclipse Projects » Standard Widget Toolkit (SWT) » SearchDialog overrides user set layout data
| SearchDialog overrides user set layout data [message #458657] |
Mon, 18 July 2005 12:56  |
Eclipse User |
|
|
|
I created my own ISearchPage by extending DialogPage. In it I create a
widget that is supposed to stretch to the full page size. This is the
intended behavior. In the createControl method I set the layout data on
the widget to be new GridData(GridData.FILL_BOTH). To my surprise the
SearchDialog class overrides this by setting layout data to
new GridData(SWT.FILL, SWT.BEGINNING, true, false)
The last false undoes the effect of my settings, making the widget
scrunched against the top side of the tab. I can set the height hint, but
this is not what I wish to have. I want the user to be able to stretch the
page and see the complete widget, rather than use a scroll bar (say, using
ScrolledComposite). I feel that setting layout data without regard for
what the user set is wrong. However, before I file a bug, I would like to
see if anybody knows a standard way around this? At the moment I had to
re-implement setLayoutData in my widget to prevent it from setting new
layout data if one was already set. Is there a better, more "standard"
approach?
|
|
|
| Re: SearchDialog overrides user set layout data [message #458664 is a reply to message #458657] |
Mon, 18 July 2005 14:26  |
| Eclipse User |
|
|
|
Originally posted by: sunil_kamath.nohotspammail.com
"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:pan.2005.07.18.16.56.16.834299@n0spam.majewski.com...
>I created my own ISearchPage by extending DialogPage. In it I create a
> widget that is supposed to stretch to the full page size. This is the
> intended behavior. In the createControl method I set the layout data on
> the widget to be new GridData(GridData.FILL_BOTH). To my surprise the
> SearchDialog class overrides this by setting layout data to
>
> new GridData(SWT.FILL, SWT.BEGINNING, true, false)
>
> The last false undoes the effect of my settings, making the widget
> scrunched against the top side of the tab. I can set the height hint, but
> this is not what I wish to have. I want the user to be able to stretch the
> page and see the complete widget, rather than use a scroll bar (say, using
> ScrolledComposite). I feel that setting layout data without regard for
> what the user set is wrong. However, before I file a bug, I would like to
> see if anybody knows a standard way around this? At the moment I had to
> re-implement setLayoutData in my widget to prevent it from setting new
> layout data if one was already set. Is there a better, more "standard"
> approach?
I understand your frustration; however, the layout is owned by the dialog -
not your page.
You own the layout for anything your page contains.
You cannot assume that the dialog is using GridLayout. (I know it does, but
you can't assume it).
A workaround perhaps would be to see what other ISearchPages do and then
copy it.
---
Sunil
|
|
| | |
| Re: SearchDialog overrides user set layout data [message #458708 is a reply to message #458707] |
Tue, 19 July 2005 14:47 |
| Eclipse User |
|
|
|
> How do you know what the layout of the container is? Rght now you know it is
> GridLayout because you peeked.
> What if the implementation changes? Will you maintain two versions of your
> component?
No, I do not maintain two implementations. I don't care what layout the
container uses. As far as I am concerned it may be FillLayout. The point
is that if I am given the entire area, I can choose to use only the top
part. If I am given the top part only, I have no choice.
My argument is no longer based on me setting any layout data. I agreed
that I should not rely on this. Instead I want to be given the entire
page, so that I have a choice of how much of it I am going to fill. How I
am given it (which layout is used by the container) is not what I am
concerned with.
In my previous post I argued that if my control is stretched, by whatever
means, to cover the entire page, I still have an option of making it
compact and aligned against the top. So this solution does not take
anything away from my choices. It gives me, however, the ability to design
a large page, more responsive to a user resizing it. I hope this is a
better explanation that conveys more accurately my arguments in favor of a
full page control.
|
|
|
| Re: SearchDialog overrides user set layout data [message #458709 is a reply to message #458708] |
Tue, 19 July 2005 14:58 |
| Eclipse User |
|
|
|
Originally posted by: sunil_kamath.nohotspammail.com
"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:pan.2005.07.19.18.47.56.92876@n0spam.majewski.com...
>> How do you know what the layout of the container is? Rght now you know it
>> is
>> GridLayout because you peeked.
>> What if the implementation changes? Will you maintain two versions of
>> your
>> component?
>
> No, I do not maintain two implementations. I don't care what layout the
> container uses. As far as I am concerned it may be FillLayout. The point
> is that if I am given the entire area, I can choose to use only the top
> part. If I am given the top part only, I have no choice.
>
> My argument is no longer based on me setting any layout data. I agreed
> that I should not rely on this. Instead I want to be given the entire
> page, so that I have a choice of how much of it I am going to fill. How I
> am given it (which layout is used by the container) is not what I am
> concerned with.
>
> In my previous post I argued that if my control is stretched, by whatever
> means, to cover the entire page, I still have an option of making it
> compact and aligned against the top. So this solution does not take
> anything away from my choices. It gives me, however, the ability to design
> a large page, more responsive to a user resizing it. I hope this is a
> better explanation that conveys more accurately my arguments in favor of a
> full page control.
OK, fair enough. I see what you mean.
---
Sunil
|
|
|
Goto Forum:
Current Time: Thu Jul 03 11:05:49 EDT 2025
Powered by FUDForum. Page generated in 0.06505 seconds |
Home