| Summary: | Invisible elements after scroll in ExpandableComposite on OS X only | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] NatTable | Reporter: | Marco Descher <marco> | ||||||||||
| Component: | GlazedLists Extension | Assignee: | Project Inbox <nattable.core-inbox> | ||||||||||
| Status: | CLOSED NOT_ECLIPSE | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | dirk.fauth | ||||||||||
| Version: | 2.0.3 | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Mac OS X | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Marco Descher
Created attachment 288762 [details]
visible (after click)
Sorry, but I don't understand what you are reporting. What gaps where. I don't spot the difference in the pictures. And the link you shared does not show any NatTable code. It only shows that you call some custom NatTableWrapper. No sights of the configuration or the painters used anywhere. Hy Dirk, the difference is, that the part that is shown in picture "visible" (bottom) is only visible after a mouse-click on the empty bottom space in the picture "invisible". In Windows this "additional click" is not required. I'll try to fix a video tommorrow to show it. I'm not sure if this is a NatTable problem, as NatTable does not have operating system specific code. I think it might be more something Nattable uses within SWT that has changed. I'll also try to delimit the versions where it last worked! I'll check back! Hi Marco, I noticed some comment that there was a switch to the RichTextCellPainter. Maybe related to the usage of the underlying browser? Created attachment 288764 [details]
parent scroll
I think I could trace it to some degree. I added a video "parent scroll" which traces the calls of AutoResizeRowPaintListener.paintControl(). The single NatTable entries are located within an ExpandableComposite which is embedded into another control being part of an E4 view. Now it seems to be the case, that scrolling the E4 view, does not leed to the event passing down, such that paintControl() gets automatically called. As soon as I manually click the control using the mouse, this is caught up on. This works fine on Windows, seems to be some SWT bug?! At least it doesn't seem to be related to the NatTable if it works on Windows and not on Mac. I really can't tell why scrolling the ExpandableComposite on Mac does not trigger a repaint on the underlying controls. Should be a question to the SWT team. Created attachment 288766 [details]
parent scroll in windows
ok, it really seems to boil down to this. I added another recording "parent scroll in windows" where you see that the exact same code gets the paintControl() function regularly called in windows. I guess I have to reword this bug and switch the project! Dirk, thanks for your help so far! SWT does not manage bugs in bugzilla anymore - issue created in https://github.com/eclipse-platform/eclipse.platform.swt/issues/415 As this issue doesn't seem to be related to NatTable and you created a ticket on the SWT project in GitHub, is it ok if I close this ticket here? (In reply to Dirk Fauth from comment #11) > As this issue doesn't seem to be related to NatTable and you created a > ticket on the SWT project in GitHub, is it ok if I close this ticket here? sure - thank you! I close this ticket as it is not related to the NatTable project. Thanks for reporting and investigating. |