SteppedComboBox problem

Thread view:

hilz - 29 Oct 2005 06:09 GMT

Hi all

I am using the SteppedComboBox that i got from here:

http://www.codeguru.com/java/articles/163.shtml

and when i compile it using JDK 5.0 with -Xlint:deprecation i get the
deprecation warning about the SteppedComboBoxUI.show() method being
deprecated.

If i change this method

public void show() {
....

to

public void setVisible(boolean isVisible){
if(!false==isVisible){
super.hide();
return;
}
....

it compiles fine with no deprecation warnings, but when i run it, and
right when i click on the combo box to expand its popup list, i get a
stack overflow exception shown at the end of this message.

Does anyone know how can i remove this deprecation message and yet keep
this combo box working?

thanks for any insight.

Exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError
    at sun.awt.windows.WComponentPeer.getLocationOnScreen(Native Method)
    at java.awt.Component.getLocationOnScreen_NoTreeLock(Component.java:1674)
    at java.awt.Component.getLocationOnScreen(Component.java:1652)
    at
javax.swing.SwingUtilities.convertPointFromScreen(SwingUtilities.java:350)
    at
javax.swing.plaf.basic.BasicComboPopup.computePopupBounds(BasicComboPopup.java:1172)
    at
com.geopak.road.qdm.SteppedComboBoxUI$1.setVisible(SteppedComboBox.java:25)
    at javax.swing.JPopupMenu.show(JPopupMenu.java:951)
    at
com.geopak.road.qdm.SteppedComboBoxUI$1.setVisible(SteppedComboBox.java:40)
    at javax.swing.JPopupMenu.show(JPopupMenu.java:951)
    at
com.geopak.road.qdm.SteppedComboBoxUI$1.setVisible(SteppedComboBox.java:40)
    at javax.swing.JPopupMenu.show(JPopupMenu.java:951)
    at
com.geopak.road.qdm.SteppedComboBoxUI$1.setVisible(SteppedComboBox.java:40)
    at javax.swing.JPopupMenu.show(JPopupMenu.java:951)
    at
com.geopak.road.qdm.SteppedComboBoxUI$1.setVisible(SteppedComboBox.java:40)
    at javax.swing.JPopupMenu.show(JPopupMenu.java:951)
    at
com.geopak.road.qdm.SteppedComboBoxUI$1.setVisible(SteppedComboBox.java:40)
.....(this keeps repeating so many times....

P.S.
SteppedComboBox.java:25=Rectangle popupBounds = computePopupBounds( 0,
SteppedComboBox.java:40=show( comboBox, popupBounds.x, popupBounds.y );

Reply to this Message

hilz - 29 Oct 2005 06:13 GMT

correction: the setVisible method i added is:

public void setVisible(boolean isVisible){
if(false==isVisible){
super.hide();
return;
}
....

so there is no "!" in the if statement.

Thanks for any help.

Reply to this Message

Chris Smith - 29 Oct 2005 06:28 GMT

> I am using the SteppedComboBox that i got from here:
>
[quoted text clipped - 3 lines]
> deprecation warning about the SteppedComboBoxUI.show() method being
> deprecated.

Yes. That's because BasicComboPopup is a JComponent, and the show()
method of JComponent is indeed deprecated.

> If i change this method
>
[quoted text clipped - 13 lines]
> right when i click on the combo box to expand its popup list, i get a
> stack overflow exception shown at the end of this message.

Yes, the code you ellipsed contains a call to show(Component,int,int)
and that in turn calls setVisible, resulting in your infinite loop. The
easiest way to avoid this is to go ahead and ignore the deprecation
warning. In this case, since an interface declared an undeprecated
show() method, the warning is just being picky anyway.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Roedy Green - 31 Oct 2005 10:18 GMT

>If i change this method
>
[quoted text clipped - 9 lines]
> }
> ....

Why would you override setVisible? Leave it alone!

if (!false == isVisible) is one heck of a roundabout way of saying

if ( isVisible )

The return is not likely needed.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

Roedy Green - 31 Oct 2005 11:50 GMT

On Mon, 31 Oct 2005 09:18:13 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :

>if ( isVisible )

that's the way you want it not if ( ! visible )

If it is visible, then hide it, otherwise there is nothing to do. It
is already hidden.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

hilz - 31 Oct 2005 12:42 GMT

>> If i change this method
>>
[quoted text clipped - 10 lines]
>> ....
> Why would you override setVisible? Leave it alone!

overriding it is what makes the combo box a stepped one! it resizes the
dropdown list to the longest item in the list.

> if (!false == isVisible) is one heck of a roundabout way of saying
>
> if ( isVisible )
>
> The return is not likely needed.

I corrected myself in a reply to my OP, and actually this is what it
needs to be:

if(false==isVisible){

because if the setVisible was called with (false) then we simply need to
hide it, and ofcourse return. but if we were setting it to (true) then
we need to do the resizing. but this is causing a stack overflow because
of infinite recursion.

Anysays, as Chris said, "In this case, since an interface declared an
undeprecated show() method, the warning is just being picky anyway."

and i actually think it is not just picky, it is actually being silly!

Reply to this Message

Roedy Green - 01 Nov 2005 03:18 GMT

> if(false==isVisible){

I would write that as

if ( ! isVisible )

I read that code to myself as "if not visible .. which is pretty
close to English

Your way to me reads a bit the way Yoda would speak;

if falseness equals the visibility ...

I just does not connect with any sort of reality.

It makes me go "huh?" and have to think it out as if I were newbie.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

hilz - 01 Nov 2005 09:33 GMT

>>if(false==isVisible){
>
[quoted text clipped - 12 lines]
>
> It makes me go "huh?" and have to think it out as if I were newbie.

Well... I aquired this habit from my employer's coding style guidelines!
And beleive it or not, they claim "readability" is the issue!

Reply to this Message

Roedy Green - 01 Nov 2005 11:49 GMT

>Well... I aquired this habit from my employer's coding style guidelines!
>And beleive it or not, they claim "readability" is the issue!

Hmm. I could possibly see

if ( isVisible == false ) for readability.

I think your boss flipped it backwards for a quite different reason
than legibility.

if ( "peanuts".equals( s ) )

This code works even when s is null.

if (s.equals( "peanuts" ) )

throws a NullPointerException if s is null.

So he wanted people to get in the habit of putting the desired value
first.

To conform I would say that to myself as:

peanuts I want for s then ...

if ( false == isVisible ) )
would become

false I want for visibility, then ...

If things were done that way consistently you would have no trouble,
but seeing in the middle of conventional code, it sounds like madness
until you look at it carefully.

It seems weird learning to talk to yourself like a Yiddish tailor to
be able to program fluently.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

hilz - 01 Nov 2005 12:45 GMT

>>Well... I aquired this habit from my employer's coding style guidelines!
>>And beleive it or not, they claim "readability" is the issue!
[quoted text clipped - 32 lines]
> It seems weird learning to talk to yourself like a Yiddish tailor to
> be able to program fluently.

part of the reason is for avoiding wasting time chasing bugs...

if you meant to say
if(isVisible==false)
but you made a mistake and wrote it this way
if(isVisible=false)
then this will compile and you will later spend time debugging to figure
out what went wrong....
but if you meant to say
if(false==isVisible)
and you made a mistake and wronte it this way
if(false=isVisible)
then this will give you a compile error which you will fix immediately.

for the same reason, you test constants the same way.
if you have a
static final int SOME_CONST=1;
then you test it using
if(SOME_CONST==aVar)
and not
if(aVar==SOME_CONST)

I think there is some sense to it!

Reply to this Message

SteppedComboBox problem

Free Magazines