Bug 363755

Comment 1 Konstantin Komissarchik 2011-11-14 20:33:07 EST

The Scale Vertically setting is controlled at every part level. The developer gets to specify how far up the parts hierarchy the stretching behavior should apply. This can be a bit confusing at first as you apply Scale Vertically setting at property editor level and then wonder why nothing changes, but the behavior is intentional. You need to be able to control where scaling stops. 

Please re-open if I misunderstood and this is referencing bugs where a part is either missing or isn't honoring the Scale Vertically setting. We've seen cases of that. Probably should open separate bugs for each of such cases in any case.

Comment 2 Rob Cernich 2011-11-14 20:54:34 EST

Hey Konstantin,

If you look at the updated architecture sample (attached to #360362), you will see that I've set scale vertically on the entire model hierarchy (section and property).  If you look at the code in DefaultListPropertyEditorRenderer.createContents(), you will see that there are intermediate Composite objects that are created which do not have their layout data set correctly for "scale vertically" (specifically, line 206).

It actually took me a bit of work just to get the sample to the point where it would "fill" the space, let alone "grab" it.  Based on that, I am _guessing_ there are other places like this lurking in the code (I removed one of the intermediate Composite objects in SapphireSection).  If you want to leave this as specific to list properties, creating separate defects as required, that's fine with me.  (I just thought it might be good for somebody to survey the various controls to make sure any intermediate Composite objects have their layout data set appropriately.)

Let me know if you need anything else.

Rob

Comment 3 Konstantin Komissarchik 2011-11-14 21:36:39 EST

DefaultListPropertyEditorRenderer definitely supports vertical scaling. You can see multiple examples of it working in the samples. For instance, the EzBug sample. 

On line 206 in DefaultListPropertyEditorRenderer, gdfill() function is used to set layout data. That function creates a layout data object that fills in both directions. 

The new form editor page feature in Bug 360362 is definitely experiencing layout problems. The issues are in the page implementation and possibly in section. Perhaps take a look at use of TableWrapLayout in StandardFormEditorPage.createFormContent() around line 92.

At this point, this looks like a necessary continuation of Bug 360362, so I will resolve this as duplicate of that bug. If other specific cases are found where scale vertically does not work, we can open separate bugs.

*** This bug has been marked as a duplicate of bug 360362 ***

Comment 4 Rob Cernich 2011-11-15 09:16:19 EST

Hey Konstantin,

(In reply to comment #3)
> On line 206 in DefaultListPropertyEditorRenderer, gdfill() function is used to
> set layout data. That function creates a layout data object that fills in both
> directions. 
> 
Yep.  My eyes must have been tired not to see that.

> The new form editor page feature in Bug 360362 is definitely experiencing
> layout problems. The issues are in the page implementation and possibly in
> section. Perhaps take a look at use of TableWrapLayout in
> StandardFormEditorPage.createFormContent() around line 92.
> 
That is indeed the problem.  From the TableWrapData.grabVertical, "Note that since TableWrapLayout works top-down and does not grow to fill the parent..."

However, this problem is not particular to the new code.  I chose to use TableWrapLayout because SapphireSection was already setting a TableWrapData and I didn't want to change anything that was not necessary.  I was also able to reproduce this in the master/details page (though, I'm not confident that I modified all the properties necessary).  Anyway, if you could try modifying the sdef for DetailsPage, you should be able to see the same behavior.

That said, I'm already patching up the layout data on the sections, so I could have just as well switched to GridLayout.

Thanks for setting me straight.
Rob

Comment 5 Konstantin Komissarchik 2011-11-15 11:45:21 EST

> However, this problem is not particular to the new code.  I chose to use
> TableWrapLayout because SapphireSection was already setting a TableWrapData and
> I didn't want to change anything that was not necessary.  I was also able to
> reproduce this in the master/details page (though, I'm not confident that I
> modified all the properties necessary).

Yes, the section part doesn't currently support scale vertically. Its an artifact of using TableWrapLayout in master details as you've discovered in the custom form editor page. At some point we may need to re-write the top-level layout logic of master details page.