I am currently working through the "Providing a Custom Renderer" example on this page. And now I wanted to create more than just one of these boxes. I did this by creating six renderer classes, one for each box.
And now for my question. Is it possible to just have one renderer class for all six boxes? For that purpose I tried to parse two variables to the constructor of the CustomBoxRenderer, like this.
public ComboBoxRenderer(ImageIcon[] currentImage, String[] currentString)
But due to how the programm seems to work, the currentImage array is null until a certain point, so I get a exception.
But let's assume this would work how I expected it to work, I still would have to create six seperate instances of the renderer for each box, which I'd like to avoid aswell.
I hope this is enough information, I could also provide my full code, but I think that'd be too much for this page here, if not, let me know.
If i'm reading correctly you could create a class that extends combobox and just adjust it so that it automatically uses your custom renderer, then all you have to is create a normal instance of your custom combobox and use it as normal except it will use your renderer without any hassle.
e.g. in your constructor you would just have this line
this.setRenderer(new ComboBoxRenderer(currentImage, currentString));
Im unsure why you think you would need to create six instances as the renderer deals with each box.
Hope this helps.
Related
I need to build a View which has a 4 layer nested Multi-Accordion with a lot of checkboxes inside them. All together there might be around 30-40 Checkboxes all through the Accordions.
The next step will be, that i have some sort of logic behind all this. Depending on the selection combination of the checkboxes I will change a text label accordingly.
My thought process was: I put up all these checkboxes and give them a numeric fx:id representing there position in the nested accordion graph. Something like "1_1" or "2_4_1".
After that, I build one ChangeListener calling a Method on Selection of a Checkbox. I can look up the Id of the checked box, look it up in my data (to see which Text belongs to it and if any rules interfer with other boxes) and handle the logic accordingly while putting the id and its text in a Map or List to keep it for later and to keep track of the checked boxes.
Now I came to know, that getting the fx:id isnt something JavaFX wants me to do. I cant deliver a custom id in custom property inside the FXML either (couldnt find anything regarding this).
I am now pretty much at the end of my knowledge (I did just start with JavaFX and have some basic Java knowledge) and it seems to me, that I tackle this topic from the wrong side.
My question is now: What would be a best practice to handle dozens of checkboxes and trigger logic in the code according to the box that was checked without writing a ChangeListener for every single Check Box leaving me with some (imo) ugly code all the way.
EDIT: I forgot to mention: I did achieve some sort of functional solution by writing a custom CheckboxChangeListener with a reference to the Element the addListener method was called on and using "getId()" on this reference. I came to know though, that this method references the css:id of the fxml element and not its fx:id and I am not quite sure if this is a proper way to go
You should look into databinding with javafx. For example:
CheckBox cb1 = new CheckBox("1");
CheckBox cb2 = new CheckBox("2");
BooleanProperty isCb1Selected = cb1.selectedProperty();
BooleanProperty isCb2Selected = cb2.selectedProperty();
Textfield foo = new TextField().visibleProperty().bind(isCb1Selected.and(isCb2Selected));
This would hide the textfield foo if atleast one of the checkboxes isn't selected.
You can find other examples here and here an oracle tutorial
Can a Java Swing JPanel hold a String value than can be modified/accessed where I can save some information?
I see no other option but to implement my own class holding a JPanel and a String... was just trying to save some space/coding..
I like the setName/getName of the Component super class... is there any inconvenience in using that ??
Yes it can. Any Swing component can hold client properties for the specific component.
See the putClientProperty(...) and getClientProperty(...) methods of JComponent. Using this approach you can define any number of client properties:
panel.putClientProperty("Title", "Panel1");
panel.putClientProperty("Description", "some text for the description");
You can also use the setName(..) and getName() methods if you just want to uniquely identify the panel with a string name. Many IDE's will use this property.
Of course if you are creating a panel with multiple Swing components and related instance variables then you would probably extend JPanel and customize its behaviour.
I like the setName/getName of the Component super class... is there any inconvenience in using that ??
If you feel the "name" property adequately describies the data you want to store then this is the most efficient way to store the data. However, if the data is not really the name of the component then don't force the data just because it is easy to use. Also it is possible some IDE's may use this property for generic debugging or messaging. That it may check display this value in an error message to help identify a specific component.
Several solutions, and it's hard to know what you're looking for here. You could create a MyJPanel class that extends JPanel and is identical except including a String field with getter/setter. You could also store information in silly ways like by setting/getting the name of the JPanel. (That is use setName and getName of the Component superclass.) Another solution is to add a JLabel or some other component with that information to the JPanel, and if necessary, making it invisible or hidden.
No, I think it cannot hold a String value.
You can see all getters/setters here:
http://docs.oracle.com/javase/7/docs/api/javax/swing/JPanel.html
Also, you can check the source code (if you want to go that far).
There's no getter/setter useful for holding a String value
(I mean ... e.g. no setText or setTitle).
Of course, you can add e.g. an invisible JTextField to your JPanel and
set the String into the JTextField. But that doesn't seem very nice to me.
JPanels hold JComponents, i.e. JButtons, JLabels, etc. A String is not a component. It would be best if you'd just use a JLabel with a String as its parameter, then add that to a JPanel.
You can add a Component like JLabel/JTextField and use setVisible(false). That object can hold strings.
note: Only for Buttons.
You could use setAtionCommand() but it is indented for something very specific. It would be horrible practice for anything else.
As a way of learning Java, I'm writing this little application for grade schoolers to practice basic math. The idea is that the kid does any number of math problems, as long as they are in the app, it just continues to throw problems at them until they click a 'Done' button. When they decide to be done, I want a new JFrame to come up that will show them all of the problems they attempted, along with their answer, and whether they got the problem right or wrong.
The advice that I am looking for is what is the best way for me present these results. I looked into the GridLayout and the GroupLayout, but I don't think that these are exactly right. I did something similar in VBA for Excel, and there I just ran a for loop with one iteration for every problem they attempted. Each iteration would add a row of labels to the frame with the elements of the problem displayed in the various labels. I tried this in Java, but I'm not even able to get the labels to even display.
So before I get all specific and start posting my code, I want to ask a bigger question, which is "what is the best method to create a view like this?" Often, I go off in one direction only to waste time before somebody suggests a totally different (and better) approach.
Thanks!
(edit: here's an image of how I did this in Excel. I'm trying to repeat basically the same thing in Java)
One simple way to make that design would be to use a mix of components. You could have a bunch of JLabels and JPanels stacked in a vertical FlowLayout. The grid you have described would be best designed in a JTable, something like the below:
If you like tables like Excel then, Java provides JTable class to create tables, if you want.
Tutorial : http://docs.oracle.com/javase/tutorial/uiswing/components/table.html
I have a fairly complicated JTable subclass (WidgetTable and its WidgetTableModel) that works fine when I add it to a dummy JPanel for testing purposes.
Since I am absolutely horrid at working with LayoutManagers, I like to use the NetBeans built-in GUI Builder for all my layout work. Then I usually just code-around the autogenerated (GUI builder) code and that has always worked for me. It is the best of both worlds: I get my presentation looking exactly the way I want it, and I also get fine-grained control over the componentry.
However, I have never used the GUI Builder tool to make tables. After tinkering around with it for a while last night, it looks as though it is only good for making pretty basic (fixed # of rows, fixed # of columns, etc.) JTables.
My WidgetTable actually has a dynamic number of both rows and columns, special editors/renderers and many other bells and whistles.
My problem:
I have two conflicting constraints: (1) I need to use the GUI builder to position and size the table exactly where I want it in the container, but, (2) The table component available through the GUI builder is too basic to handle my WidgetTable.
I need a way to design a "table placeholder" into my container with the GUI builder, such that, once NetBeans autogenerates that placeholder code, I tweak the code and instruct it to dynamically instantiate one of my WidgetTables instead, consuming the location and size that I defined the placeholder component to take up.
This way I can have my cake, and eat it too. The only problem is, I don't think the GUI builder supports this ability to drag-n-drop abstract JComponents, position and size them, and then plug subclasses into them elsewhere in the codebase.
Anybody ever have this problem before or have any interesting recommendations? I imagine the best thing to do would be for me to just roll up my sleeves and learn LayoutManagers, but I'm mostly a server-side developer and only come over to the client-side every once in a blue moon; and honestly, don't have the energy to learn the intricacies and nastiness of GroupLayout and its sinister cousins.
Thanks for any help!
Insert a JTable using the GUI builder, reset its model property to the default value, and tweak the construction code so that it looks like
jTable1 = new WidgetTable(this.widgetTableModel);
You may tweak the creation code by right-clicking on the JTable, selecting "Customize code", choosing "custom creation" instead of "default code" in the first combo box, and typing the code for the constructor call.
If you need your jTable1 variable to be of type WidgetTable rather than JTable, edit the "Variable declaration code" in the same dialog box.
NetBeans also allows you to create custom components for building UIs. This may be more work than you want to put into your WidgetTable, but if you think you're going to have to build more UIs with custom components, it could be worth learning.
I do this all the time. I have an subclassed JTable that I use with the GUI editor and it is Dynamic.
Add a JTable to your project using the GUI editor and the layout of your choice.
Once the table is added, right click on it and click on custom code.
In the constructor of the JTable, change it to say new WidgetTable(new WidgetModel()) instead of new JTable(new DefaultTableModel()).
Create a global variable for you WidgetTable. Something like private WidgetTable widgetTable;
In you constructor, after the call to initComponents(), cast your JTable to a Widget table and use that from now on.
`widgetTable = (WidgetTable)jTable1;
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?