|
|
Re: Usage of IMessageManager [message #472355 is a reply to message #472349] |
Fri, 29 February 2008 15:41 |
Eric Rizzo Messages: 3070 Registered: July 2009 |
Senior Member |
|
|
Vel wrote:
> Hi,
>
> I have a multipage editor (derived from FormEditor) with one page
> (IFormPage). I divided the page into two using TableWrapLayout. The left
> side has couple of text and combo controls and the right has a table
> viewer with popular Add, Remove buttons. I have a 'Save' button on the
> workbench toolbar to save contents of the form.
>
> I am trying to use the MessageManager capability of Forms 3.3 to throw
> the messages. To begin with, I added an error message using
> page.mananged_form.getMessageManager(). The error message is displayed
> properly.
>
> Here is the issue.
> Though the table viewer has both scroll bars, after an item is added it
> and message is added to MessageManager through my save button, the
> viewer gets resized and the scroll bar disappears. This further leads to
> resize of the left and right composites. I thought this is because of
> layout and layoutData of my controls but all are clear. When there is an
> entry in table viewer but message is not added to MessageManager
> (addMessage call is commented in Save action), there is no resize.
I've run into this several times. The first thing to understand is that
adding/removing messages causes a re-layout of the entire page - that is
why you only see this when messages are added/removed. I bet that if you
put collapsible sections on your page you would see the same behavior
when you collapse/expand them (section expand/collapse triggers a
re-layout, too).
So when the page is re-layout-ed, what happens is that one of the
composites that contains the table (or its parent(s)) is using the
table's preferred size to calculate the layout. The table's preferred
will generally be large enough to render all of its contents without
scrolling, so when one of the parent layouts asks, that is what it gets.
The fix I use is to put the table inside a GridLayout (or other layout
that allows specification of a widthHint) and then set the table's
widthHint to 1. As long as the table is also set to fill/grab, it will
stretch to fill available space; but the widthHint of 1 forces its
preferred size to never cause the parent to grow.
When I do this, by the way, I also include a comment in the code where
th widthHint is set so that anyone reading the code later (including
myself) understands why this seemingly silly setting is there.
Hope this helps,
Eric
|
|
|
|
|
Re: Usage of IMessageManager [message #609963 is a reply to message #472349] |
Fri, 29 February 2008 15:41 |
Eric Rizzo Messages: 3070 Registered: July 2009 |
Senior Member |
|
|
Vel wrote:
> Hi,
>
> I have a multipage editor (derived from FormEditor) with one page
> (IFormPage). I divided the page into two using TableWrapLayout. The left
> side has couple of text and combo controls and the right has a table
> viewer with popular Add, Remove buttons. I have a 'Save' button on the
> workbench toolbar to save contents of the form.
>
> I am trying to use the MessageManager capability of Forms 3.3 to throw
> the messages. To begin with, I added an error message using
> page.mananged_form.getMessageManager(). The error message is displayed
> properly.
>
> Here is the issue.
> Though the table viewer has both scroll bars, after an item is added it
> and message is added to MessageManager through my save button, the
> viewer gets resized and the scroll bar disappears. This further leads to
> resize of the left and right composites. I thought this is because of
> layout and layoutData of my controls but all are clear. When there is an
> entry in table viewer but message is not added to MessageManager
> (addMessage call is commented in Save action), there is no resize.
I've run into this several times. The first thing to understand is that
adding/removing messages causes a re-layout of the entire page - that is
why you only see this when messages are added/removed. I bet that if you
put collapsible sections on your page you would see the same behavior
when you collapse/expand them (section expand/collapse triggers a
re-layout, too).
So when the page is re-layout-ed, what happens is that one of the
composites that contains the table (or its parent(s)) is using the
table's preferred size to calculate the layout. The table's preferred
will generally be large enough to render all of its contents without
scrolling, so when one of the parent layouts asks, that is what it gets.
The fix I use is to put the table inside a GridLayout (or other layout
that allows specification of a widthHint) and then set the table's
widthHint to 1. As long as the table is also set to fill/grab, it will
stretch to fill available space; but the widthHint of 1 forces its
preferred size to never cause the parent to grow.
When I do this, by the way, I also include a comment in the code where
th widthHint is set so that anyone reading the code later (including
myself) understands why this seemingly silly setting is there.
Hope this helps,
Eric
|
|
|
|
Powered by
FUDForum. Page generated in 0.04774 seconds