🚀 go-pugleaf

Hi Alan,

All objects implement serializable????

class ItemListener extends MouseInputAdapter implements Serializable ???????

Hope this helps

Arth


"Alan Shiers" <ashiers@hfx.eastlink.ca> wrote in message
news:41d0409e$1@newsgroups.borland.com...
> Hi there,
>
> I'm working on a project where I'm saving to file a subclass of JPanel,
> which in turn contains other objects. All the objects being saved in the
> project implement Serializable.  I have no problem saving to file and
> re-opening the file. But some functionality of the objects are lost!  For
> instance, all the objects have an inner class that extends MouseAdapter,
> like this:
>
> class ItemListener extends MouseInputAdapter
> {
>    public void mousePressed(MouseEvent e)
>    { System.out.println("mousePressed");
>      if(type != InputType.TEXTBOX)
>        JTestComposer.setEditor(MyComponent.this);
>    }
> }
>
> Once I open the file and click on the object, this mousePressed(....)
> method
> is supposed to fire. But it doesn't.  The call to
> JTestComposer.setEditor(MyComponent.this); actually brings up a Properties
> dialog box for this object. I can't get the Properties dialog box though
> if
> mousePressed(...) doesn't fire.
>
> What's the reason for this? How do I fix it?
>
> Alan
>
>

Thanks Arthur ... since the class ItemListener was an inner class, I didn't
realize it too needed to be Serializable as is the outer class.

Now that that is solved...I have one other problem which you might be able
to answer. One of the classes I created called Table has a member of
primitive type int. Like so:

public class Table extends JPanel implements Serializable
{
  ...
  private static int RowCount = 0;
  ...
}

Table winds up being one of the objects being saved to file.
When I open the file for some reason this Table object doesn't retain the
state of what RowCount held originally when it was saved.

Is it because it was declared static or something silly like that?

When the file loads it displays all the TableRow objects in the Table as
expected, but for some reason RowCount doesn't retain the number it had of
these TableRow objects.

Any ideas?

Alan

On 12/27/2004 at 12:00:18 PM, Alan Shiers wrote:

> I'm working on a project where I'm saving to file a subclass of JPanel,
> which in turn contains other objects. All the objects being saved in the
> project implement Serializable.

Did you notice the following in the JPanel JavaDocs:

   Warning:  Serialized objects of this class will not be compatible
   with future Swing releases. The current serialization support is
   appropriate for short term storage or RMI between applications
   running the same version of Swing. As of 1.4, support for long
   term storage of all JavaBeansTM  has been added to the java.beans
   package. Please see XMLEncoder.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html

Yes it's because the fields are static. If you look at the javadocs for the 
Serialization interface it hints that only an object's non-static and 
non-transient fields are serialised.

Arth

 One of the classes I created called Table has a member of
> primitive type int. Like so:
>
> public class Table extends JPanel implements Serializable
> {
>  ...
>  private static int RowCount = 0;
>  ...
> }
>
> Table winds up being one of the objects being saved to file.
> When I open the file for some reason this Table object doesn't retain the
> state of what RowCount held originally when it was saved.
>
> Is it because it was declared static or something silly like that?
>
> When the file loads it displays all the TableRow objects in the Table as
> expected, but for some reason RowCount doesn't retain the number it had of
> these TableRow objects.
>
> Any ideas?
>
> Alan
>
> 

Ok, things are starting to fall into place a little better.  One other
functionality however is not being reinstated when I open a saved file. I
make use of Drag 'n Drop in my application.  Several instances of an object
that is getting saved is a class I named TargetPanel which extends JPanel
implements Serializable and in its constructor it calls a method called
installDnD().

installDnD() and associated inner class TargetPanelContainerListener are as
follows:

public class TargetPanel extends JPanel implements Serializable
{
    public TargetPanel()
   {
      ...
      installDnD();
   }
   ...
   ...
   protected void installDnD()
  {
    //setDragEnabled(true);
    setTransferHandler(new ComponentTransferHandler());
    addContainerListener(new TargetPanelContainerListener());
  }

  class TargetPanelContainerListener extends ContainerAdapter implements
Serializable
  {
     public void componentAdded(ContainerEvent e)
     {  System.out.println("entering componentAdded");
       if(e.getChild() instanceof InputTool)
       {
         //Make sure every InputTool knows what row its in
         InputTool comp = (InputTool)e.getChild();
         comp.setItemNumber(TargetPanel.this.getRowNumber());
         //Set the isDirty flag
         if(DocumentPanel.isDirty == false)
            DocumentPanel.isDirty = true;
       }
     }
  }

When I open a saved file, I wound up manually iterating over every instance
of the TargetPanel(s) and calling installDnD() on each one in order to
reinstate each TargetPanel as being a viable drop target for transferable
components.  Is this usual? Wouldn't this functionality be saved. I
shouldn't have to do that should I?

Alan

On 12/29/2004 at 11:23:51 AM, Alan Shiers wrote:

> When I open a saved file, I wound up manually iterating over every
> instance of the TargetPanel(s) and calling installDnD() on each one in
> order to reinstate each TargetPanel as being a viable drop target for
> transferable components.  Is this usual? Wouldn't this functionality be
> saved. I shouldn't have to do that should I?

I can see no reason that you should have to, if serialization worked well
with Swing components.  But there have always been problems with Swing and
serialization, and Sun recommends against using it.  I tried serializing
Swing components back with JDK 1.2 and I quickly gave up on the idea.
Over the years I have seen many people try it, and they all had
significant problems.

There have been members that were marked as transient that held important
state, so that the state was lost when the component was deserialized.
There have also been members that were not marked as transient, but were
not serializable either, so serialization would fail.  In some cases,
these members were only set under specific circumstances, so the
serialization would only fail on occasion - usually after the code was
deployed.

What I have found works very well is to persist the model and to build the
view components from scratch when you launch your program.  You may have a
few view attributes that you want to save, but it is much easier to
persist just those attributes and apply them when you build the UI.  You
will have far fewer problems with this approach.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html