🚀 go-pugleaf

John,

Thanks for your long and considered response.

I did go ahead and use the JPanel approach, which solved the problem of
seeing the button as a normal sized button and normal background around it.

In the end I simply used a Button-based CellEditor and this works too.
There are two small glitches with this idea, which I will attempt your
second solution to fix.

The first problem is that the ENTIRE cell sees the click and not the button.
The second problem is that, since the CellEditor is a JButton, it resizes
itself to the full cell dimensions.  It does appear as a depressed button
but full cell size.

Now that I have this basically working, I have to move to other stuff, but I
will come back later and have a go.

Thanks again for the considerable thought that you put into your answer.

David

"John P. McGrath" <JPMcGrath@fast.net> wrote in message
news:MPG.13e83b933788f585989a71@forums.borland.com...
> On Mon, 24 Jul 2000 23:02:26 -0700, David W. Taylor wrote:
>
> > 3. See the depressed button, with normal button behavior
> > and listen for the mouse up.  The mouse click should
> > appear to be sensed by the button and not the entire
> > cell.
>     :
> > Does anyone have a clear example of how this theoretically
> > simple task is done, particularly step 3?
>
> I would not agree that the task is theoretically simple.  Effectively,
> what you are trying to do is to place a JComponent in a JTable cell, but
> a JTable is not a "container" for JComponents.  Instead, it contains
> cells and it can paint or edit the cells using a component.
>
> I have thought of two possible approaches to this problem:
>
> The first sounds like what you have been trying, and I am less confident
> that this approach will work.  In this approach, you use a JButton-based
> TableCellRenderer to paint the cell, and use a TableCellEditor to create
> an actual button in the cell when it is needed.
>
> The problem I see with this approach is to get the button to become
> pressed by a mouse click that occurs before the button is created.  You
> may be able to initialize the button in a pressed state, which will
> partially solve the problem.
>
> One glitch you may run into has to do with focus transfer.  JTable does
> not always appear to transfer focus to the cell editor when the editor is
> realized.  I think it behaves differently when you
>
> There is another possible glitch with this, although JTable may already
> solve this in the general case.  Since the mouse press occurs on the
> JTable itself, and any drag events and the mouse release event will be
> sent to the table as well.  So you may have to add listeners to the
> JTable that will forward these events to the button.
>
> I presume that this is close to what you have tried.  If so, how is it
> different?  And what have you done about handling the initial mouse
> click, or about transferring focus to the CellEditor.
>
>
> ===========
>
> The other approach is a lot more general and extensible, and I think it
> is more likely to work without problems.  This design is not trivial, but
> is is certainly doable.
>
> In this approach, you give up on trying to emulate the button using
> TableCellRenderers and TableCellEditors.  Instead, you will place real
> live components (buttons in this case) above the table instead of in the
> table.  This will necessarily give up the advantage that a JTable has of
> not actually creating a separate instance for each component, so you
> would not want to use this with a really large number of such components.
>
>
> To do this, you will first create component, call it a RealTable, which
> is derived from JPanel and has a "layered" LayoutManager, which will
> arrange all of its components at the same size and position, one on top
> of the other.  In this panel, you place two components: the JTable
> supplied by the caller on the bottom and a transparent JPanel derived
> panel on top.  You will use the RealTable in place of the JTable, so you
> would add it to a scroll pane rather than the JTable.
>
> You can then place any component you would like on the transparent panel.
> These will sit above the JTable, so the components you place on it will
> react exactly as you would expect, without doing anything special.  The
> scroll pane will scroll the RealTable, so it will scroll the transparent
> panel and the JTable together.
>
> Now you have to worry about placing the components in the correct place
> on the transparent panel so that they appear over the correct cell in the
> JTable.  To handle this, you create a custom CellLayoutManager for the
> transparent panel that accepts [row,column] positions as constraints and
> positions the cells over the corresponding cell.
>
> The columns may be re-sized and re-ordered on the fly, so the transparent
> panel will have to listen to the JTable (or its TableColumnModel), and
> revalidate when this changes.
>
> You also have to worry about where to place the component within the
> cell, and how to size the component according to the size of the cell.
> The most general way to handle this would be to create a separate
> transparent CellPanel for each cell that you want to place a component
> over.  Then the CellLayoutManager would always size the CellPanel to the
> exact size of the cell, and the caller could use whatever LayoutManager
> he would like to arrange the contents of the CellPanel.
>
> One advantage of this design is that, once you have it working, it should
> work for any JComponent.  You will not have to create special renderers
> to draw the cell, and worse, create special editors with funky code to
> activate them.  The components can also have a permanent state, rather
> than be initialized every time the user clicks on the cell.
>
> As I said, this design is not ideal if you are going to have a very large
> number of components "added" to JTable.  But I suspect that that would
> not be a problem for most uses.
>
> If you choose to implement this design, give me credit in the comments.
> :o)  Good luck.
>
> --
> Regards,
>
> John McGrath