Skip to main content

Tables and Prototype values (do they work?)

5 replies [Last post]
swebb99
Offline
Joined: 2007-06-26

I have a table where I make use of prototype values but they don't seem to work as I would expect.

As far as I can tell the prototypes values are only used when initializeColumnWidths() is called on the table. This only seems to be called when the model is set or the table structure changes, also autoCreateColumnsFromModel must be set. So I fail to see how prototypes are ever actually used properly because you can't set the prototypes until the model is already set on the table ? So after setting the prototypes what then is supposed to make use of them to calculate the widths of the columns.

setModel() or tabledChanged() can be called again but if autoCreateColumnsFromModel is set the prototype values are lost because the column objects are recalculated, if it isn't set then the prototypes values aren't used anyway.

As initializeColumnWidths on JXTable is protected I can't call it direct. so I can't set the prototypes and then force a recalculation.

Am I missing something here ? Maybe I am missing the way prototypes and column ext should be used (a clip of my code is at the end of the message)

Also shouldn't packAll() use the prototype values if there isn't any data in the model ? At the moment it gets the header width, then only uses the cellrenderer if there is data, if there isn't any data it doesn't fall back to using prototypes data if set!

Also the prototype calculation make use of cellrenderers what about editors as well as these might be wider then the renderer !

Also an enhancement would be useful for setting the min and max size of the column based on prototype values!

Finally here is my code, with the work around at the end. Am I doing something wrong with my use of the prototypes. If so please let me know.

Thanks

Steve

activeTable.setModel(model);
activeTable.getColumnExt(ID_STR).setPrototypeValue("88888888");
activeTable.getColumnExt(INCIDENT_ID_STR).setPrototypeValue("88888888");
activeTable.getColumnExt(TYPE_STR).setPrototypeValue(AlertType.MEDIUM);
activeTable.getColumnExt(PRIORITY_STR).setPrototypeValue(AlertPriority.MEDIUM);
activeTable.getColumnExt(RAISED_TIME_STR).setPrototypeValue(Calendar.getInstance().getTime());
activeTable.getColumnExt(DEFERRED_TIME_STR).setPrototypeValue(Calendar.getInstance().getTime());
activeTable.getColumnExt(DEFERRED_TIME_STR).setVisible(false);
// now force a column width calculatiobn
for (TableColumn column : activeTable.getColumns(false)) {
((JXTable)activeTable).getColumnFactory().configureColumnWidths(activeTable, (TableColumnExt) column);
}

Oh its also worth mentioning that if there is a cell renderer on a column then the prototype values should be of a type that the renderer recognises otherwise it default to string which might not be what you wanted. This probably needs documenting a bit clearer.

Message was edited by: swebb99

Message was edited by: swebb99

Message was edited by: swebb99

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aephyr
Offline
Joined: 2009-11-20

> I have a table where I make use of prototype values
> but they don't seem to work as I would expect.
>
> As far as I can tell the prototypes values are only
> used when initializeColumnWidths() is called on the
> table. This only seems to be called when the model is
> set or the table structure changes, also
> autoCreateColumnsFromModel must be set. So I fail to
> see how prototypes are ever actually used properly
> because you can't set the prototypes until the model
> is already set on the table ? So after setting the
> prototypes what then is supposed to make use of them
> to calculate the widths of the columns.

Since you already have the TableColumnExt on hand which you are setting the prototype of, just following it with table.getColumnFactory().configureColumnWidths(JXTable, TableColumnExt) which is is where the workload of the beast from initializeColumnWidths() is performed and is public instead of protected as is initializeColumnWidths() to boot!

>
> Also shouldn't packAll() use the prototype values if
> there isn't any data in the model ? At the moment it
> gets the header width, then only uses the
> cellrenderer if there is data, if there isn't any
> data it doesn't fall back to using prototypes data if
> set!

There probably should be something like a revalidate() method. To me, "pack" implies taking into account only the data on hand. A user that initializes a pack knows nothing of your prototype value and would probably end up thinking the packing was broken if it didn't look like it was packing!

> Also the prototype calculation make use of
> cellrenderers what about editors as well as these
> might be wider then the renderer !

Sounds reasonable, I'm on board with that!

> Also an enhancement would be useful for setting the
> min and max size of the column based on prototype
> values!

Perhaps this more suited as a "do it yourself". Set your min/max prototypes, call the method I outlined above, set the min/max with the value of the preferred width it calculated, and then finally set your preferred width prototype, repeat said method call and then rinse!

Edit: the revalidate() could be unpack() and offered in the column control as well. Maybe the user doesn't like the result of the pack and wants a redo.

kleopatra
Offline
Joined: 2003-06-11

>
> To me, "pack" implies taking
> into account only the data on hand. A user that
> initializes a pack knows nothing of your prototype
> value and would probably end up thinking the packing
> was broken if it didn't look like it was packing!
>

good argument ...

> > Also the prototype calculation make use of
> > cellrenderers what about editors as well as these
> > might be wider then the renderer !
>
> Sounds reasonable, I'm on board with that!
>

... but applies to the editors as well, IMO: they are invisible most of the time and removed while doing the pack.

CU
Jeanette

aephyr
Offline
Joined: 2009-11-20

User knows nothing of the editors? Hmm... not this editor user.

Edit: To be fair, we are probably talking about different things here. There are two cases where the editor could be used in width calculations that isn't used currently: the initial preferred size calculation and the packing calculation. I was referring to the former as I was agreeing that editors should be accounted for with the prototype value while I disagreed earlier that prototypes should be used in the pack calculation. Whether editors should be used for the pack calculations with all of the current values in the column is a different topic. Usually the editors size isn't that much different from the renderers size so it wouldn't much of a change IMO.

kleopatra
Offline
Joined: 2003-06-11

the idea is to set all column properties - including prototype values - in the ColumnFactory. Obviously the default isn't overly rich, mainly because there is no general way of getting hold of custom settings (historically, way back in the mists of jdnc the prototype and other properties came from tableModel's meta-data and/or a corresponding resource file).

Feel free to subclass for your needs and contribute back :-)

As to whether or not a pack() should take a prototype into its eval is a good point to discuss. Personally, I always thought of it like being strictly init-only; could be swayed, though. As to potential type-mismatches of prototype vs actual data - that's up to application devs to take care of. As to consider editor's requirements as well - my first way out would be to set a longer prototype.

(sorry for being a bit short, I'm hungry )

CU
Jeanette

swebb99
Offline
Joined: 2007-06-26

Hi Sorry I haven't got back sooner, been very busy at work.
Anyway I'm a little confused by the responses at there seems to be a difference of opinions about the way this should all work. From my point of view I expected the following.
1) No prototypes - everything given the same width
2) No prototypes + packAll - everything given the space (if possible) to fit data
3) Prototypes defined + no data - columns are sized for prototype data including renderers and editors
4) Prototypes defined + data - columns are sized for data but prototype widths are used if greater than current data

I could only get 3 to work if my hack was applied (see original post). As for 4 it appears that packAll() always re-sizes to fit data and prototypes are ignored. It strikes me that a mechanism to define the min width (or max) based on the prototype and the ability to use these to override the calculated width when packAll is called would be much more useful to the bulk of users. Maybe a packAll() passing in some kind of arg would be the way to go!
PS: I should mention that users haven't really got an idea what pack means and we remove the widget from tables as it just confuses them. Basically it seems a very errrr developer (geeky, the text is developer friendly not user friendly) widget although useful in some cases. My point being that a developer call on pack rather than the widget call should perhaps be more flexible and follow rules for using the prototype values where appropriate.
Steve