[Repast-developer] [ repast-Bugs-1241755 ] Adding DisplaySurface fails before displayable is added

[SourceForge.net <no...@so...>]

Bugs item #1241755, was opened at 2005-07-20 18:07
Message generated for change (Comment added) made by reubgr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101703&aid=1241755&group_id=1703

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: None
Priority: 6
Submitted By: Reuben Grinberg (reubgr)
Assigned to: Nick Collier (srcnick)
Summary: Adding DisplaySurface fails before displayable is added

Initial Comment:
Adding a DisplaySurface to a Containter (such as a JPanel) before a 
Displayable has been added to the DisplaySurface leads a 
NullPointerException since the Painter has never been set.
java.lang.NullPointerException
        at uchicago.src.sim.gui.Painter.createBufferedImage(Unknown 
Source)
        at uchicago.src.sim.gui.LocalPainter.paint(Unknown Source)
        at uchicago.src.sim.gui.DisplaySurface$DUpdate.run(Unknown 
Source)
        at java.awt.event.InvocationEvent.dispatch
(InvocationEvent.java:171)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy
(EventDispatchThread.java:234)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy
(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEvents
(EventDispatchThread.java:178)
        at java.awt.EventDispatchThread.pumpEvents
(EventDispatchThread.java:170)
        at java.awt.EventDispatchThread.run
(EventDispatchThread.java:100)

In addition, since DisplaySurface doesn't seem to add displayables 
via the normal Container.add() mechanism, I can't call 
myDisplaySurface.getComponentCount() as a work around. This also 
means that I can't add a Container listener to the DisplaySurface to 
know when a Displayable has been added.

----------------------------------------------------------------------

>Comment By: Reuben Grinberg (reubgr)
Date: 2005-08-05 18:32

Message:
Logged In: YES 
user_id=174152

Any reason this was closed without a resolution?

----------------------------------------------------------------------

Comment By: Reuben Grinberg (reubgr)
Date: 2005-08-05 14:48

Message:
Logged In: YES 
user_id=174152

In addition, it'd be really nice to separate out the JFrame stuff from the 
container stuff. We've had a hell of a time getting access to the JFrame 
created by DisplaySurface.display(). Maybe one way to deal with this is 
to keep all the functionality in DisplaySurface but create a separate 
class called DisplaySurfaceFrame or something like that. Since a lot of 
people probably use the DisplaySurface.display() function, we can set 
that up so it  displays the current DisplaySurface inside of a 
DisplaySurfaceFrame. Users who need more control (like me!) , 
however, could put the DispaySurface inside of a DisplaySurfaceFrame 
themselves or could put the DisplaySurface inside of another container. 
For a while we were experimenting with a one-window UI where 
everything was in SplitPanes and so we wanted the DisplaySurface to 
show up in one of the panes. There were a lot of issues that we had to 
work-around.

Come to think of it, there is a similar design issue with 
OpenSequenceGraph. The display method just displays a graph and 
doesn't give me access to it. It'd be nice to have an 
OpenSequenceGraphFrame or something like that. Even having a 
function in OpenSequenceGraph that returned the JFrame without 
displaying it would be much better.

Thanks,
Reuben Grinberg

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101703&aid=1241755&group_id=1703