In a rich client CRUD framework I'm working on, I have a so-called edit panel, which as the name suggests, is involved in editing row objects via the usual swing input components.
Now, the panel has a default focus component field, which references the input field which should receive focus when the edit panel is initialized or cleared. The problem is the most logical name for the method which performs the focus request.
public boolean requestDefaultFocus()
return getDefaultFocusComponent().requestFocusInWindow();
}
The edit panel extends JPanel so this overrides the now deprecated JComponent method. The method name I'm currently using to avoid this is setDefaultFocus().That just doesn't sound quite right, although I will be able to live with it in case the answer to the question turns out to be a resounding no.
So, what are your thoughts on overriding a deprecated method like that?
I would not recommend it. There's no way to stop your code from issuing deprecation warnings. It makes it look like there's something wrong. And that takes developer time to verify that the warnings are spurious.
How about setInitialFocus()?
Related
I have a Swing custom control which serves an almost identical function to a JLabel. It's not accessible by default for people who use assistive technology, like a screen reader. I'm working on the Megamek GitHub Project, and trying to figure out how to associate the PMSimpleLabel class with other objects, as in the JLabel class's setLabelFor method.
The approach taken so far seems to be to more or less ape the JLabel's accessibility implementation. I'm not sure if this is the right way to go about it, there seem to be some elements in the latter I'm not understanding.
The problem turns out to be largely because of the custom components. The AccessibleJComponent class has a fallback mechanism to name controls which don't ohterwise have accessible names, but this is hard-coded to look for a JLabel and not a custom label class.
There are a few work-arounds for this, such as modifying the get/setAccessibleName methods, or switching to using the accessible description instead.
The solution in the long term is probably to use regular Swing components where possible
We want to be able to select the text on some labels.
At the moment, we're using a hack where we extend JEditorPane and then try to style it to look identical to a JLabel. This seems to work fine, but really it just lulls you into a false sense of security until a user using a screen reader asks you why you're inserting an editor which is never editable. Which, funnily enough, is exactly what has happened.
As it turns out, getAccessibleContext() for an editor pane returns the context for an editor pane, unsurprisingly. I know I can override that method and reimplement the entirety of JLabel.AccessibleJLabel myself, but there are a lot of things to implement, and I feel like there must be a better way.
Is there, in fact, a better way? e.g., it seems like I should be able to do it via the Look & Feel, but maybe there is an even easier trick.
I guess ideally, I would have hoped that there were just a property on JLabel to allow making the text selectable directly, allowing us to both keep the semantics/accessibility of adding a label to the view, while also allowing us to keep the usability.
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.
I need to change the behavior of every JButton in an application (it's a research project). We felt that the best way to change all of the buttons using an aspect since it would keep it clean--we wouldn't have to change all 262 instances to a new type. We have run into a snag. The aspect that we have written does not modify the buttons in a JOptionPane like it does for every other button in our project. Here is the advice that I have:
after() returning(JButton button): call(*.new(..)) || call(* newInstance(..)) {
init(button);
}
This matches every other constructor of JButton, but it seems to be missing the one used by JOptionPane. How can I access their creation? I'm still new at AOP, so maybe this isn't even possible to do.
I think AspectJ ignores the javax package by default. Since the option pane buttons are created in the look and feel code (see BasicOptionPaneUI.ButtonFactory in the javax.swing.plaf.basic package for example), that might be why it's being ignored. Maybe look at changing the configuration options to allow/include the javax package?
I have a form that tries to modify a JComponent's graphics context. I use, for example,
((Graphics2D) target.getGraphics()).setStroke(new BasicStroke(5));
Now, immediately after I set the value and close the form, the change is not visible. Am I not allowed to modify a JComponent's graphics context? How else would I modify the stroke, color and transformations?
Thanks,
Vlad
There are several problems with that approach. The first is that most components will set these things themselves when ever they are asked to repaint themselves. This means that your change will be lost every time the component gets to the point where it would actually use it. But, on an even more fundamental level than that, Graphics2D objects are not persistant. They are typically instantiated every time the component is redrawn, meaning that the Graphics2D object you got won't be the same the component will be using when redrawing.
What you need to do, to achieve this kind of thing is either to reimplement the specific component yourself, or implement a new look and feel that will affect the entire set of swing components. Have a look at the following link for further details about this:
http://today.java.net/pub/a/today/2006/09/12/how-to-write-custom-look-and-feel.html
Nobody to answer? I have let some time to see if there is any good answer before mine: I am not a specialist of such question...
First, I don't fully understand your question: you change a setting then close the form?
Anyway, I am not too sure, but somewhere in the process, the graphics context might be recomputed or taken from default. Perhaps if you do this operation in the paint() method, you can get some result, although I am not sure.
For a number of changes, you usually use a decorator. I explored a bit this topic when answering a question on SO: How do I add a separator to a JComboBox in Java?. I had to paint my own border there (asymmetrical), but often you just take an existing one, so it is quite simple.
I hope I provided some information, if it didn't helped, perhaps you should give more details on what you want to do (and perhaps a simple, minimal program illustrating your problem).
OK, I've worked around the problem like this: The custom JComponent now holds a Stroke object, which is set by the "Choose stroke" form when the user clicks OK. Then, in the paint method of the JComponent, I set the stroke of the graphics context passed as parameter to paint to the one contained in the object.
I have experimented and found out that, for some reason, JComponent.getGraphics().set* doesn't work.