Bugzilla – Full Text Bug Listing
| Summary: | [disassembly] maximizing/resizing view sometimes leaves "........" lines | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Kirk Beitz <kirk.beitz> | ||||
| Component: | cdt-debug-dsf | Assignee: | Anton Leherbauer <aleherb+eclipse> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Pawel Piech <pawel.1.piech> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aleherb+eclipse, ken.ryall, pawel.1.piech | ||||
| Version: | 7.0 | Flags: | aleherb+eclipse:
review+
|
||||
| Target Milestone: | 7.0.1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Thanks, the patch looks good. Committed the patch to HEAD and cdt_7_0. |
Created attachment 178280 [details] DisassemblyPart.java 1.2 patch to cause TextViewer#updateViewportListeners() to cause listeners' viewportChange() to be invoked the problem: it is possible when resizing the Disassembly tab for the view to wind up containing "........" sections. (i first experienced this when double clicking to maximize, but demonstrated the problem could occur with a drag downward resize of the pane containing the view.) find attached a 3-line patch that solves this problem in the testing i've done. (using EDC within nokia eclipse-based carbide, this can occur by stepping from the main function into the main's first run-time function, back out, and then into the wrapper for the first user function, back out, and then into the first user function. the main and user functions are close but not contiguous in memory, so the view separates them just off-screen with "........". when the maximize occurs, about the third line from bottom contains the "........". it's reproducible in carbide very time without the patch, and never occurs with the patch. drag re-size will expose it right near the bottom as well.) my determination of the primary root cause leading to this failure is that TextViewer#updateViewportListeners() only calls listeners' viewportChanged() in cases where locally cached fTopPixel differs from fTextWidget.getTopPixel(). the case of the viewport being resized downward (which is what happens for a maximize or a resize drag downward) does not cause a viewportChanged() call. the attached (admittedly quick-n-dirty) solution: TextViewer exposes protected fLastTopPixel ... and DisassemblyViewer#updateViewportListeners() already consults it in order to set a variable for a getter used by DisassemblyPart. the patch simply resets the exposed value to -1 (the initial value) in cases that a RESIZE is the reason for the call. TextViewer#updateViewportListeners() sets fTopPixel as soon as it determines this fudged cached value differs from TextViewer.fTextWidget#getTopPixel() , and now that it is different, the logic will also cause its listeners' viewportChanged() to be invoked, filling the "........" regions to get filled. the "proper" solution might eventually (or sooner!) be to fix TextViewer to cache the width & height the same way it caches topPixel, but that will be a much more complicated patch, will affect a lot more views, and thus may cause unnecessary instability for what, for nokia, needs to be a very near term solution. hoping the attached patch is good enough for now for both CDT_7_0 (if there's still time) and HEAD.