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.
Related
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.
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
I am doing a simple GUI painting box program.
However, I have a problem with adding 2 similar separated groups to be corresponding in the same way.
I mean when I click the JRadioButtonMenuItem Line, then the JRadioButton Line below also has to be selected too. What should I do?
Do you need to see my code?, please let me know
Thank you so much.
P/s: it says I need 10 reputation to post image
Share the model between the two radio buttons:
JRadioButton radioButton = new JRadioButton("Line");
JRadioButtonMenuItem radioMenuItem = new JRadioButtonMenuItem("Line");
radioMenuItem.setModel( radioButton.getModel() );
Actually, you should share the Action as well between the two components. Read the section from the Swing tutorial on How to Use Actions for more information and examples.
The exact solution depends a lot on how your code is structured right now. I bet that the standard library has some functionality to accomplish what you want to do, but if you want to go ahead and implement it then you might as well (minimal time input and you learn something).
The most direct solution that comes to my mind is to encapsulate selecting a button in a method that will manipulate all sets of corresponding buttons. I am going to assume that you are using action listeners for the buttons right now, if not you could adapt the idea. In the action listener, you can detect the mouse click and perform some work as necessary. That work should include updating the other buttons appropriately too. You could even create a method that both action listeners call and updates all necessary sets of buttons.
It is also possible to use the same action listener on both sets of the buttons, but you'll need to know which selection the user wants to be active (likely an easy task).
My Java is pretty rusty, so I am not including any example code, but if anything is unclear or you think an example would help I can do so.
Hope at least something here helps you. Good luck!
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 have a created a UI in swing using NetBeans.
There are some use cases where the user presses buttons and a JDialog appears as a result.
The JDialog accepts input via JComboBox, at least 4.
E.g.
User presses "ButtonA" and a JDialog appears that displays the following:
"select X:" combo
"select Y:" combo
"select Z:" combo
"select O:" combo etc
I.e. beside each combo is a descriptive label. There are a few other controls in each JDialog besides each combo, i.e. JCheckbox, JTextarea
If user presses "ButtonB" a JDialog appears that displays the following:
"select A:" combo
"select B:" combo
"select C:" combo etc
So the dialogs are not the same but have some pattern in their presentation format. I.e. usage of comboboxes.
Initially I though to create a single JDialog and pass some arguments for the text it should display on the labels of the JDialogs and whether the JCheckbox should appear or not, if the JTextArea should appear or not and with what text etc, all depending on parameters passed in the initialization of the JDialog so as to have a single class for all use cases, but the code started getting really complicated and I rejected this approach.
What I did was create via GUI designer a JDialog, exactly as needed for each button press and came up with about 10-11 such JDialogs.
This appoach has made the programming much simpler but I do not know if it is a standard way to deal with this since I created 10-11 extra classes for the input.
My question is, whether what I did is reasonable, or there are better ways to deal with situation like this.
Thank you!
I think I would write a DialogBuilder class that returns a JDialog.
EDIT:
Visual vs Programatic creation of Dialogs
I'm used to generating Dialogs by writing code. before Java I used to code in Delphi in which Dialogs were created using a GUI - so initially I did find this annoying and even tedious. Nowadays I rather enjoy it. So yes, I would probably throw out (most of) the dialog code created by netbeans. Unless your dialogs are more complicated than your question suggests.
Complexity
Yes, there is a danger that you'll end up taking a lot of time to create quite complex code. However, if you are like me, you'll learn a lot doing it. One thing you'll learn is how to use various patterns to avoid that complexity. Finding an elegant way to solve those issues is something I find pretty satisfying - it's one of the aspects of programming I find most enjoyable.
Parameters
When you mention your concern about "if argA&& argB && !argC then display JCheckbox etc for 10-11 different jdialogs" - I can only suggest you try to approach the problem from a different direction. For example, you could pass the DialogBuilder a list of pairs of labels and JComboboxes. Or maybe you could extend JCombobox so that it has an additional field and a getter for it's label.
e.g.
DialogBuilder builder = new DialogFactory();
builder.add("Select X:", new Xcombo(...), true); // with checkbox
builder.add("Select Y:", new Ycombo(...), false); // without
...
builder.getDialog.setVisible(true);
or
builder.add("Select X:", new MyCombo(xList), false);
builder.add("Select Y:", new MyCombo(yList), false);
You can see (I hope) that the DialogBuilder.add(String, JComboBox, boolean) method wouldn't need dozens of complex if ... then ... else clauses.
Just my $0.02 worth.