Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #1689 > unrolled thread

=?iso-8859-1?q?JComboBox=

Back to article view | Back to comp.lang.java.gui

Contents

  =?iso-8859-1?q?JComboBox= "Piet71" <piet71@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
    =?iso-8859-1?q?Re:_JCombo "Piet71" <piet71@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
    Re: JComboBox.setSelected "Roedy Green" <roedy.green@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
      =?iso-8859-1?q?Re:_JCombo "Piet71" <piet71@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
        Re: JComboBox.setSelected "Lew" <lew@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
          =?UTF-8?B?U3lzdGVtLm91dC5 "RedGrittyBrick" <redgrittybrick@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
            =?UTF-8?B?UmU6IFN5c3RlbS5 "Lew" <lew@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
              =?UTF-8?B?UmU6IFN5c3RlbS5 "RedGrittyBrick" <redgrittybrick@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
                =?UTF-8?B?UmU6IFN5c3RlbS5 "Lew" <lew@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
    =?utf-8?B?UmU6IEpDb21ib0J "Andrew Thompson" <andrew.thompson@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000
      =?iso-8859-1?q?Re:_JCombo "Piet71" <piet71@THRWHITE.remove-dii-this> - 2011-04-27 15:34 +0000

#1689 — =?iso-8859-1?q?JComboBox=

  To: comp.lang.java.gui
Hi,
I have written a program that heavily uses JComboBoxes to have the
user select some stuff. In oder to allow for a quick exchange between
JComboBox and JList, I have coded a class that could serve as Model
for both JComponents.  In my program it is frequently the case that
when the user selects an item from a JComboBox, the selection in other
JComboBoxes needs to be updated and the new selection shown in the
JTextField of the JComboBox. The latter is not working. Only when you
click on the JComboBox is the entry updated, though in the drop down
box, the correct item was already selected. Here is some sample code.
Is there something wrong with my CombinedListModel class?
Many thanks in advance!
Regards, Piet
import javax.swing.*;
import javax.swing.event.*;
import java.awt.event.*;
import java.awt.*;
import java.util.*;

