java - JTextArea Question

[Harry_Hardcore]

was wondering how one you have set a size to your JTextArea, how do you make it so that this size doent change, so onle the space provided can be typed in eg.limit it to 50 chars

can it be done with JTextFields also?

 

[tim_m]

do you want to limit the number of characters the user is allowed to type into the field, after a certian amount, they can't enter any more even if they keep typing or do you only want it to scroll vertically, with wrapping? if you just want wrapping, when you instantiate the object you set the rows and colums (you can set them with the appropriate methods as well). you can then use obj.setLineWrap(true); to make it wrap. i'm not sure if there's a direct way to limit the number of possible characters. my first guess would be to make a listener for the textarea and check the number of characters every time it changes. if it's more than the number, delete the extra.

 

[toaster83]

Just to add on to what tim_m said, a JTextArea can be multiline while a JTextField is forced to a single line of entry. So if you want to word wrap, make sure to use a JTextArea. Other than that, I confirm what tim_m said above.

Oh, I just realized that you may be referring to something else. According to the API, setting rows and columns sets the "preferred size" of the JTextArea. I think that essentially means that it won't make it any larger than that, but that it will resize to make the area smaller if necessary. I don't know of a way to set a hard limit that overrides that "functionality." Obviously, for applets that shouldn't be too much of a problem since the author sets the size and that can't be changed. For applications, however, that is a different story.

The only thing I can think of is put the area in a JScrollPane, so that if the panel gets too small, it will just let the user scroll and not change the size. I'm pretty sure that's how it works, but I haven't worked with the JFC for a few months now (summer vacation), so I may be a little off.

Hopefully that helps. If you tell us what you are trying to do, maybe more precise assistance can be provided. Good luck.

 

[Harry_Hardcore]

thanks for the replys

i think ill put the listener in and just delete any extra characters. Im looking to allow a maximum of 50 characters entered and not allow any more.

 

[KingKaeru]

thanks for the replys

i think ill put the listener in and just delete any extra characters. Im looking to allow a maximum of 50 characters entered and not allow any more.

Yep, toss a listener on it and do a setText(myField.getText().substring(0,MAX_LENGTH)) on change.when myField.getText() > MAX_LENGTH

--KK

 

[tim_m]

the only problem i see with that (which i saw when i replied but didn't [and still don't] know the answer to so i didn't mention it then) is that if on the odd chance a user inserts text in the middle of the field somewhere, every char added would cause the one on the end to be chopped off, not the one just added. i have no idea how to work that out, however, if it's not an issue, then all the better

 

[KingKaeru]

the only problem i see with that (which i saw when i replied but didn't [and still don't] know the answer to so i didn't mention it then) is that if on the odd chance a user inserts text in the middle of the field somewhere, every char added would cause the one on the end to be chopped off, not the one just added. i have no idea how to work that out, however, if it's not an issue, then all the better

You could also just buffer it and not allow pastes over MAX_LENGTH

check old string with new string.
if newstring > MAX_LENGTH, set to oldstring
set oldstring to myText.getText.

--KK

 

[toaster83]

If you wanted to really make it fancy, you could also code it so that if there is five characters available and you try to paste in more than that, then it would just put in the first five characters of the pasted string. Buffering makes all sorts of things possible, esp with java.util.regex, if one were so inclined.

I'm surprised the Java devs haven't put in a maximum length method into these classes. This seems like something that would be needed by enough people to warrant its own method. Also, it could be handled much more efficiently at a lower level than having to deal with a TextListener class. *shrug*

 

[KingKaeru]

If you wanted to really make it fancy, you could also code it so that if there is five characters available and you try to paste in more than that, then it would just put in the first five characters of the pasted string. Buffering makes all sorts of things possible, esp with java.util.regex, if one were so inclined.

I'm surprised the Java devs haven't put in a maximum length method into these classes. This seems like something that would be needed by enough people to warrant its own method. Also, it could be handled much more efficiently at a lower level than having to deal with a TextListener class. *shrug*

Nothing prevents you from writing your own component

about allowing users to paste only upto max_length and then dropping off the extra, it wouldnt be much more work. You have to realize though that when you have about 50+chars, it's pretty significant and could confuse the user. e.g. user pastes thinking that it will all be there when it really isnt. This could easily happen when pasting a chunk of text into the middle of another string. In the end, it depends on how the app is used. That's definately something to think about though.

--KK

 

[toaster83]

Nothing prevents you from writing your own component

Writing the component oneself is simple enough. I'm just talking about it from an efficiency point of view.

about allowing users to paste only upto max_length and then dropping off the extra, it wouldnt be much more work. You have to realize though that when you have about 50+chars, it's pretty significant and could confuse the user. e.g. user pastes thinking that it will all be there when it really isnt.

I suggested that only because I think that's how it works for web forms and such. But I might be wrong on that. In any event, I agree it would be simple enough.