Community
Participate
Working Groups
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727) Build Identifier: 20090621-0832 For controls on a composite that is scrollable (like the CompositeTable) the user can easily achieve that error marlers are drawn outside the cmoposite by scrolling the error marked widgets nea the left border. Error markers drawn in this situation do not get cleared when scrolling back and other actions that require redrawing. see screenshots and snippet. Reproducible: Always Steps to Reproduce: see code and screenshots attached
Created attachment 151162 [details] snippet with sample code
Created attachment 151163 [details] steps to reproduce behaviour
Spend a few minutes with the example. I believe that this is due to a limitation of JFace's ControlDecoration class. See also Bug #208397 which is seems related. Need to spend an hour to look into it properly.
He, he, this is an interesting one. In CompositeTable the widget to ridget binding changes when the Table is scrolled or resized. This is not the problem yet. The problem is that we don't clear and re-apply the ControlDecoration when the control is unbound. See attached MarkerBug002 for a demo. I'll experiment to find out how we can fix this.
Created attachment 160386 [details] Snippet to reproduce issue
Created attachment 160387 [details] Snippet to reproduce issue
This affects more that the ControlDecoration. Also foreground and background are affected.
Created attachment 160388 [details] Snippet to reproduce issue
When the decorated control is moved one has to repaint both the old border position (was not done - will remove border) and the new border position (was done). Fixed in HEAD.
Oops, wrong bug.
Reassigning to default assignee.
Created attachment 213297 [details] fix + test Elias thanks for the Snippet. The problem here is that the error decoration object (in this case ControlDecoration) inside the MarkerSupport is always associated with the control, passed to its constructor. The first time an error marker is set, a ControlDecoration object is created, cached, and used for all subsequent error markers for this _ridget_. if (errorDecoration == null) { errorDecoration = createErrorDecoration(control); } But if we set a new UI control to this ridget, the cached error decorator must be reset too. This was not the case. In the proposed fix (see patch) I moved the cache to the UI control object using setData(key, errorDecoration) if (control.setData(ERROR_DECORATION_FOR_CONTROL_KEY) == null) { control.setData(ERROR_DECORATION_FOR_CONTROL_KEY, createErrorDecoration(control)); }
pushed to git