public class ComboProblemDemo extends JFrame implements
ActionListener{
	JComboBox fruit;
	JComboBox basket;
	ArrayList<Fruit> fruitlist = new ArrayList<Fruit>();
	ArrayList<Basket> basketlist = new ArrayList<Basket>();
	CombinedListModel fruitModel;
	CombinedListModel basketModel;
	public static void main(String[] args){
		ComboProblemDemo cpd = new ComboProblemDemo("Combo Problem Demo");
		cpd.pack();
		cpd.setVisible(true);
	}
	public ComboProblemDemo(String title){
		super(title);
		fruitModel = new CombinedListModel();
		basketModel = new CombinedListModel();
		setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		JPanel panel = new JPanel();
		fruit = new JComboBox(fruitModel);
		fruit.addActionListener(this);
		basket = new JComboBox(basketModel);
		for(int b = 0;b<2;b++){
			basketlist.add(new Basket(b));
		}

		for(int f = 0;f<2;f++){
			Fruit fr = new Fruit(f);
			fruitlist.add(fr);
			fr.setBasket(basketlist.get(0));
		}

		for(int f = 3;f<5;f++){
			Fruit fr = new Fruit(f);
			fruitlist.add(fr);
			fr.setBasket(basketlist.get(1));
		}
		fruitModel.setItems(fruitlist);
		basketModel.setItems(basketlist);
		panel.add(fruit);
		panel.add(basket);
		setContentPane(panel);
	}
	public void actionPerformed(ActionEvent ae){
	
basketModel.setSelectedItem(((Fruit)fruit.getSelectedItem()).getBasket());
	}
}
class Fruit{
	private int index;
	private Basket basket;
	public Fruit(int index){
		this.index = index;
	}
	public String toString(){
		return "Fruit "+index;
	}
	public Basket getBasket(){
		return this.basket;
	}
	public void setBasket(Basket basket){
		this.basket = basket;
	}
}
class Basket{
	private int index;
	public Basket(int index){
		this.index = index;
	}
	public String toString(){
		return "Basket "+index;
	}
}
class CombinedListModel extends AbstractListModel implements
ComboBoxModel,ListSelectionListener{
	private java.util.List<? extends Object> items = new
ArrayList<Object>();
	private Object selected = null;
	public CombinedListModel(){
	}
	public void valueChanged(ListSelectionEvent lse){
		System.out.println("value changed, index is "+lse.getFirstIndex()+"
is adjusting:"+lse.getValueIsAdjusting() );
		//if (lse.getValueIsAdjusting()){
			//selected = this.items.get(lse.getLastIndex());
		selected = ((JList)lse.getSource()).getSelectedValue();
		//}
		//setSelectedItem(lse.getSource().);
	}
	public void setItems(java.util.List<? extends Object> items){
		this.items = items;
		if (items.size() > 0) selected = this.items.get(0);
		fireContentsChanged(this,0,getSize());
	}
	public Object getElementAt(int index){
		return items.get(index);
	}
	public int getSize(){
		int size = items == null ? 0 : items.size();
		return size;
	}
	public void setSelectedItem(Object item){
		System.out.println("Selection changed");
		if(items.contains(item)){
			selected =item;
		}
		else{
			System.out.println("Selection not possible");
		}
	}
	public Object getSelectedItem(){
		return selected;
	}
	public void clear(){
		this.items.clear();
		fireContentsChanged(this,0,this.items.size()-1);
	}
}

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#1690 — =?iso-8859-1?q?Re:_JCombo

  To: comp.lang.java.gui
Sorry, I just figured out that the title " JComboBox.setSelectedItem()
doesn=B4t display selected Item?" would have been more appropriate.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1691 — Re: JComboBox.setSelected

  To: comp.lang.java.gui
On 25 May 2007 14:24:12 -0700, Piet71 <pit.grinja@gmx.de> wrote,
quoted or indirectly quoted someone who said :

>basket = new JComboBox(basketModel);
>		for(int b = 0;b<2;b++){
>			basketlist.add(new Basket(b));
>		}

You hard coding lengths, a big naughty.  See
http://mindprod.com/jgloss/jcombobox.html
for how to do this.

Normally you add Strings rather than objects to the JComboBox.

You have so much extra stuff beyond the JComboBox that might not be
working. Get your code working with Strings. Then if you must use
objects, make sure they have a toString method, and add a couple
manually.  Then do your fiddling with ArrayLists and combining.

The way it is, you can't tell if you problem is with JComboBox or with
your ArrayLists and objects.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1692 — =?iso-8859-1?q?Re:_JCombo

  To: comp.lang.java.gui
Thanks for your comments, Roedy.
> The way it is, you can't tell if you problem is with JComboBox or with
> your ArrayLists and objects.
In my real program I have added lots of System.out.println's from
which I could tell that everything was working as expected and that
the selected object was updated except that the new selected object
was not shown in the JComboBox.
I have found out in the meantime that I simply need to fire an event
in my setSelectedItem method of the CombinedListModel class . Makes
sense that the JComboBox will not update its view when the
setSelectedItem method is invoked by bypassing the JComboBox. Here is
the new version. It seems to be working but is not throughly tested.
To do the testing I will have to remove that changes that I made
yesterday when desperately looking for the source of the unexpected
behaviour.
<code>
public void setSelectedItem(Object item){
    System.out.println("Selection changed");
    if(items.contains(item)){
        selected =item;
 
fireContentsChanged(this,items.indexOf(item),items.indexOf(item));
    }
    else{
        System.out.println("Selection not possible");
    }
}
</code>
Regards
Piet

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1696 — Re: JComboBox.setSelected

  To: comp.lang.java.gui
Piet71 wrote:
> In my real program I have added lots of System.out.println's from

One trouble with System.out.println (why didn't you use System.err?) is that 
they have to be removed for production.  There are many reasons not to use 
System.out for debug or trace purposes.

Why not using logging?


-- 
Lew

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1697 — =?UTF-8?B?U3lzdGVtLm91dC5

  To: comp.lang.java.gui
Lew wrote:
> Piet71 wrote:
>> In my real program I have added lots of System.out.println's from
> 
> One trouble with System.out.println (why didn't you use System.err?) is 
> that they have to be removed for production. 

Sorry to jump in here, I'd certainly agree that you should remove those 
sort of statements (or make them conditional), however since output to 
System.out is not normally visible in a jar'd Swing application (i.e. 
when not run from an IDE or command shell) - is there any major problem 
if they're left in?

> There are many reasons not 
> to use System.out for debug or trace purposes.

I'd be interested in reading your list of those reasons.

> 
> Why not using logging?

I can't answer for the OP, but in my case it went like this:

- System.out.println() works
   - it needs no special classes/jars bundled with your app.
   - it needs no complex XML config files
   - it needs no class instantiation/initialisation
   - it is just as easy to make conditional
   - it is just as easy to comment-out or remove using search/replace

- Logging classes seem like they're oriented to making complex
   logging needs possible. Few of them make simple jobs simple.

- There's too many to choose from. Writing System.out.println()
   a few dozen times takes a lot less gumption than studying a
   half dozen logging classes and choosing one then using it.

For my limited needs I preferred to reinvent the logging wheel myself, 
though I did feel properly guilty about it :-) I ended up with something 
I could control by environment variables or command line params, which 
could be used statically without configuration files or instantiation, 
which could have logging levels set programatically if needed, and which 
did the right thing in the absence of any configuration.

It goes without saying that it does a lot less than the more developed 
logging classes. But I like that it's as easy to use as 
System.out.println().

I still use System.out.println() for simple programs.

I'm open to persuasion, so I'm interested to hear more details of the 
evils of System.out.println().

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1718 — =?UTF-8?B?UmU6IFN5c3RlbS5

  To: comp.lang.java.gui
RedGrittyBrick wrote:
> Lew wrote:
>> Piet71 wrote:
>>> In my real program I have added lots of System.out.println's from
>>
>> One trouble with System.out.println (why didn't you use System.err?) 
>> is that they have to be removed for production. 
> 
> Sorry to jump in here, I'd certainly agree that you should remove those 
> sort of statements (or make them conditional), however since output to 
> System.out is not normally visible in a jar'd Swing application (i.e. 
> when not run from an IDE or command shell) - is there any major problem 
> if they're left in?

Only the drag on performance - println() is invoked regardless of need. 
Logging libraries are optimized for minimal impact on production performance.

>> There are many reasons not to use System.out for debug or trace purposes.
> 
> I'd be interested in reading your list of those reasons.

The performance reason, ibid.  Not having the output stream cluttered with 
trace statements.

>> Why not using logging?
> 
> I can't answer for the OP, but in my case it went like this:
> 
> - System.out.println() works
>   - it needs no special classes/jars bundled with your app.

Specious.

>   - it needs no complex XML config files

Neither does log4j.

>   - it needs no class instantiation/initialisation

Neither does log4j unless you need the flexibility.

>   - it is just as easy to make conditional

No, it isn't.  The conditions add complexity to your code, instead of being 
hidden inside the logging aspect.

>   - it is just as easy to comment-out or remove using search/replace

Which is a source code change, much harder than not changing source code. 
Logging wins, since it doesn't need any code change, not commenting out nor 
removal via search/replace.

> - Logging classes seem like they're oriented to making complex
>   logging needs possible. Few of them make simple jobs simple.

I have no idea how you came up with this.  Logging libraries are dog-simple to 
use, about as complex as:

Logger logger = Logger.getLogger( getClass() );
...
logger.error( msg );

> - There's too many to choose from. Writing System.out.println()
>   a few dozen times takes a lot less gumption than studying a
>   half dozen logging classes and choosing one then using it.

I cannot believe you are touting ignorance as an excuse.  Pathetic.

Logging takes all of five minutes to learn.  Arguing that you are too lazy to 
learn it is not an indictment of the logging library but of the practitioner.

> For my limited needs I preferred to reinvent the logging wheel myself, 
> though I did feel properly guilty about it :-) I ended up with something 
> I could control by environment variables or command line params, which 
> could be used statically without configuration files or instantiation, 
> which could have logging levels set programatically if needed, and which 
> did the right thing in the absence of any configuration.

