They say a single image is worth 1000 words:
I'll just note that the size is set to default. (build in NetBeans)
any idea how do I fix this?
Adam.
Without you showing code, I'd say that your JTextField width is not set to be wide enough. You can resize it to be large enough for the number of characters you anticipate.
However, this does not guarantee that the user will not type in more characters, which would show the text cutoff as well.
You can extend the Document that JTextField uses to add the maximum character restriction, as shown at
http://www.rgagnon.com/javadetails/java-0198.html
what are the lengths of your data,it seems you changed the layout and that's causing that problem as the border seems also occupying half of the character.
They say a single image is worth 1000
words:
Actually its not. When posting a question a SSCCE is worth 1000 words.
Stuff like that usually happens when you don't use a layout manager. Assuming (which is all we can do since you didn't post any code) that you are using a proper layout manager then your basic code for creating a text field to display 3 characters is:
JTextField width = new JTextField(3);
The reason is the LNF that was assigned to the frame, once I've changed that, it all works fine.
Related
If I make button relatively small, it's caption turns to ellipsis.
How to turn off this feature?
Don't let the button go below it's preferred size, then it will never need to elide the text of the button label:
button.setMinSize(Button.USE_PREF_SIZE, Button.USE_PREF_SIZE);
I want to make very small button
You can use any of the below either separately or in combination:
Apply CSS to use a very small font in the button.
Make the label text for the button very short.
Use brian's answer which proposes explicitly setting the ellipse string to empty.
Use a small graphic icon instead of text.
You can use setMinSize as documented above in all cases (if you wish the button not to go below a preferred size truncating or eliding content).
In all cases, if you wish, you can also apply CSS to minimize the padding between the label and button the border.
From your previous comment (I want to use simple captions like "<" and ">"), I think option 2 (Make the label text for the button very short) is what you want.
You may also be interested in Joel's Designing for People Who Have Better Things To Do With Their Lives which would indicate, usability-wise that very small buttons are usually a pretty bad idea.
in your label/button you can use the textOverrun property to turn off ellipsis.
textOverrun.set(OverrunStyle.CLIP);
this is probably a bit late for you, so i am putting it here for lone wanderers digging up this question.
It puts ... because there's no room for the text. You can use bigger buttons or a smaller font but if you really want the dots gone use button.setEllipsisString(""); , but then you just get truncated text.
I have the following text:
وزا.word
But when displaying it on my JTable it looks like this:
word.وزا
In every JLabel or TextArea or any other input it does look like the original text:
وزا.word
ONLY on the JTable I am having such problem.
I do not care if it is making sense or not, and yes I know the Arabic Language is written from right to left. My guess is Java is detecting it and automatically inverting it, but I do not want it to.
Note: I have no idea what وزا means, and for practical purposes I don't care. It's also irrelevant for this case wether وزا.word does not make sense and word.وزا does or viceversa.
Note 2: The text, reversed or not is always aligned to the left (as I expect it to).
Thanks in advance.
At a guess, your default Locale is giving the default renderer a ComponentOrientation that is inconsistent with your other settings. You might try creating a custom renderer having the preferred orientation using one of the approaches suggested here.
Addendum: java.text.Bidi supports bidirectional reordering; you may be able to use unicode format control code points, as suggested in this Q&A.
As above. I have a modal JOptionPane that uses a text area to display a slightly larger than normal message. The Pane works fine and is currently roughly 300px sq. The problem is I am trying to output something similar to the following:
Amt (TAB HERE) x (TAB HERE) Type (TAB HERE) Price (TAB HERE)
Again I have no problem with the actual Panel at all it's displaying at the size I want but for some reason it "tabs" really far. Like 1/3 of the JOptionPane such that it cuts off after Type and I lose half my text. Is there any way I can specify the size of the tab I want? I've tried aligning manually using spaces but as you can imagine not all letters are the same width and it's just too damn hard to get it to line up properly so I NEED to tab. I don't want to mess around with new layout managers either. I am simply concatonating a string in a method returning it to a JTextArea and then putting that inside my JOptionPane so I'd like a solution that works doing this. If I output to the command line the tab looks normal, like maybe 5 odd characters but doing that in this manner it's more like 2 words long....
Worse case scenario I make a bigger JOptionPane but I would prefer not to for aesthetics.
You can put an HTML table in your JTextArea like they show here. Either a JTextArea or a JTable can go in a JOptionPane.
In order to be able to display a sentence on a, say, JPanel with a GridLayout(1,0) [i.e., only one line/row] and then be able to draw a syntax tree (or similar) above it, I want to display the sentence as a row of Strings, which each include one word.
The single Strings should then be either selectable (as in a JList), or I should at least be able to get their Location on the JPanel via getLocation().
Up to this point I have tried the following options, and had the following issues:
- Single Strings as JLabels: The JLabels are stretched out to fill the JPanel width, re-sizing them to fit the single String they're displaying seems complicated. I would want to be able to do this, however, to make the sentence look like a sentence and not like a badly layed out table.
- JList: All the functionality I want, but I'm unaware of an option to re-size the "cells" of a single String (cf. JLabel above). Also, I'm having difficulties restricting display of the JList to a single line/row (cf. another of my questions).
- JTextArea: I couldn't get my head round how to get the Location of the single Strings that I had appended to the JTextArea.
I'm aware that drawString() might be an option, but I'm afraid to use it since I don't want to mix AWT and Swing. Also, I would need to calculate the int values for x and y for every single String. And I'm not sure whether I'd be able to get their Locations at all (although I could of course save their ints in a Map or Vector since I have to calculate them anyway).
Thankful for any suggestions! Thanks!
I would use JTextArea and method modelToView()/viewToModel() to get x,y for position in nthe string and position in the string for coordinates x and y.
Also use Utilities class getWordStart() getWordEnd() getRowStart() getRowEnd() methods.
EDIT: As noted by camickr in the comments, setSize() is not an appropriate way to lay out Components (as this is automatically done by the respective LayoutManager, I have removed the respective code from my answer.
Triggered by StanislavL's answer, I have found a solution to do it via JTextField, albeit by using one for each String rather than just one (as suggested by StanislavL).
I can now easily getLocation() for each JTextField. Simple, really!
I'd like to thank StanislavL for his answer, without which I'd never have though about this, and camickr for his comment.
I have a JLabel that needs to display some html-formatted text. However, I want to restrict this to being 4 lines long (and if so, provide a button to see everything).
So far, I've tried setting the maximum size manually or via a layout manager. However, both of these solutions can cause part of a line to be displayed.
edit: To add a little more details, I need to force 4 lines even when respecting line wrapping correctly, resizing components, and changing font sizes. I've considered handling resize/fontsize changes by replacing the label with a new one that fits correctly.
JLabel seems to handle incomplete tags well, so I could probably do something like a binary search on the input string finding which character would cause it to go over the 4 line limit (using FontMetric to determine how many pixels 4 lines would be), and then replacing an existing label with the new one. The big downside to this approach is that I need to run the computation every time the user resizes the panel or changes fonts (and it feels like a dirty dirty hack).
Add the JLabel to a JScrollPane as set the scrollpane with a reasonable preferred size. Scrollbars will appear a necessary.
I don't know of any absolute solution to the questions since I doubt you can define what a "line" is. One line of text may be font 12 and another 24. I don't know of any way to calculate the height of each given line.
Even if you did use a ComponentListener to handle the componentResized() event I'm not sure you can come up with a reasonable algorithm to to calculate the exact width/height of of a 4 line display.
I would try running through the String of text and removing all text after the third "\n"
String shortenText(String oldtext){
String newText = "";
for(int i=0;i<3;i++){
newText += oldtext.substring(0,oldtext.indexOf("\n"));//adds one line to String
oldtext = oldtext.substring(indexOf("\n")+1);//shorten old string to prepare for next iteration
}
return newText;
}
You may also want to try the same algorithm, except strip of <p> and <br> tags as well...
If you know the values of the possible tags just switch the text from "\n" to "<br>" or any tag you need
Hey, I found a way that works. The framework I'm working with allows me to create a listener for font size changes. In this listener, I determine what the new max size of the label is (getFontMetrics(font).getHeight() * 4) and then re-set the maximum height on the label to this and then relayout everything. This even handles the word wrap case well. I'm guessing that someone could do nasty things with silly HTML input, but this covers the 99% case pretty well.