Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

gui system

Thread view: 
martijn - 09 Nov 2005 13:41 GMT
Hi,

I programmed my own custom gui system as an excercise, but I have some
troubles with threads accessing it simultaneous. I've posted this in
the
java.programmer group because its not AWT or Swing specific issue.

Before going into the actual problem I'll quickly tell how my gui
system is
setup:
-GuiComponent which handles all component specific methods, like
processing
input events, location, appearance etc.
-GuiContainer, a container holds components, the container also extends

component (so a container can contain other containers).

In my main app I add one "parent" container. This container is given
the AWT
peer component as a reference so it knows what size it has etc. I Also
dispatch all  mouse and key events to this parent container, the
container
delivers these to its components. Each container holds a list with
pointers
to active components (which it should draw and deliver events to) which
I'll
call activeList.

Now the problem I have occurs while painting. In the paint method of my
app
I call the parent container's render(Graphics g), which will trigger
the
parent container to iterate through all its components and draw them to
that
graphics context. This itself works ok.

But in some rare scenario's it throws a nullpointer exception, this is
caused by the AWT dispatch threads:

In my main app I call the parent container to draw its components, but
when
a mouse event occurs during this painting it's dispatched to the
components
in a seperate thread (because the events are triggered by the AWT
processMouseEvent, processKeyEvent on the AWT peer component). When a
component receives an event which triggers it to register itself
inactive,
it updates the container's activeList to remove itself. The paint
however is
also still working in the other thread, it loops through the
activeList,
which was updated while rendering which may cause a nullpointer
exception.

What would be a elegant solution to this problem?
I thought of creating a copy of the activeList in the render method,
but
this would be costy (for each frame a copy of the entire list) and
would
still result in nullpointer exceptions if the actual component is
removed.

The synchronized attribute would be no solution ofcourse since it only
protects that method from multiple threads accessing it. I would need
some lock on the activeList attribute...

Any ideas?
hilz - 09 Nov 2005 17:06 GMT
> Hi,
>
> I programmed my own custom gui system as an excercise, but I have some
> troubles with threads accessing it simultaneous.

All swing operations should be in a single thread. The swing dispatcher
thread.
Search for the SwingWorker example on the Sun website for a potential
solution to your problem.
hilz - 09 Nov 2005 17:10 GMT
here is a link

https://swingworker.dev.java.net/
martijn - 10 Nov 2005 00:54 GMT
> here is a link
>
> https://swingworker.dev.java.net/

thanks! though i dont use swing for my gui, it looks like i could adapt
the concept of a swingworker.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.