Bugzilla – Full Text Bug Listing
| Summary: | setToBeRendered(true) on a Part does not re-draw the UI | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Lars Vogel <Lars.Vogel> | ||||||||
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> | ||||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | Lars.Vogel, remy.suen | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows 7 | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 181224 [details]
number2
Created attachment 181225 [details]
number3
(In reply to comment #0) > findPart = service.findPart("de.vogella.e4.tododetails"); > findPart.setToBeRendered(false); > findPart.setToBeRendered(true); I thought the stack's selectedElement had changed to 'null' after the second line but this doesn't appear to be the case. So it seems to me that the third line should have caused the renderer to both recreate the tab item (which it does) and also select it (which it does _not_). After talking this over with Remy we think that the following 'rule' makes sense: The selectedElement (SE) of a container must be: a) a child of the container (obvious) *AND* b) its TBR must be true (we can't find a scenario where having an SE that isn't rendered in the UI makes sense) The rendering engine can(will) enforce this by setting the SE to null whenever it detects that the above conditions no longer apply. The rendering engine will *never* attempt to determine a new 'correct' value for the SE (i.e. the only change it will ever make is to set it to null). It would be up to the code making the changes in the model to pick a new selected element. The rendering engine simply doesn't have enough info to make a valid selection (i.e. in the compat layer the new selected element should be determined through the 'activation history'. In this particular scenario the engine couldn't 'know' whether or not the call to findPart.setToBeRendered(true) wasn't going to be followed by a few more calls showing other parts...
BTW, there's a fairly simple pattern that can be used to re-institute the naive version of 'auto-select'.
Add a listener that detects when the 'selectedElement' goes to null and do the following:
// Selects the first visible entry in the presentation
for (MUIElement element : container.getChildren()) {
if (element.isToBeRendered() && element.isVisible()) {
container.setSelectedElement(element);
break;
}
}
Thanks Eric. WORKFORME |
Created attachment 181223 [details] number1 If I get a part and call setToBeRendered(false); setToBeRendered(true) then the SWT Widgets are not drawn. If I then click on the part header the controls are drawn. Here is what I do: findPart = service.findPart("de.vogella.e4.tododetails"); findPart.setToBeRendered(false); findPart.setToBeRendered(true); --> The part is shown again but its controls are not visible. Please see the attached screenshots.