I’ve been working on modifying the examples to build a table node which consists of a record node populated with modified MultiTextNode, called MultiColumnRow that builds cells horizontally rather than vertically effectively creating a table row. I’m currently working out the details of lining up column rows and handling various events.
However, I was wondering if JGo supports the use of JTables and other swing elements. Swing elements are obviously a lot heavier than JGo elements but it would be nice if I could just take a swing element, attach some ports to it and have a swing object. Is this possible, and are they’re any other solutions in the works for more complex elements like tables? Thanks.
Yes, you can subclass JGoControl to override createComponent to add a TableModel property and to create a JTable from that model.
Actually you’ll probably need to subclass JTable, to implement initialization and focus and autoscrolling and any listeners you might need.
Caveat: JComponents represented by JGoControls are always “in front” of everything else displayed by the JGoView. Also, printing and scaling can be a problem, since Swing components don’t really handle those things well.
I see. So, just to clarify, will Swing components show in front of layers that are above the layer it is in (given that the above layer is not transparent) or is it that it only shows in front of other objects that are in the same layer?
Each JComponent does its own drawing, so its drawing cannot be synchronized with the drawing that the JGoView does.
So you can pretend that all JGoControls live in a special layer that appears in front of all JGoDocument layers and JGoView objects.
What happens if 2 JComponents are overlaid one on top of the
other. How is that presented? Say I have a panel that
extends from a jGoControl. It does nothing but act as a container
and hold another JComponent. How is that handled?
All JComponents created by JGoControl just become child components of the respective JGoView–that is, it calls Component.add(Component). So what happens is what happens with any set of JComponents added to a JComponent.
Remember that a JGoControl can be a document object, which means it may be visible in multiple JGoViews simultaneously. This means that there could be multiple JComponents for each JGoControl, one per JGoView. But your override of JGoControl.createComponent can decide to return null instead of actually creating a JComponent. That’s commonly done for JGoOverviews, for example. Sometimes you want there just to be a single JComponent for the JGoControl, so you don’t have to worry about synchronizing the multiple JComponents.