Bugzilla – Full Text Bug Listing
| Summary: | SWT Table resize "breaks apart" with PaintItem Listener | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | mtrudgia | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipse.felipe | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
Remove the SWT.NO_BACKGROUND flag from the Shell (or better, remove all those flags, use SWT.SHELL_TRIM instead). I think SWT.NO_BACKGROUND is not implemented in Cocoa, that is why you don't see the problem there. Closing. Unfortunately, this does not fix the problem. The SWT.SHELL_TRIM appears to have no affect on Win7. Removing SWT.NO_BACKGROUND somewhat "disguises" the problem, because the black regions that can be seen in my example application become "white" when you remove this flag. But that is not a fix... the problem still exists. 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. |
Created attachment 192996 [details] Simple Application exhibiting the problem Running the attached application, and performing large resizing of the shell, you can see black regions to the bottom and right of the table. As you slow down the resizing, or even hold the mouse stationary during resize, the black regions disappear. This appears to be due to the PaintItem listener. If you comment out both the EraseItem and PaintItem listeners from the attached code, resize behaves smoothly and as expected. NOTE: Does not appear to happen on MAC OSX, but does on Vista and Windows 7, and potentially other Windows flavors.