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?
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
As I'm modifying an existing Look and Feel, I also want to change how the "buttons" of a PopUpMenu behave. Right now it behaves like this, when I hover my mouse over it. As you can see it behaves very "3D":
And I want to let it behave like the buttons I made below them:
I've looked trough alot of documentation of Java Swing but I can't seem to find it. So if someone knows, please help me out. I have tried to change every property I could find.
The correct answer here is, as I found out, not everything can be managed by the LaF. Therefore, sometimes you have to get your hands dirty.
In this case I created my own CSTMButton, because in Swing one is also able to add buttons to a menubar. Now I can create it's own listener to generate the behaviour I want.
I need to show something very similiar to source code, but it shouldn't be possible to modify it (but i still need funcionality as paint annotation etc.). The use case is more like - you click on some line and something will happen, some annotation will be shown etc.).
So i decided to try to use eclipse application platform, because its jface.text looks very good.
I am trying to use SourceViewer for my purposes. It could be configured to not be editable, but it is still drawing the caret if you click into it.
QUESTION: How to disable painting of the caret?
EDIT: If you know something better than SourceViewer, which could fit to what i need, tell me please.
SourceViewer sv = new SourceViewer(parent, new CompositeRuler(), 0);
sv.setEditable(false);
sv.configure(new SourceViewerConfiguration());
sv.addVerticalRulerColumn(new LineNumberRulerColumn());
sv.setDocument(new Document(""));
Looks like you should be able to set the caret to null with:
sv.getTextWidget().setCaret(null);
errorPopup= popFactory.getPopup(this, errorBox,
(verifierTopComponent.super.getX()+verifierTopComponent.super.getWidth()/2),
(verifierTopComponent.super.getY()+verifierTopComponent.super.getHeight()/2));
The code above works, and properly centers the popup... but only if the window is fullscreen, on my main monitor.
How do I make it more robust? I'd like to center it in the middle of the current RCP instance.
(verifierTopComponent is my incorrectly named TopComponent in the module).
After the comment below, I'm wondering if maybe y'all typically use a vastly different method to create a popup? I'm just trying to put something in the user's face to let them know why things won't work as they have done them.
When using the NetBeans RCP you should rather use DialogDisplayer and DialogDescriptor
Something like this:
DialogDescriptor dd = new DialogDescriptor(errorBox, "Error message");
Object result = DialogDisplayer.getDefault().notify(dd);
It will automatically take care of calculating the correct position.
I'm unsure how to solve your specific issue but in my experience you can/should use NetBeans' org.openide.NotifyDescriptor class to show notifications to the user. You will need to add a dependency for the Dialog API to your module to use the following.
NotifyDescriptor nd = new NotifyDescriptor(
"This is the message that will go in the main body of the message. This could also be a custom JPanel",
"Title of Dialog",
NotifyDescriptor.DEFAULT_OPTION,
NotifyDescriptor.ERROR_MESSAGE,
null, // this could be an array of JButtons that will replace the dialog's built-in buttons
NotifyDescriptor.OK_OPTION);
Object returnedValue = DialogDisplayer.getDefault().notify(nd);
if (returnedValue == NotifyDescriptor.OK_OPTION) {
// user pressed OK button
}
As always, see the javadoc for NotifyDescriptor for more info
Edit As described in another answer you could use the DialogDescriptor class which extends the NotifyDescriptor class and adds the ability to set the dialog to modal along with a couple of other useful features.
There are also a couple of other useful classes that extend the NotifyDescriptor class that may be useful for other situations. See the javadoc for NotifyDescriptor for a list of subclasses.
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()?