There are many answers to how to set the font (use renderer), but I want to get this font. The reason why is for unit-testing: test for the renderer doing its job OK.
The human eye can see whether a component for a given cell is rendered with a red foreground, but how can we do this programmatically?
later Just a word about my comment "get hold of the screen real estate". That's not quite it: each one of these table cells contains something... but what? And is it possible to reference it? It almost seems that each one is the "ghost" of the component (the same one) used successively to render each individual cell. Obviously I don't really know about the "architecture" of the representation of a JTable. Would be interesting to find out... although I suspect strongly that these "ghosts" (or whatever) are inaccessible.
Use the JTable.prepareRenderer(...) method.
This method will return the Component that will be used to do the rendering of the cell. So you can then invoke the getForeground() method on the Component.
Related
here are the screenshots of the application
Rows will be displayed in the Table according to the text which is written in the search textfield.
Now i want to mark that particular text as per the shown in the second image with the yellow color
I know how to select a row or a particular cell.
but I don't know how to select a particular text inside the cell of any row in the table.
I am guessing you know how to search in JTable, so I am not pasting code of it here.
You can look over the SwingX library. It has this kind of function as you said predefined it it. You just need to add it to your table. This is where you can find it. Give it a try you will surely like it.
The basic premise would be to use a custom TableCellRenderer that provided the functionality that you require.
The problem is how to implement it.
I would create a TableCellRenderer based on a JTextField, remove it's border and make it transparent. This will allow you to use the text highlighting functionality provided by JTextCompoent to highlight portions of the text, as demonstrated here.
The next problem is then knowing what to highlight. There are a number of possibilities.
You could provide a method in your table model that could return the current text that should be highlighted.
I'd, personally, probably use the JTable#putClientProperty and JTable#getClientProperty methods to seed the search text.
Or, you could actually provide a simple model that directly to the renderer which had a method that returned the current search text. This might actually be more useful as you could link it to field, the method building the filter and the renderers and allow them to simply seed each other
I have a list of entities where each entity render into widget based on JPanel. Widgets have dynamic behaviour - once placed on panel it can be changed by underlying entity. This happens automaticaly. Moreover some widgets can be resized by different actions, on button click for example.
The question is how to organise them into something like JList but without rubber stamp technics. In other words I wanna JList where each item rendered with cellrenderer stay "alive".
Right now I have implemented quick-and-dirty component based on JPanel with vertical BoxLayout, it uses JList's renderer component and it's model... but my implementation is too dirty...
Um.. yeah, using JTable is not suitable too.
Do you have some ideas?
If you don't want rubber stamping to take place then you'll have to create your own JList implementation that uses actual components.
You could try and work around the rubber stamping effect by caching each component for each row in your renderer and bind values into it and return that instance when JList asks the renderer for it. This is pretty risky because if you have 20 rows being displayed you'll have to cache 20 instances in your renderer, and only when the row isn't visible can you reuse one. That would mean if you had 5 unique configurations (A,B,C,D,E) of components you might have 10 of type A, 5 of type B, 2 of type C, and 3 of type D, and 0 of type E being displayed. However, you can't simply reuse one of those components without knowing if its being displayed or not. So you'd have to take into account if the row is being displayed and if it's the right type for the row you are rendering. And you'll have to clean up after the row is hidden.
Another option is make a single component for the row that encapsulates all X variations you have and put those on a CardLayout. Then you can simply cache one per row being displayed, and simply swap the card being displayed upon rendering that row. I think that might be the simplest option for you.
The harder part is going to be routing events click mouse clicks, keyboard events, etc to those active components to have them respond like normal components. Re-rendering the buttons when the user clicks them, and so forth is going to be challenging. Not impossible, but tedious.
Finally, variable row height JList is a pain. Especially in your calculations to figure out if a row is displayed or not because you can't simply do easy math like: int rowHeight = jlist.getHeight / model.size(). It doesn't work. You have to calculate each row's height and them up to figure out if a row is visible or not.
Doing what you're talking about is a lot of work, and very tricky coding to work around some of the assumptions of JList to make it work. In the end you might find it easier just to implement your own List control that makes different design decisions. Either way its going to require you are good at Swing to get it to work.
Ok. I don't find any implementation of such component. Let it be first one.
https://github.com/wertlex/JActiveList
P.S. I don't think this is proper way implementation... but it works.
use JList and ActionListener XD
I have a problem with rendering nodes in JTree. When node's font is changed and node's text gets wider that way then node's text is cut and end of text replaced with dots.
How to tell the JTree then that it should widen area to render tho whole node.
Thank you for help
You can use custom renderer and set to the component (JLabel) something like this
final Dimension size = label.getPreferredSize();
label.setMinimumSize(size);
label.setPreferredSize(size);
or just set text like this
setText("<html>" +valueText+"</html>")
Sounds like the trigger of the font change happens under the feet of the tree: internally, the ui delegate does lots of size caching which must be updated on any change which effects the cached sizes. That's done automatically on changes to the treeModel, to relevant expansion state and some visual changes to the tree itself.
So the basic question is: what triggers the change of the font? If it's some change of the model/nodes, the model implementation is incorrect in not firing an appropriate TreeModelEvent, the obvious solution would be to fix that :-) If it's something outside the model, the solution depends on the details of your context, nothing generally applicable.
Size caching
The JTree uses a renderer to render nodes. The renderer is the same renderer for all OSs, so the differnt lookings are inside ComponentUIs. JTree uses by default a JLabel to paint nodes, so its the JLabel's size wo guides us to cut the text using ....
Lets make a short excourse: Swing has differen LookAndFeels for different Operation Systems, they are detached from the components in UI-Classes like the BasicLabelUI (and this is the source of your problem). BasicLabelUI caches the size of the label to prevent recalculation if no changes has made. So BasicLabelUI did not clear the cache of theese old size values. BasicLabelUI do clear the cache if he gets informed about any changes.
The question is, why does the BasicLabelUI did not get informed about changes? Well, if you modify/expand/rename the Tree programatically you must tell the ComponentUI to drop that cache!
You lucky, you do not need to write much code because a genius already wrote something for you, the creators of the TreeUI-class Rob Davis and Scott Violet wrote startEditingAtPath and stopEditing.
Example
TreeUI ui = tree.getUI();
for (TreePath treePath : selectionPaths) {
ui.startEditingAtPath(tree, treePath);
}
tree.setSelectionPaths(selectionPaths);
tree.expandPath(expandPaths.getSelectionPath());
ui.stopEditing(layer);
Call your TreeModel's reload()
I'm writing a custom swing component (something completely new, but think JTree or JList). I'm trying to follow the general design of JTree, JTable, JList etc for consistency (I've also seen various poor 3rd party components abandon the separable model and/or renderer approach).
So, I have a model full of nodes, the component itself and a renderer. At some point the node has to be turned into text and displayed by a renderer. I'm not clear on the best way to do this:
Pass the node itself (as Object) to the renderer, and let the renderer decide how to display it.
This is how JList does it.
Requires a customised renderer just to change the text.
Allows great flexibility in how to display the node (doesn't even have to be text).
Pass the node itself (as Object) to the renderer, but have a convertValueToText() method in the component class.
This is how JTree does it.
Renderers can be just as flexibile as before - don't have to use this method.
Have to override component to change the text transformation.
As above, but delegate convertValueTotext() to the model.
This is how JXTable does it.
The model is probably the best place for this method - and it's easier to override there.
I don't want to have to customise the renderer just to change the text, but I'd like to be able to customise the renderer to do more than display a model-displayed string (else why bother with renderers). I really don't like the fact that JXTable uses reflection to look for convertValueToText() in the model - this smells of bad magic to me.
Can anyone shed any light on this oft-neglected part of Swing?
SOLUTION
What I ended up doing was this:
Add a method to the model which returns a string for the given node. Importantly, this can be null to indicate that the renderer should know what to do or that we simply can't provide anything useful.
The component has the same method, and passes the call on to the model. This is important for view-model separation. The renderer calls this method, so it doesn't talk to the model directly.
The default renderer calls the above method and if it's not null, it uses it, otherwise it can call toString on the value, or provide a default, or whatever.
This leaves developers a choice when they want to override the displayed value
- Override the method with a non-null return value knowing that the default renderer will display this text.
- Provide a custom renderer which is passed the actual node object so it can do "clever" things if it needs to.
I'm quite happy with it - it "feels" right, it works, and it's easy to use.
Thanks for your perspectives!
Good question. This is not specific to Swing, but a philosophical question about the difference between a model and a view.
In general, is converting objects into text the job of the model or the view? My purist head says that actually you want a hierarchy of views - one to convert object model to text, and one to display the text. You might even want more than two - for instance, object-to-text, text-to-document-structure, document-structure-to-HTML, and then CSS to present to the user.
However, pragmatism says this may get too hard to remember and maintain. So in your circumstance I would suggest: think about how likely it is you'll ever want to extract non-text data from the model. If it is not very likely, then put the equivalent of convertValueToText in the model.
Otherwise, allow the component to either use a renderer, if it is given one, or else take the object value and convert it to text internally.
This allows maximum flexibility and probably makes things feel most natural to the users of the API. I believe this is the JTable model though I haven't used Swing for a long time.
AFAIK neither JList nor JTree require the renderer to render text. The renderer gets passed the data object and return a JComponent which gets positioned as a child in Tree/List itself and then rendered.
I would go with this. A renderer for text would simply return a JLabel. If you want to be able to change the way, the text is constructed pass a Formatter to the TextRender, and you are done.
Stephan
If you had to write your own component do it as simple as possible. In a lot of cases if you need a custom renderer then you don't care about interpretation by component or model. Model holds your data. And in this case is also custom written. From my point of view the good choice is based on first option. Provide DefaultRenderer which implements AbstractRenderer and add there all methods like toText(Object o) and so on. Then allow me to decide whether I want to use default functionality or I prefer to wrote my own. Do you really need custom component? To make it works correctly it is a LOT of work. Is this component worth all this?
I'm working on cusomizing a Swing application by dynamically altering the UIDefaults. The end goal is to alter many of them (colors, fonts, sizes, borders, etc) and save the result on a per user basis. While it may give the application some non-standard looks, the client asketh and the client shall receive.
The only problem I'm running into is that GUI will only update ONCE. The first time I change a ui property everthing is great, subsequent changes don't affect anything.
// called from the EDT
// uiKeyName points to some ColorUIResource
UIManager.getDefaults().put(uiKeyName, <<color from color picker>>);
SwingUtilties.updateComponentTreeUI(rootWindow);
It works once, but never again. Ideas?
When you put the new color (for example) in the table, is it a Color object, or a ColorUIResource? As I understand it, the new value will only be taken up if the current value is null or an instance of UIResource. Thus, if you insert a plain old Color object, any subsequent changes you make will be ignored.
Also, as the linked doc page suggests, this may only help with the font and foreground/background colors; when it comes to changing things like borders and margins, you may be out of luck. This is not what Swing's Pluggable LookAndFeels were designed for. Maybe you could interest the client in a Synth-based LAF?