I don't see how any of that differs from, say, log4j.

> It goes without saying that it does a lot less than the more developed 
> logging classes. But I like that it's as easy to use as 
> System.out.println().

I like logging, which is as easy to use as "logger.error( msg )" and doesn't 
require re-compilation to remove them,

> I still use System.out.println() for simple programs.
> 
> I'm open to persuasion, so I'm interested to hear more details of the 
> evils of System.out.println().

Go to, say, the Apache logging page for that.  They lay the argument out 
better than I can.

You should actually learn to use, say, log4j, before you pass judgment.  By 
admitting that you haven't learned either that nor java.util.logging, you 
admit that you do not have a basis for your judgment.

Try it, you'll like it.

-- 
Lew

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1722 — =?UTF-8?B?UmU6IFN5c3RlbS5

  To: comp.lang.java.gui
Lew wrote:
> RedGrittyBrick wrote:
>> - System.out.println() works
>>   - it needs no special classes/jars bundled with your app.
> 
> Specious.
> 

>>   - it needs no class instantiation/initialisation
> 
> Neither does log4j unless you need the flexibility.

All the examples I've seen seem to involve something like
`static Logger logger = Logger.getLogger(test.class);`

> 
>> - Logging classes seem like they're oriented to making complex
>>   logging needs possible. Few of them make simple jobs simple.
> 
> I have no idea how you came up with this.  Logging libraries are 
> dog-simple to use, about as complex as:
> 
> Logger logger = Logger.getLogger( getClass() );
> ...
> logger.error( msg );

