How can a JTextField make the add() method believe it's another object?
I have created a HistoryTextField class that is supposed to replace any JTextField. It is actually an editable JComboBox that stores previously entered values so the user can choose from them.
Everything works nicely, my only problem is that it is not compatible with JTextField because my class now extends JComboBox. But for re-use purposes it should extend JTextField, so that it can replace any JTextField without changing variable declarations.
So I changed the code to extend JTextField, containing the JComboBox as a member. If HistoryTextField is added to a panel using the add() method, the JComboBox should actually be added.
Which method(s) of the JTextField do I have to override to accomplish this?
[739 byte] By [
micro5a] at [2007-11-27 11:47:34]
# 1
You could consider to use the autocomplete classes from SwingLabs:
http://download.java.net/javadesktop/swinglabs/releases/0.8/docs/api/org/jdesktop/swingx/autocomplete/package-summary.html
http://swinglabs.org/
-Puce
Pucea at 2007-7-29 18:14:03 >
# 2
Interesting but that was not the question.
# 3
I'm not sure this is possible, but I'd suggest all the size-related methods and
any paint-related methods all need to invoke the methods on the combo.
Probably any visiblity or showing methods and parent-related methods too.
Possibly non-text field specific listener-related methods such as property
change listeners, component listeners, hierarchy listeners too.
JayDSa at 2007-7-29 18:14:03 >
# 4
> Interesting but that was not the question.
That sometimes happens when a wrong question is asked. Instead of going against the stream, you can use existing third-party solutions to add auto-completion support to text components and comboboxes.
http://today.java.net/pub/a/today/2007/07/19/adding-auto-completion-to-swing-comboboxes.html
# 5
It was easy and fun to implement but thanks for the link.
However, my aim is to replace a JTextField with that HistoryTextField, not a JComboBox. But my class is working, my question concerns just a nice-to-have detail of it. Your link doesn't help, though.
# 6
> But my class is working
Then why are you asking a question?
You can't simply extend a JTextField and enclose a JComboBox. It is not a text field and can't be used as one without a lot of coding.
# 7
> It was easy and fun to implement but thanks for the
> link.
>
> However, my aim is to replace a JTextField with that
> HistoryTextField, not a JComboBox. But my class is
> working, my question concerns just a nice-to-have
> detail of it. Your link doesn't help, though.
I haven't used the SwingLabs myself, but from the documentation, they seem to support text fields, too, not just combo boxes. Why to implement your own, when you can use an existing, probably more tested solution, and then have more time to concentrate on your business code? That's why I posted that link.
-Puce
Pucea at 2007-7-29 18:14:03 >
# 8
> > But my class is working
>
> Then why are you asking a question?
>
> You can't simply extend a JTextField and enclose a
> JComboBox. It is not a text field and can't be used
> as one without a lot of coding.
Such a pity, one tiny little language restriction away from
public class HistoryTextField extends JTextField, JComboBox {
:-)
# 9
> Why to implement your own, when
> you can use an existing, probably more tested
> solution, and then have more time to concentrate on
> your business code?
For fun? For the challenge? As an exercise in learning more about Swing than just adding stuff to panels? To avoid dependencies to third-party libraries? For licensing reasons? (Not sure if the last one is applicable to SwingLabs.)
There are several reasons I can think of why one would want to do something like this oneself. Some may be good, some may be bad, tt all depends on the situation.
# 10
> > Why to implement your own, when
> > you can use an existing, probably more tested
> > solution, and then have more time to concentrate
> on
> > your business code?
>
> For fun? For the challenge? As an exercise in
> learning more about Swing than just adding stuff to
> panels? To avoid dependencies to third-party
> libraries? For licensing reasons? (Not sure if the
> last one is applicable to SwingLabs.)
>
> There are several reasons I can think of why one
> would want to do something like this oneself. Some
> may be good, some may be bad, tt all depends on the
> situation.
Yes, of course there are some situations, that's why I said he should "consider" in the first response. But I think just doing something someone else has already done without something new is a waste of time and energy! You want to do something fun, something challenging, something to learn from - everything fine, but I think there are plenty of things one could think of, which don't exist yet. Just my 2 cents.
-Puce
Pucea at 2007-7-29 18:14:03 >
# 11
Sometimes it's just a matter of information. If I had known of the existing component I probably had used it. So what? As I said it was fun to do it, it cost me just a few hours of finetuning it, and it made me feel like being a creative person instead of just someone reusing an existing component. :)
(Which doesn't mean I will not perhaps give that existing thing a try. Though it doesn't solve the initial question of this thread, it has the same problem as my one.)
# 12
> So I changed the code to extend JTextField,
> containing the JComboBox as a member. If
> HistoryTextField is added to a panel using the add()
> method, the JComboBox should actually be added.
>
> Which method(s) of the JTextField do I have to
> override to accomplish this?
So you have a text field that you put a combobox in? The add method is in the panel, if you wanted that to add the combobox instead of the field, the panel is the one that would have to know how to extract the combobox from the text field. Or just add the combobox.
But that doesn't really matter. If some other code is expecting this component to be a JTextField, it has to be a JTextField or subclass thereof.
