Article View: borland.public.jbuilder.java.swing
Article #12719Re: JBuilder's support of implementing AbstractModels...
From: Greg Hamer
Date: Fri, 06 Nov 1998 00:00
Date: Fri, 06 Nov 1998 00:00
106 lines
5643 bytes
5643 bytes
You used the wrong wizard. If you use the override Methods wizard, (just
press OK, an obscure thing to do since it is asking you to choose a method
and none of the abstract methods show up in the list) it will generate stub
methods for all the abstract methods that need to be implemented. It would
not be hard to have the implement interface wizard look for unimplemented
abstact methods also. Probably the new Class wizard should do it also. The
New Bean wizard has a browse button like you desire. It does the same stuff
as the new class wizard; I forget why we left the new class wizard in the
product.
We intend to add a feature so that any class(already on the classpath) can
specified and then dropped into the designer without first adding it to the
palette or adding to the code by hand. Then you could select jTable1 and set
the model from the inspector to the model that you dropped from the
designer. Does this
sound ok?
Geoffrey L. Goetz wrote:
> Start fresh with an new Core JDK and Swing Application.
> Add a JScrollPane Swing Container to the JFrame
> Add a JTable to the JScrollPane
>
> File | New | Class
> Extend from com.sun.java.swing.table.AbstractTableModel
> NOTE: It would be nice if the Class wizard could browse through
> the libraries to find the name of the class to extend.
>
> Wizards | Implement Interface
> Implement the com.sun.java.swing.table.TableModel interface.
>
> Save All; Build All - ERRORS...
>
> Use of the Implement Interface Wizard was an attempt to add the "stub"
> code necessary to make this new class an 'implementable' class rather
> than just another abstract class. AbstractTableModel does implement
> some of the necessary methods in the TreeModel interface, but not all.
> I was hoping that the interface wizard would be smart enough to
> implement the rest. It adds only the implements phrase when the
> implements phrase was not really necessary.
>
> public class MyClass1 extends AbstractTableModel implements TableModel
> {
> ^^^^^^^^^^^^^^^^^^^^^
>
> If you compile the new class at this point it will error out indicating
> that the class should be declared abstract since it does not implement
> the getValueAt(int, int) method. Add the method and compile again and
> the compiler asks you to implement the getColumnCount() method. Add the
> method and compile again and the compiler asks you to implement the
> getRowCount() method. This is what the implement interface wizard was
> designed to avoid isn't it?
>
> getRowCount(), getValueAt(int, int), and getColumnCount() were the
> methods I was hoping that the Implement Interface Wizard would have
> added for me. Yes, I realize that I must 'do' something in these
> methods. Here is an example implementation of the methods for the new
> class (MyClass1) just created...
>
> public Object getValueAt(int rowIndex, int columnIndex){
> return new String("test");}
> public int getColumnCount(){
> return 5;}
> public int getRowCount(){
> return 5;}
>
> The new class created (MyClass1) does not show up in the pull down of
> the model attribute of the jTabel component, you must manually add the
> following line of code in the jbInit() of the JFrame...
>
> jTable1.setModel(new MyClass1());
>
> If you follow the above steps and add the above code, you will get a
> compilable/runnable application that displays a table five by five with
> the string text "test" in each rows column. After you compile MyClass1,
> the designer will display the text values as well.
>
> I would like the tool to be a little more helpful in working with Swing
> Models and Components (MVC). I feel like I am using a hammer to drive a
> nail through a plane of wood and the nail is not moving at all. The
> hammer is not doing its job. I will add that I am impressed that the
> designer is responding quite nicely to the manual code edits I have
> added. "Under the hood" JBuilder is MVC solid! But the wizzards and
> code generaors could stand to be updated a little for more MVC type
> programming.
>
> Thanks!
> -Geoff
>
> --
>
> \\|//
> | (o o) |
> =-=-=-=-=-=-=-=-=-=-=-=-=-(_)-=-=-=-=-=-=-=-=-=-=-=-=-=
> _|__ ______ __|_
> (____) / _____) ___ ______ _____ _____ (____)
> (____) / / ___ / ___) / __ / / ____)/ ____) (____)
> (____) / /___/ // ___) / /_/ / / ___) / ___) (____)
> (__) /_______//_____)/_____/ /_/ /_/ (__)
> | |
> | http://home.columbus.rr.com/ggeoffre |
> | |
> | .oo0O O0oo. |
> | ( ) ( ) |
> =-=-=-=-=-=-=-=-=-=-=-\ (-=-=-) /-=-=-=-=-=-=-=-=-=-=-=
> \_) (_/
Technical Details
Message-ID:
<36437921.B9005FEA@inprise.com>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<36431108.E0C06DBB@bottom.of.note.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 111d45,b407ec72108c3abf X-Google-Attributes: gid111d45,public From: Greg Hamer <ghamer@inprise.com> Subject: Re: JBuilder's support of implementing AbstractModels... Date: 1998/11/06 Message-ID: <36437921.B9005FEA@inprise.com> X-Deja-AN: 409179605 Content-Transfer-Encoding: 7bit References: <36431108.E0C06DBB@bottom.of.note.com> Content-Type: text/plain; charset=us-ascii Organization: Another Netscape Collabra Server User Mime-Version: 1.0 Newsgroups: borland.public.jbuilder.java.swing