Can you just invoke methods statically like
    Logger.error(msg);


>> - There's too many to choose from. Writing System.out.println()
>>   a few dozen times takes a lot less gumption than studying a
>>   half dozen logging classes and choosing one then using it.
> 
> I cannot believe you are touting ignorance as an excuse. 

I didn't think I was :-)

Actually its a problem I've encountered more than once with Java. A 
recent example: I have a web-service written in Perl and wanted to test 
access to the service from Perl, C# and Java. I'd a little experience of 
Perl and Java but none of C#.

With Perl, THE way to do web services is to use SOAP::Lite. No need to 
research lots of options. A SOAP::Lite test client can be written in 
under a dozen lines of code.

With C#, I'd not written a line of C# before, but I downloaded Mono, 
read http://www.mono-project.com/Web_Services, wrote a dozen lines of C# 
and typed four commands and had a working client within an hour. I 
didn't have to research several toolkits and choose one.

With Java I've spent hours Googling and reading reviews and tutorials 
for what seemed like dozens of web-services toolkits. Most of it seemed 
ten times as much work as Perl or C#. It was hard to work out what was 
obsolete stuff and what was 'standard' for Java 6. I downloaded the 
latest Eclipse Web-Tools Platform and tried to generate a stub class 
from the WSDL but had problems. In the end I used the rather nasty 
approach suggested in 
http://www.ibm.com/developerworks/xml/library/x-soapcl/ which I 
supplemented with a SAX parser, simply in order to avoid spending too 
much time learning something which was somewhat peripheral to the project.

> Pathetic.

Cruel bastard ;-)


> Logging takes all of five minutes to learn.  

I spent hours trying to find out what logging classes were available, 
which were widely used and whether any were a standard part of JRE 1.5.


> You should actually learn to use, say, log4j, before you pass judgment.  
> By admitting that you haven't learned either that nor java.util.logging, 
> you admit that you do not have a basis for your judgment.
> 
> Try it, you'll like it.
> 

I will try it, but I suspect I'll probably still use 
System.out.println() in small programs (one or two classes, < 200 LOC).




Appendix A:

Complete Perl web-services client

   #!perl
   use strict;
   use warnings;
   use SOAP::Lite;
   print SOAP::Lite
     ->proxy('http://example.com/service')
     ->uri('Widgets')
     ->getWidgetDescription('Foo');


Complete C# web-services client (excluding stub generated from WSDL)

   using System;
   class GetWidgetDescription {
       public static void Main(string [] args) {
           WidgetService service = new WidgetService();
           Console.WriteLine(service.getWidgetDescription("Foo"));
       }
   }

My real service returned arrays of objects but that didn't add 
significantly to the time taken to produce working Perl or C# clients 
with which to test the service.

Doubtless a Java client *can* be just as concise and easy to learn but 
the above were almost straight from the first tutorials I found. I've 
not found a simple Java tutorial that only uses classes that are part of 
the standard JRE.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1724 — =?UTF-8?B?UmU6IFN5c3RlbS5

  To: comp.lang.java.gui
RedGrittyBrick wrote:
Lew wrote:
>> Pathetic.

RedGrittyBrick wrote:
> Cruel bastard ;-)

Sorry.  Intended only for rhetorical effect.  All feelings hurt in this 
newsgroup are the sole responsibility of the reader, blah blah blah.

>> Logging takes all of five minutes to learn.  

> I spent hours trying to find out what logging classes were available, 
> which were widely used and whether any were a standard part of JRE 1.5.

