Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340340

Summary:

[Forms] SharedScrolledComposite.reflow(boolean) does not properly reflow to resize the section in question

Product:

[Eclipse Project] Platform

Reporter:

zengland

Component:

User Assistance

Assignee:

platform-ua-inbox <platform-ua-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

cgold, eclipse.felipe, steeg

Version:

4.1

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

stalebug

Attachments:

Description	Flags
This is the section in question before a maximize	none
This is the section in question after a maximize	none
This is the section in question after a maximize and expand/collapse	none
This is the section in question before a maximize	none

Description zengland

2011-03-17 12:00:37 EDT

Build Identifier: Version: 3.4.2 Build id: M20090211-1700

Editor which extends EditorPart implements ITabbedPropertySheetPageContributor,

which contains 4 org.eclipse.ui.forms.SectionPart

the top section contains a org.eclipse.ui.views.properties.tabbed.TabbedPropertySheetPage

when the first tab in this is not as tall as a later tab,
so that the later tab needs a vertical scrollbar

resizing the editor via a 'maximize' action eliminates the scrollbar in the tabbedPropertySheetPage UI so that not all
of the contents can be seen.

However, expanding any other section in the editor causes the UI to reflow and/or layout so that the section containing the tabbedPropertySheetPage is now tall enough to not need a scrollbar. This is a terribly ugly workaround about which our customers will complain.


It seems that on a maximize/restore action
org.eclipse.ui.forms.widgets.SharedScrolledComposite.reflow(boolean) does not properly reflow to resize the section in question
though a section expanding will cause it to reflow/resize correctly.

Reproducible: Always

Steps to Reproduce:
In details field

Comment 1 zengland

2011-03-17 12:04:28 EDT

Created attachment 191434 [details]
This is the section in question before a maximize

Comment 2 zengland

2011-03-17 12:05:03 EDT

Created attachment 191435 [details]
This is the section in question after a maximize

Comment 3 zengland

2011-03-17 12:05:51 EDT

Created attachment 191436 [details]
This is the section in question after a maximize and expand/collapse

Comment 4 zengland

2011-03-17 12:06:46 EDT

Created attachment 191437 [details]
This is the section in question before a maximize

Comment 5 Fabian Steeg

2011-03-18 14:58:53 EDT

If the version set on this bug is correct (4.1) and not the version from comment 0 (Version: 3.4.2 Build id: M20090211-1700) I might be hitting a related issue: since 4.1M5, our ScrolledComposite grows larger than its parent if any part stack (not only the one that contains the ScrolledComposite) is resized. Our workaround is to set the ScrolledComposite to the size of its parent in a control listener, something like this:

sc.addControlListener(new ControlListener() {
  public void controlResized(final ControlEvent e) {
	sc.setSize(sc.getParent().getSize());
  }
  public void controlMoved(final ControlEvent e) {}
});

Comment 6 Chris Goldthorpe

2011-04-18 17:23:41 EDT

Can you attach a test case to the bug report?

Comment 7 Lars Vogel

2019-11-14 02:20:23 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant, please remove the "stalebug" whiteboard tag.