I'm writing a Java app that needs to run on a device with a very high screen resolution. The only UI component that I need to display is a JFileChooser.
Since the screen resolution so high, the FileChooser appears too small. Is there a simple command I can use to make it bigger? Ideally, I'd like to keep the proportions of the components the same, so that the icons grow just as much as the text.
Also, it's important that any changes modify only my application. A global approach to changing the size of the graphics, like using a lower resolution, or changing a system-wide font size, isn't an option for me.
Any ideas?
This class works fine, both resizing JFileChooser window and fonts.
public class JFileChooserArqs {
private Font font = new Font("monospaced",Font.BOLD,16);
private String fileName;
public JFileChooserArqs(String title)
{
fileName = null;
JFileChooser fc = new JFileChooser(".");
fc.setPreferredSize(new Dimension(800,600));
fc.setDialogTitle(title);
setFileChooserFont(fc.getComponents());
int returnVal = fc.showOpenDialog(null);
if (returnVal == JFileChooser.APPROVE_OPTION) {
fileName = fc.getSelectedFile().getAbsolutePath();
}
}
private void setFileChooserFont(Component[] comp)
{
for(int x = 0; x < comp.length; x++)
{
if(comp[x] instanceof Container) setFileChooserFont(((Container)comp[x]).getComponents());
try{comp[x].setFont(font);}
catch(Exception e){}//do nothing
}
}
public String obtemNomeArquivo() {
return fileName;
}
}
I know the answer. Just use chooser.setPreferredSize(new Dimension(int width,int height)); method where chooser is your JFileChooser .
Example:
public class MyFrame extends JFrame(){
JFileChooser chooser = new JFileChooser();
chooser.setPreferredSize(new Dimension(800,600));
//Here show your dialog and do the rest
}
You need to choose suitable layouts to design the user interface. Have a look at CodeRanch thread.
I was going to suggest adding the JFileChooser to a container having a suitable layout, as #AVD suggests. For example, ImageDisplay adds the chooser to BorderLayout.WEST where it's free to grow vertically while adopting the UI delegate's preferred width. Before you abandon that approach, verify that you are not inadvertently defeating that design feature.
If you really need control over the display characteristics of the chooser's subcomponents, you may want to look at these variations of FileBrowser.
Related
I am using JFileChooser as a component for selecting files in this code.
I need one additional input from the user to trigger the way how the file shall be opened. In my use case if it shall be read to the RAM entirely or not.
I know I can ask user elsewhere but the best would be if I can add JCheckBox to the JFileChooser dialog. I want to achieve something as on the picture.
How I can do that and how I read the status of user input?
I figured out the simplest is to utilize the mechanism that is intended for image thumbnails of selected files. By providing so called Accessory Component, which must be a child class of JComponent, through calling JFileChooser.setAccessory you can obtain a space to the right of file selecting rectangle.
Including minimal example:
JFileChooser fc = new JFileChooser();
fc.setDialogTitle("Open DEN file...");
fc.setAccessory(new CheckBoxAccessory());
int returnVal = fc.showOpenDialog(frame);
CheckBoxAccessory cba = (CheckBoxAccessory)fc.getAccessory();
boolean useVirtualStack = cba.isBoxSelected();
JOptionPane.showMessageDialog(null, String.format("selected=%b", useVirtualStack));
where the class CheckBoxAccessory looks as follows
public class CheckBoxAccessory extends JComponent {
JCheckBox virtualCheckBox;
boolean checkBoxInit = false;
int preferredWidth = 150;
int preferredHeight = 100;//Mostly ignored as it is
int checkBoxPosX = 5;
int checkBoxPosY = 20;
int checkBoxWidth = preferredWidth;
int checkBoxHeight = 20;
public CheckBoxAccessory()
{
setPreferredSize(new Dimension(preferredWidth, preferredHeight));
virtualCheckBox = new JCheckBox("Virtual stack", checkBoxInit);
virtualCheckBox.setBounds(checkBoxPosX, checkBoxPosY, checkBoxWidth, checkBoxHeight);
this.add(virtualCheckBox);
}
public boolean isBoxSelected()
{
return virtualCheckBox.isSelected();
}
}
The result looks as follows
Disadvantage is that you will not get the whole component to play with but just a relatively small box. Thus the visual look is not what I initially wanted, but when you are no Picasso, you won't care. Advantage of this solution is that you can even react on change of selected file, which is in more details described in https://docs.oracle.com/javase/tutorial/uiswing/components/filechooser.html#accessory
When I do something like fileText.setText(path) in a JTextField, it works well unless the text is in Hebrew (or combines English and Hebrew). Then I get something like this:
I tried different fonts (even fonts that "Hebrew" is mentioned in them), but it didn't help. How do I fix it?
By the way, it is working properly with the ToolTipText (fileText.setToolTipText(path))
Here's my code:
// browse files or folders
public void browse(JTextField txtField) {
JFileChooser fileChooser = new JFileChooser();
fileChooser.setCurrentDirectory(new File(System.getProperty("user.home")));
fileChooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
int result = fileChooser.showOpenDialog(this);
if (result == JFileChooser.APPROVE_OPTION) {
File selectedDir = fileChooser.getSelectedFile();
String path = selectedDir.getAbsolutePath();
if (txtField == srcText) {
srcText.setText(path);
srcText.setToolTipText(path);
}
else {
if (txtField == dstText) {
dstText.setText(path);
dstText.setToolTipText(path);
}
}}
}
Not an answer, since your code works well as it is. Please try to your environment.
For me it works flawlessly out of the box with the default font on Windows 7. Java JDK1.8.0_31
public class JTextFieldExample extends JFrame {
private static final long serialVersionUID = 1L;
public JTextFieldExample() {
super("TextField Test Demo");
final Container container = getContentPane();
final JTextField textField=new JTextField("hello \u05DD\u05D5\u05DC\u05E9 Hello \u05DD\u05D5\u05DC\u05E9");
// optionally set RTL
textField.setComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
container.add(textField);
setSize(300,100);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setVisible(true);
}
public static void main(final String args[]) {
new JTextFieldExample();
}
}
Makes a window with a JTextField containing:
hello םולש Hello םולש
(I am sorry if I am using something strange or offensive in Hebrew. I just copied the unicode chars from another page, they claim it means "hello").
I've also tried you code in a test app and that is worked well, too.
Also Hebrew-only, English-Hebrew mixtures work well.
However you may prefer to set the RTL orientation to better match to Hebrew, and I guess in my example, the Hebrew letters are displayed in reverse order disregarding to the actual orientation.
Do the following:
check if the JTextField work well in Hebrew? If so, then there is something odd in the path returned by the file selector
check the path by priting it to the console. Locate chars which can cause problems, e.g. \-es, or broken unicode code points
dump the bytes of the string in hexa. This can reveal e.g. unicode byte ordering marks or broken unicode code points.
Given a list of true-color full frames in BufferedImage and a list of frame durations, how can I create an Image losslessly, that when put on a JLabel, will animate?
From what I can find, I could create an ImageWriter wrapping a ByteArrayOutputStream, write IIOImage frames to it, then Toolkit.getDefaultToolkit().createImage the stream into a ToolkitImage.
There are two problems with this attempt.
ImageWriter can only be instantiated with one of the known image encoders, and there is none for a lossless true-color animated image format (e.g. MNG),
It encodes (compresses) the image, then decompresses it again, becoming an unnecessary performance hazard.
[Edit]
Some more concise constraints and requirements. Please don't come up with anything that bends these rules.
What I don't want:
Making an animation thread and painting/updating each frame of the animation myself,
Using any kind of 3rd party library,
Borrowing any external process, for example a web browser,
Display it in some kind of video player object or 3D-accelerated scene (OpenGL/etc),
Work directly with classes from the sun.* packages
What I do want:
Frame size can be as large as monitor size. Please don't worry about performance. I'll worry about that. You'll just worry about correctness.
Frames all have the same size,
an Image subclass. I should be able to draw the image like g.drawImage(ani, 0, 0, this) and it would animate, or wrap it in an ImageIcon and display it on a JLabel/JButton/etc and it would animate,
Each frame can each have a different delay, from 10ms up to a second,
Animation can loop or can end, and this is defined once per animation (just like GIF),
I can use anything packaged with Oracle Java 8 (e.g. JavaFX),
Whatever happens, it should integrate with SWING
Optional:
Frames can have transparency. If needed, I can opaquify my images beforehand as the animation will be shown on a known background (single color) anyway.
I don't care if I have to subclass Image myself and add an animation thread in there that will cooperate with the ImageObserver, or write my own InputStreamImageSource, but I don't know how.
If I can somehow display a JavaFX scene with some HTML and CSS code that animates my images, then that's fine too. BUT as long as it's all encapsulated in a single SWING-compatible object that I can pass around.
You're right that ImageIO isn't an option, as the only animated format for which support is guaranteed is GIF.
You say you don't want to make an animation thread, but what about a JavaFX Animation object, like a Timeline?
public JComponent createAnimationComponent(List<BufferedImage> images,
List<Long> durations) {
Objects.requireNonNull(images, "Image list cannot be null");
Objects.requireNonNull(durations, "Duration list cannot be null");
if (new ArrayList<Object>(images).contains(null)) {
throw new IllegalArgumentException("Null image not permitted");
}
if (new ArrayList<Object>(durations).contains(null)) {
throw new IllegalArgumentException("Null duration not permitted");
}
int count = images.size();
if (count != durations.size()) {
throw new IllegalArgumentException(
"Lists must have the same number of elements");
}
ImageView view = new ImageView();
ObjectProperty<Image> imageProperty = view.imageProperty();
Rectangle imageSize = new Rectangle();
KeyFrame[] frames = new KeyFrame[count];
long time = 0;
for (int i = 0; i < count; i++) {
Duration duration = Duration.millis(time);
time += durations.get(i);
BufferedImage bufImg = images.get(i);
imageSize.add(bufImg.getWidth(), bufImg.getHeight());
Image image = SwingFXUtils.toFXImage(bufImg, null);
KeyValue imageValue = new KeyValue(imageProperty, image,
Interpolator.DISCRETE);
frames[i] = new KeyFrame(duration, imageValue);
}
Timeline timeline = new Timeline(frames);
timeline.setCycleCount(Animation.INDEFINITE);
timeline.play();
JFXPanel panel = new JFXPanel();
panel.setScene(new Scene(new Group(view)));
panel.setPreferredSize(imageSize.getSize());
return panel;
}
(I don't know why it's necessary to set the JFXPanel's preferred size explicitly, but it is. Probably a bug.)
Note that, like all JavaFX code, it has to be run in the JavaFX Application Thread. If you're using it from a Swing application, you can do something like this:
public JComponent createAnimationComponentFromAWTThread(
final List<BufferedImage> images,
final List<Long> durations)
throws InterruptedException {
final JComponent[] componentHolder = { null };
Platform.runLater(new Runnable() {
#Override
public void run() {
synchronized (componentHolder) {
componentHolder[0] =
createAnimationComponent(images, durations);
componentHolder.notifyAll();
}
}
});
synchronized (componentHolder) {
while (componentHolder[0] == null) {
componentHolder.wait();
}
return componentHolder[0];
}
}
But that's still not quite enough. You first have to initialize JavaFX by calling Application.launch, either with an explicit method call, or implicitly by specifying your Application subclass as the main class.
something like
public void paintComponent(Graphics g) {
super.paintComponent(g);
g.drawImage(getImageForCurrentTime(), 3, 4, this);
}
I have JLabel which I would like to change its size while I resize the window. When JLabel contains String which is too big, the String should be shortened, with right part visible and adds dots on the left hand side of the String.
My JLabel is inside innerPanel which is a header in middlePanel which is added to outerPanel. So when I resize window I use listener on outerPanel in that way:
outerPanel.addComponentListener(new ComponentListener() {
#Override
public void componentResized(ComponentEvent evt) {
int width = ((JPanel) evt.getSource()).getWidth();
windowSize = width;
refresh();
}
// [...] other not used override methods
});
refresh() repaints view and creates new middlePanel where is called class which creates innerPanel where is located my JLabel:
Public class InnerPanel extends JPanel {
private int maxSize;
String string = "<VERY_LONG_STRING>";
private static final int DEFAULT_INDEND_PIXEL = 70;
public InnerPanel(int windowSize) {
maxSize = windowSize - DEFAULT_INDENT_PIXEL;
createPanel();
}
private createPanel() {
// [...] gridbag and GridBagConstraints implementation
String shortString = countString();
JLabel label = new JLabel(shortString);
add(label,gc);
}
private String countString() {
int index = 0;
boolean toBig = true;
StringBuilder sb = new StringBuilder(string);
while(toBig) {
Rectangle2d rect = // [...] code which creates rectangle around text from sb.toString()
// I have no access to repo at home but if it's important I can paste it tomorrow
if(rect.getWidth() > maxSize)
sb.deleteCharAt(0);
else
toBig = false;
}
return sb.toString();
}
}
That's works fine in general, bacause it do resize JLabel in one step when I enlarge window in width. But the problem is appear when I try to reduce the window in width. In this case componentResized() calculate width step by step (and it's called multiple times), gradually decreases width by some amount of pixels till it reach real window size. It's behave in that way even thow I change window size in one step from maximum size to 800. Whole process is so slow, that it takes around a second to fit string to window size. So it looks bit like an animation.
The problem is very rare to me, bacause width in componentResized() method is calculeted step by step only when I assign windowSize variable.
When I give windowSize fixed size like for example 500 - componentResized() is called only onces - with correct width indicated real window size (!!) - and there's no its step by step decrease!
It's look like width variable which is assigned by ((JPanel) evt.getSource()).getWidth() knows that windowSize is used to dynamically change size of JLabel component even before first call of refresh() method.
If anyone have an idea what is going on here - I will be very appreciate for help.
You may be able to adapt one of the approaches shown here to better effect. As shown here, the ellipsis is supplied by the label's UI delegate via a call to SwingUtilities2.clipString(), which appends the clipString. Rather than re-invent the label UI, use TextLayout to determine the required geometry, prepend the ellipsis, and handle the alignment in a table or list renderer, as shown here.
Ive implemented the jFileChooser in my command line program and it works, just as it should with only one annoying issue. It seems that it opens underneath every window with no alert of any kind. In fact I even missed it a couple of times at first leading me to believe that i had implemented it wrong.
I have implemented this as follows:
System.out.println("Please select the file");
JFileChooser fc = new JFileChooser();
int retValue = fc.showOpenDialog(new JPanel());
if(retValue == JFileChooser.APPROVE_OPTION){
g.inputFile = fc.getSelectedFile();
}else {
System.out.println("Next time select a file.");
System.exit(1);
}
Essentially I only want the jFileChooser in order to have the user select a file as an input file. This is the only component that has a need for a GUI implementation, so if i can avoid writing up an GUI, that would be helpful.
So after trying a variety of things from different stack overflow topics I ended up with a result that consistently and reliably opens above every window on Windows 7.
public class ChooseFile {
private JFrame frame;
public ChooseFile() {
frame = new JFrame();
frame.setVisible(true);
BringToFront();
}
public File getFile() {
JFileChooser fc = new JFileChooser();
if(JFileChooser.APPROVE_OPTION == fc.showOpenDialog(null)){
frame.setVisible(false);
return fc.getSelectedFile();
}else {
System.out.println("Next time select a file.");
System.exit(1);
}
return null;
}
private void BringToFront() {
frame.setExtendedState(JFrame.ICONIFIED);
frame.setExtendedState(JFrame.NORMAL);
}
}
As it stands in my program it is an inner class and is invoked by calling:
System.out.println("Please select the file");
g.inputFile = g.new ChooseFile().getFile();
I think of two possible causes for something like this:
You're trying to mix AWT and Swing GUI's in the same program, or
You're trying to mix a console program (i.e., using System.out.println(...) and getting input via a Scanner object) with a Swing GUI.
If you are doing either of these two things, then you should simplify and make it only a Swing GUI type program. If this information doesn't help, then you may wish to give us more information about your problem.
Edit 1
I just noticed the details of your code. The new JPanel() part below is a problem:
int retValue = fc.showOpenDialog(new JPanel());
To make the JFileChooser act as a dialog to your top level window (which it is currently not doing and which is your chief problem), you should instead pass a component that is in the parent top level window, such as a JPanel or JButton that is held inside of your JFrame or JApplet.
Edit 2
OK, you're trying to mix a Java console program with a Swing GUI program which is like eating ice cream with pickles -- they just don't go well together. There is no top-level window to offer to the JFileChooser's showOpenDialog method so that it will act as a true dialog.
The best solution is to not do this, to instead re-write your application to be a complete Swing GUI.
In my code, I can just use null and it works. I'm using Java 7 on Windows 7.
JFileChooser chooser = new JFileChooser(System.getProperty("java.class.path"));
FileNameExtensionFilter filter = new FileNameExtensionFilter("CSV files", "csv");
chooser.setFileFilter(filter);
int returnVal = chooser.showOpenDialog(null);
if(returnVal == JFileChooser.APPROVE_OPTION) {
try {
Scanner inputFile= new Scanner(new File(chooser.getSelectedFile().getAbsolutePath()));
} catch (FileNotFoundException e) {
e.printStackTrace();
}
}