Actually, this is a common problem with Java, all right.  I found that log4j 
was very simple, adapted well to learning a little at a time, and relieved me 
of all worries about re-instrumenting for production.  I therefore ignored all 
the other choices.

>> You should actually learn to use, say, log4j, before you pass 
>> judgment.  Try it, you'll like it.

> I will try it, but I suspect I'll probably still use 
> System.out.println() in small programs (one or two classes, < 200 LOC).

Or maybe you won't like it.  It took me a few projects to even bother to set 
up a log4j.properties for a project.  Its simplest uses did enough for a 
while, at least as much as println() and with much less footprint.

> Doubtless a Java client *can* be just as concise and easy to learn but 
> the above were almost straight from the first tutorials I found. I've 
> not found a simple Java tutorial that only uses classes that are part of 
> the standard JRE.

It's a fair cop.  Java can be a real beast.

-- 
Lew

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1694 — =?utf-8?B?UmU6IEpDb21ib0J

  To: comp.lang.java.gui
Piet71 wrote:
>Hi,
>I have written a program that heavily uses JComboBoxes to have the
>user select some stuff. In oder to allow for a quick exchange between
>JComboBox and JList, I have coded a class that could serve as Model
>for both JComponents.  In my program it is frequently the case that
>when the user selects an item from a JComboBox, the selection in other
>JComboBoxes needs to be updated and the new selection shown in the
>JTextField of the JComboBox. The latter is not working. 

I am not entirely confident I understand the code, but
try changing this bit for different behaviour.

>public class ComboProblemDemo extends JFrame implements
>ActionListener{
..

>	public void actionPerformed(ActionEvent ae){
>	
>basketModel.setSelectedItem(((Fruit)fruit.getSelectedItem()).getBasket());

  // tell the UI to update..
  repaint();

>	}
...

HTH

-- 
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via http://www.javakb.com

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#1721 — =?iso-8859-1?q?Re:_JCombo

  To: comp.lang.java.gui
On 26 Mai, 10:45, "Andrew Thompson" <u32984@uwe> wrote:
> Piet71 wrote:
> >Hi,
> >I have written a program that heavily uses JComboBoxes to have the
> >user select some stuff. In oder to allow for a quick exchange between
> >JComboBox and JList, I have coded a class that could serve as Model
> >for both JComponents.  In my program it is frequently the case that
> >when the user selects an item from a JComboBox, the selection in other
> >JComboBoxes needs to be updated and the new selection shown in the
> >JTextField of the JComboBox. The latter is not working.
>
> I am not entirely confident I understand the code, but
> try changing this bit for different behaviour.
>
> >public class ComboProblemDemo extends JFrame implements
> >ActionListener{
>
> ..
>
> >    public void actionPerformed(ActionEvent ae){
>
> >basketModel.setSelectedItem(((Fruit)fruit.getSelectedItem()).getBasket()=
);
>
>   // tell the UI to update..
>   repaint();
Thanks for the idea. I haven=B4t tried it yet, since the problem went
away by firing a suitable event in the model class that apparently
told the view (the JComboBox) to repaint. In this way, all JComboBoxes
that get their data from the CombinedListModel class should
automatically show the right behaviour w/o the need to repaint() all
of them. BTW, DefaultComboBoxModel also calls
fireContentsChanged(this,-1,-1) in its implementation of
setSelectedItem(Object o). I have changed my implementation
accordingly. However, I was unable to find when this event finally has
an effect in the JComboBox.
JComboBox implements ListDataListener and registers itself as such on
the ComboBox model in the JComboBox.setModel(ComboBoxModel aModel)
method. Thus, the JComboBox's contentsChanged method is invoked when
fireContentsChanged() is invoked in the model. The contentsChanged()
method calls protected selectedItemChanged() of JComboBox if the new
and old selection differ, and selectedItemChanged() then invokes
fireItemStateChanged() which then calls itemStateChanged() on every
registered ItemListener of the JComboBox and that seems to be the end
of the chain. I checked whether JComboBox registers itself as an
ItemListener on itself, but that doesn=B4t seem to be the case.
@Lew: Thanks for your hints regarding logging. I will have definitely
a look at log4j because I am reaching the limits of
"System.out.println()" debugging. But for my last problem, System.out
seemed to be the faster solution.
Regards, Piet

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.gui

csiph-web