[
https://issues.apache.org/jira/browse/PIVOT-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057738#comment-13057738
]
Chris Bartlett edited comment on PIVOT-768 at 6/30/11 10:23 AM:
----------------------------------------------------------------
(1) Assuming that TablePane.Filler is actually used by designers/developers
when aligning cells, simply making it default to being non-visible takes care
of the blocked event issue.
Then it would just be a case of adding as many Fillers as required, without any
additional markup or code to set the 'visible' property.
This would not stop any *other* Components being used as fillers - but I doubt
that is a real world problem.
(2) While the z-order idea would be a much more complete solution, I'm not sure
that the potential benefits would outweigh the effort involved.
Are there use cases for a having overlayed components that are specified via a
TablePane?
I imagine using a Panel for this, or writing a custom container to meet the
specific requirement.
(3) The javadocs for TablePane *do* discuss the root of the 'problem'...
"Note that unlike an HTML <table>, components that span multiple rows or
columns will not "push" other components out of their way. Instead, the
spanning components will simply overlay the cells into which they span. This
means that application developers may have to use filler cells in the cells
that are spanned"
http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/TablePane.html
I didn't see this until after my problem, and can't speculate as to whether it
is because it simplifies the layout logic, was a specific design choice to
allow overlayed cells, or if there is a more subtle reason.
So, how about if TablePane just managed the Filler components itself? ie, if I
have a Component with a colspan of 3, the TablePane would insert 2 Fillers into
the TablePane.Row after that component. That way, none of the layout logic
needs to change and BXML markup would be simpler.
Obviously, changes to the colspan (and rowspan) values would need to be
monitored to insert/remove as appropriate.
Finally, I wouldn't expect the Fillers to trigger TablePaneListenerList
'cellInserted' or 'cellsRemoved' events, but that is just my opinion.
was (Author: cbartlett):
(1) Assuming that TablePane.Filler is actually used by designers/developers
when aligning cells, simply making it default to being non-visible takes care
of the blocked event issue.
Then it would just be a case of adding as many Fillers as required, without any
additional markup or code to set the 'visible' property.
This would not stop any *other* Components being used as fillers - but I doubt
that is a real world problem.
(2) While the z-order idea would be a much more complete solution, I'm not sure
that the potential benefits would outweigh the effort involved.
Are there use cases for a having overlayed components that are specified via a
TablePane?
I imagine using a Panel for this, or writing a custom container to meet the
specific requirement.
(3) The javadocs for TablePane *do* discuss the root of the 'problem'...
"Note that unlike an HTML <table>, components that span multiple rows or
columns will not "push" other components out of their way. Instead, the
spanning components will simply overlay the cells into which they span. This
means that application developers may have to use filler cells in the cells
that are spanned"
http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/TablePane.html
I didn't see this until after my problem, and can't speculate as to whether it
is because it simplifies the layout logic, was a specific design choice to
allow overlayed cells, or if there is a more subtle reason.
So, how about if TablePane just the Filler components itself? ie, if I have a
Component with a colspan of 3, the TablePane would insert 2 Fillers into the
TablePane.Row after that component. That way, none of the layout logic needs
to change and BXML markup would be simpler.
Obviously, changes to the colspan (and rowspan) values would need to be
monitored to insert/remove as appropriate.
Finally, I wouldn't expect the Fillers to trigger TablePaneListenerList
'cellInserted' or 'cellsRemoved' events, but that is just my opinion.
> Using TablePane.Filler to align cells in a TablePane can result in blocked
> mouse input when a Component's 'columnSpan' is > 1
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: PIVOT-768
> URL: https://issues.apache.org/jira/browse/PIVOT-768
> Project: Pivot
> Issue Type: Improvement
> Components: wtk, wtk-terra
> Affects Versions: 2.0
> Environment: n/a
> Reporter: Chris Bartlett
> Priority: Minor
> Fix For: 2.1
>
> Attachments: table_pane_filler_issue.bxml, table_pane_filler_issue.png
>
>
> See attached BXML file and screenshot
> A workaround is to make the 'filler' Component non-visible, whether it is an
> actual TablePane.Filler or something else.
> (A non-visible Label works exactly the same as a TablePane.Filler instance)
> Perhaps TablePane.Filler should default to being non-visible to avoid this
> problem?
> I haven't investigated this in any way, so making the change may well have
> ramifications elsewhere.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
