Sorry for the odd choice of words for the title, however, "border" seems to be the inappropriate term. While it is true that the visible line surrounding an icon in a JToggleButton can be made invisible by using setBorderPainted(false), the same is not true for JCheckBox and JRadioButton.
I can not use the JToggleButton and therefore need to use either the JCheckBox or JRadioButton (or some derivative of JToggleButton I am not aware of), but need the square or circle, respectively, to be non-visible when there is no icon on the button. Also, using setVisible(false) eliminates the button from the layout, however, I need the space to be reserved and not have the component layout change (using GroupLayout).
Any suggestions? Am I going to have to create a custom renderer? I will be looking at that in the mean time.
The route into this would be through customising the look at feel by changing some of the UI properties in the UImanager (the sort of thing that allows you to make simple tweaks with fonts and colours and presumably the images used for the checkboxes or radiobuttons) -- but it's many years since I last did that sort of thing and can't remember the details.
A little Googling turned up this project to inspect current property values, so might at least help with indicating the right part of the APIs to be looking at.
You have to choices here:
1) Customize Look and Feel as described in previous entry.
2) Create your own custom controls by inheriting from existing ones and overriding component painting.
I found a cheap and easy (read hack) for this. I created an empty transparent icon and used it when I didn't want any item to be displayed.
Related
I'm working on my custom ColorChooserPanel class, but I don't know how to create a ColorSwatch.
I found a class named ColorSwatch or something like that but its package private and I can't access it.
How can I ensure that I have a proper color chooser?
First, you need to think about the way this should work, to formulate your goals into action points that you can always check and see whether and how they are fulfilled:
it should be displayed
it should handle click events
it should be able to return a color (the last chosen color, or a default in lack of that)
Now, a very common way of supporting color choosers is to have something like in this image:
However, this is way too complex for a first implementation. You should first have something which "works", that is, you are able to choose colors to taste success and then work out the subsequent details. Unless you say otherwise, I'm assuming that the Basic colors section is good for now. In that case, you can create a class, which contains a JPanel, containing clickable elements. Your class needs to have a Color member, which one can get calling a getter and which is set when a clickable item inside your JPanel is clicked. The clickable items can be JPanels on their own, for example.
If you prefer something ready-made, then kindly read these:
https://docs.oracle.com/javase/tutorial/uiswing/components/colorchooser.html
https://coderanch.com/t/332515/java/Color-Palette
When specific action is performed, I want to replace button with text field. I know that I have to call button1.setVisible(false); but I don't know how to create text field on the exact same place. I am using NetBeans designer, if you can give me a hint, how to add 2 components at same place, and switch between then, something like switching between layers in photoshop, if something like that is possible, would be great. Thanks
For many components in one space, use a CardLayout as see in this short example.
I have designed an html document editor and I wanted some help in resolving a design problem in it. The problem is as follows -
The document editor consists of a surface (JFrame) and a menu bar. Inside the surface I have three panels - a tool panel, text panel and status panel (which are all extensions of JPanel). The text panel has the customized text pane (extension of JTextPane). Now the problem is that - there are lots of scenarios where the menus and the widgets items on the tool panel need access to the underlying document model of the JTextPane. E.g. to implement list/paragraph dragging functionality, the ruler needs to know the position of the caret inside the document model, so that I can mark the paragraph whose left inset I need to increase.
The way I have organized my design right now is that - surface is a singleton, so to access the html document model inside the JTextPane you need to code your way through the following maze -
Give me surface -> go to text panel -> go to text pane -> go to document of the text pane
Another alternative to make the reference of the document inside the text pane static, so that it can be accessed directly.
TextPane.getTextDocument ()
Also the html document inside the Text Pane I am using is not customized right now. So I am just using the default HTMLDocument returned by the text pane. Though in future I may have to replace it with a more customized extension of HTMLDocument (e.g. to implement cusom tags)
I am somewhat of a design novice. Can some design guru throw some light/insight into this?
I think if you get 10 responses you'll get 11 answers. :-)
First, there is no need for a Singleton. In this scenario, it's just a way of cheating with a global variable. And what happens when you want to have two or three text documents open?
Do your menus have ready access to the tool panel? Since toolpanel is a sibling of the textpanel, and in a 1-1 relationship (I think?) it is somewhat "reasonable" for toolpanel to know about textdocument (have a link it) and a convenience method, getTextDocument(). And it seems reasonable for your widgets to know about their immediate parent, the tool panel.
That would be my way of approaching the problem - what links between objects "make sense". You want as little coupling as possible, but there are places where you do need coupling. Maybe I have misunderstood your problem, or maybe you think a lot differently than me, in which case you should do it another way. Also, you are making a best guess as to how your code might evolve in the future. Good luck with that! :-)
One big question for any solution - does the text document change? (e.g., is there a File->New menu or a File->Open menu?). If so, that needs to be considered. In my proposal, the JFrame, on a File->Open, would create the text document and then change the link to it in the ToolBar.
p.s. MVC purists - please add appropriate models and controllers! I just talked about the graphical components to keep things simpler...
p.p.s. Examples of "thinking ahead" for reasonable enhancements
Would this handle multiple JFrames open at once? Yes.
Would this handle a single JFrame, but with multiple documents (say, a tabbed interface for the text document)? Almost. The method has to be a little smarter to know which of the many documents is active, but you can easily imagine doing that.
How about when I need to hold a lot more info about the dicument, like the name (so Save gives a good default), last time saved, is it "dirty", is it HTML or XHTML or whatever... At this point, you'll probably want to add one more model layer. But you can sortof imagine, with one more layer of indirection (one more link) this being o.k. So it depends on how close you are to implementing #3 how you want to design.
I'm using a JInternalFrame and I want to remove the dropdown in the upper left of the frame, as it serves no purpose (I've disabled resizeable, closable, etc.)
I don't see a property for this, and I don't want to remove the entire title bar, as the title is necessary. I've looked around online, and basically come up empty here. I'm hoping it's something simple that I've just overlooked, as this is my first time using JInternalFrame, and I'm not exactly a GUI kind of guy to begin with.
internalframe.setFrameIcon(null);
Edit: hack to remove system menu in Windows:
BasicInternalFrameUI ui = (BasicInternalFrameUI)internalFrame.getUI();
Container north = (Container)ui.getNorthPane();
north.remove(0);
north.validate();
north.repaint();
The relevant Icon in The Synth Look and Feel, among the Nimbus Defaults, appears to have this key:
InternalFrame:InternalFrameTitlePane:"InternalFrameTitlePane.menuButton".icon
You may be able to use the approach shown in A Synth Example to replace the Icon.
setFrameIcon(anyBigImageThatCantBeDisplayed);
I´ve tried null parameter and got some visual issues...
So i added a big image(no background) that was already on my resource folder and the icon was no longer displayed as the menu...
Here's a very specific coding question:
I've recently been asked to maintain some old-ish Java Swing GUI code at work and ran into this problem:
I've attached my own subclass of InputVerifier called MyFilenameVerifier to a JTextField (but it may as well be any JComponent for these purposes). I've overridden the verify() method such that it calls super.verify(input) (where input is the JComponent parameter to verify()). If super.verify(input) comes back false, I do:
input.setBorder(BorderFactory.createLineBorder(Color.RED));
This is a convention used throughout the UI of this application that started long before me, so I don't have a lot of choice as far as using other ways to get the users attention (wish I did). This is just the way it works.
Problem is, once the user goes back and types something valid into the text field, I need a way to set it back to default border (instead of just saying set it to Color.GRAY or whatever, which is a different color from its original border). I need a way to say, "remove the extra decoration and go back to normal" or just set the border to its default, in other words.
Couldn't you just call input.getBorder() and cache it somewhere before setting the border to red?
Or without caching anything, you could tell the JComponent to update its UI back to the look and feel's defaults via component.updateUI. That should make the component reset its colors, borders, fonts, etc to match the original settings.
input.getBorder()
Wouldn't it be awesome if no one ever saw this and I got away free without the ass-beating I deserve for asking this question?
Not sure how your system is build, but I think you can store the original border before changing it. So you can change it back later
// assuming the Border was not null before
if (!super.verify(input)) {
original = input.getBorder();
input.setBorder(...);
} else {
if (original != null) {
input.setBorder(original);
original = null; // not needed
}
}
You need to preserve the existing border when you change it.
One way to do this is to use the methods putClientProperty() and getClientProperty(), which you'll find documented in the API.
Another possibility, if there are only a few input widgets you need this for is to subclass, e.g. JTextField, add setBorderOverride() and modify getBorder() to return "overriddingBorder" if it is not null.
Then you just use setBorderOverride(redBorder) to make it red and setBorderOverride(null) to clear it.
This of course depends on the painting to use getBorder(), which it may or may not do, and which may be implementation specific.
Incidentally, you only need a single static reference to the border-- it's the selfsame border instance used by all JTextFields.