🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.jbuilder.java.language
Article #17424

Re: Button + Checkbox + CheckboxGroup == loads of fun

#17424
From: Paul Furbacher
Date: Fri, 20 Nov 1998 00:00
72 lines
2921 bytes
William Yu wrote:

>[...]
> However, I still do want to know if there is an answer to my original
> question. In part, it'll allow me to put something in *fast* so my main
> development track can continue. But mostly, to understand more about how
> Java  works.

Original idea: 

>     public class CheckboxButton {
>         ...
>>>>>     Checkbox dummy = new Checkbox(); <<<< focus attention here
> 
>         public CheckboxButton() {
>             dummy.addItemListener(new dummyListener(this, dummy));
>         }
> 
>         public void setState(boolean b) {
>             if (b != dummy.getState())
>                 dummy.setState(b);
>             ...
>         }
> 
>         public void setCheckboxGroup(CheckboxGroup cbg) {
>             dummy.setCheckboxGroup(cbg);
>             ...
>         }
>     }

The following is not guaranteed to work (I don't have time to 
test the idea).  But it is modeled after how the AWT CheckboxGroup
and Checkbox work together. 

I think if you just anonymously override the Checkbox's "setState()"
method, you'll get what you want (i.e., a link between your dummy
checkbox and you CheckboxButton).

  Checkbox dummy = new Checkbox() { 
    public void setState(boolean state) {
      super.setState(state); 
      this.setStateInternal(state);  // <<< this is the linkage, no events necessary
    }
  };

where "this.setStateInternal()" is 
declared as follows:

   public class CheckboxButton {
     private boolean state;

     //...
     private void setStateInternal(boolean state) {
        this.state = state;
        // ... do other state-change related things here
     }

This should avoid the likely stack overflow if the anonymous
class override were to call CheckboxButton.setState() method.

No events are needed in this approach.

> The lack of itemStateChange when the setState() method is called leads
> me to believe that CheckboxGroup is doing something else behind the
> scenes. 

Not really.  It's not using events to alter the states of
the two checkboxes.  It simply says "setState()" to the previously 
checkbox, if certain conditions are met.


Paul Furbacher
Technical Details
Message-ID: <3655B3AC.54F8FF76@bilbo.bio.purdue.edu>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <364ED33A.4C99CE@Bigfoot.com> <36506AD9.5B65D538@bilbo.bio.purdue.edu> <3650B77C.CAD1F182@Bigfoot.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f74b3,ad23d109ed8251a3
X-Google-Attributes: gidf74b3,public
From: Paul Furbacher <pf@bilbo.bio.purdue.edu>
Subject: Re: Button + Checkbox + CheckboxGroup == loads of fun
Date: 1998/11/20
Message-ID: <3655B3AC.54F8FF76@bilbo.bio.purdue.edu>
X-Deja-AN: 413955391
Content-Transfer-Encoding: 7bit
References: <364ED33A.4C99CE@Bigfoot.com> <36506AD9.5B65D538@bilbo.bio.purdue.edu> <3650B77C.CAD1F182@Bigfoot.com>
To: William Yu <William_Yu@Bigfoot.com>
Content-Type: text/plain; charset=us-ascii
Organization: Biological Sciences, Purdue Univ.
Mime-Version: 1.0
Reply-To: pf@bilbo.bio.purdue.edu
Newsgroups: borland.public.jbuilder.java.language