[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-484) OverlayHelper removes table header if a form is contained in a JTable

[Andy D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy DePue resolved RCP-484.
----------------------------

    Resolution: Fixed

Fix committed as SVN revision #1799.


> OverlayHelper removes table header if a form is contained in a JTable
> ---------------------------------------------------------------------
>
>                 Key: RCP-484
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-484
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Binding System
>    Affects Versions: 0.3.0
>            Reporter: Andy DePue
>            Assignee: Andy DePue
>             Fix For: 0.3.0
>
>
> I have a modified JTable that creates a Spring Rich form for each row.  This allows us to develop a table row using a UI designer, then have this modified table instantiate it for each row.  Each row's form is then added to the enclosing parent form in order to support validation.  This all works fine now, except that when a row form is bound, the table header is removed!  After tracking this down, I've determined the culprit is OverlayHelper.  In order to support JScrollPanes (which this table happens to be in), OverlayHelper will remove the view component from a JScrollPane, add it to a JLayeredPane, then add that JLayeredPane to the JScrollPane.  This has the effect of removing the table's header from the JScrollPane, and since JLayeredPane knows nothing of table headers, the table header is never seen again.  OverlayHelper wants the JLayeredPane to be scrolled in order to avoid having to calculate scroll offsets and clipping boundaries for the overlay icons.
> I've created a preliminary fix by redesigning how OverlayHelper works.  The whole idea of replacing a JScrollPane's view component with a JLayeredPane is prone to many issues (this isn't the first bug to result from this approach).  The real fix is to figure out how to calculate overlay offsets and clipping boundaries on a component, whether it is in a scrollpane or not, and then handle the placement of the overlay in the rootpane's layered pane.  This would completely eliminate the need for OverlayHelper to ever instantiate a custom JLayeredPane, let alone replace a view component.
> I will be checking in the changes to OverlayHelper (and the unit tests) soon, and I encourage everyone to stress test this to make sure I didn't miss any corner cases.
> BTW, OverlayHelper uses components for the overlay as opposed to a custom "painter" (which is good), but it makes clipping a little tricky.  Since OverlayHelper uses the rootpane's layered pane exclusively now, clipping is very important so that an overlay within a JScrollPane is not painted outside the boundaries of the scrollpane when it is scrolled out of view (or even partially out of view).  My quick and dirty approach is to enclose the overlay component into a JPanel, then when clipping is required, I size the JPanel to the clip bounds, and adjust the position of the overlay component within the JPanel appropriately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira