 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / January 2006Jlist items not appearing occasionally
I am adding entries to a JList via a DefaultListModel from a single thread but sometimes the entries do not show unless I modify the list. To give some context, I have an instant messenger application and on login, several users are added to the list. Sometimes the list appears fine in that all users are shown and selectable etc. however sometimes nothing shows on the list - if this is the case, when another user logs in (thus adding agin to the list) the list shows correctly with all users. I have code below to show how I am initialising the list and adding to it. Should I be doing anything more? Is there a way to force the contents of the list to refresh? Thanks Allan // creation of list mList = new DefaultListModel(); mListBox = new JList(mList); mStatusBar = new JStatusBar(3); getContentPane().setLayout(new BorderLayout()); getContentPane().add(new JScrollPane(mListBox)); getContentPane().add(mStatusBar, BorderLayout.SOUTH); // adding to list mList.addElement(xiUser.userName()); // just a plane old String being added > I am adding entries to a JList via a DefaultListModel from a single thread > but sometimes the entries do not show unless I modify the list. To give [quoted text clipped - 19 lines] > // adding to list > mList.addElement(xiUser.userName()); // just a plane old String being added Code looks fine. Don't think this could be the problem but you cold try mList.add(mListBox.getModel().getSize(), xiUser.userName()); I would be concerned with the xiUser.userName() call. This must be the problem. Easy way to find out is to step trace it in a debugger.  SignatureThanks in Advance... IchBin, Pocono Lake, Pa, USA http://weconsultants.servebeer.com/JHackerAppManager __________________________________________________________________________ 'If there is one, Knowledge is the "Fountain of Youth"' -William E. Taylor, Regular Guy (1952-) >> I am adding entries to a JList via a DefaultListModel from a single >> thread but sometimes the entries do not show unless I modify the list. [quoted text clipped - 30 lines] > > Easy way to find out is to step trace it in a debugger. The Strings are definately defined and have length >0 however I think it might be a swing/threads problem... Allan >>> I am adding entries to a JList via a DefaultListModel from a single >>> thread but sometimes the entries do not show unless I modify the list. [quoted text clipped - 34 lines] > might be a swing/threads problem... > Allan I am do ton's of JTable updates across multiple tables with no problem. Are you loading your GUI as below.. javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { SomeCcreateAndShowGUIMethod(); } }); SignatureThanks in Advance... IchBin, Pocono Lake, Pa, USA http://weconsultants.servebeer.com/JHackerAppManager __________________________________________________________________________ 'If there is one, Knowledge is the "Fountain of Youth"' -William E. Taylor, Regular Guy (1952-) > I am do ton's of JTable updates across multiple tables with no problem. > Are you loading your GUI as below.. [quoted text clipped - 4 lines] > } > }); No I am not, not yet at least. If I create the gui in this way (which seems rather easy) then how do I add a String to my JList? I take it I need to use something like this: Runnable updateAComponent = new Runnable() { public void run() { component.doSomething(); } }; SwingUtilities.invokeLater(updateAComponent); (taken from sun website) My only problem is, how do I provide my String as a paramater to add it to the JList? (It cannot be final as the contents of the String are not known until runtime). Allan Jlist inherits the method repaint() which will redraw your list box and should show newly added elements if you call it just after adding something. Hope that helps. Sean Ingham Design 4 Sale > Jlist inherits the method repaint() which will redraw your list box and > should show newly added elements if you call it just after adding something. Something in your event handling is very wrong whenever you feel the need to call repaint() to get a change in the model recognized. The OP has either messed up the notification from the list model to the list, or he has probably messed up threading. Non of this has anything to do with repaint(). BTW: Posting in HTML to a newsgroup is a big no-no. You will end up faster in people's filters than you can say HTML. The same holds for advertising in the message body. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ > I am adding entries to a JList via a DefaultListModel from a single thread > but sometimes the entries do not show unless I modify the list. To give Is the single thread the Event Dispatch Thread (EDT)? Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> I am adding entries to a JList via a DefaultListModel from a single >> thread but sometimes the entries do not show unless I modify the list. [quoted text clipped - 3 lines] > > Tom Hawtin I dont think so - if my understanding of EDT is correct. I start up the program which creates all gui components and starts off worker threads. One of these worker threads is my socket listening thread which when the correct packet arrives, adds the users to the list. So it is a different thread to the one that created the list. Allan [JList contents occasionally display as empty] >> Is the single thread the Event Dispatch Thread >> (EDT)? > I dont think so - if my understanding of EDT is > correct. I start up the program which creates all [quoted text clipped - 3 lines] > the users to the list. So it is a different > thread to the one that created the list. Okay, then you've fallen into one of Sun's little pitfalls; Swing Isn't Thread Safe. Updates to the GUI need to be inserted into the Event Dispatch Thread by a "Runnable" mechanism, instead of being done directly in some other processing thread where they are calculated or the data causing them to be done is captured; do a web search for the details. Otherwise, due to race conditions between repaints and intervening second updates, Horrible Things May Happen, like a pointer ending up pointing out in space when its target goes away. xanthian. > [JList contents occasionally display as empty] > [quoted text clipped - 25 lines] > > xanthian. I have heard that Swing isnt thread-safe, but I assumed that this meant that calls to any operation across multiple threads should be synchronized, but it goes further than this it seems. I have had a look at the documentation on the Sunwebsite about this and what came to mind was - why? Why have they made it this way? This is a similar problem in win32 programming with message loops across different threads - I thought I had gotten away from this! Anyway, the documentation is not very clear - if I want to update my list by adding a String to it, how can I pass the String parameter? If this has to be done with a Runnable() object to I have to pass it as a param to the constructor? Thanks Allan > I have heard that Swing isnt thread-safe, but I assumed that this meant that Not only is Swing not thread-safe, it's not even thread-agnostic. It is, to a certain extent, thread-hostile. > calls to any operation across multiple threads should be synchronized, but > it goes further than this it seems. I have had a look at the documentation > on the Sunwebsite about this and what came to mind was - why? Why have they > made it this way? This is a similar problem in win32 programming with > message loops across different threads - I thought I had gotten away from > this! Unfortunately multithreading is not easy. > Anyway, the documentation is not very clear - if I want to update my list by > adding a String to it, how can I pass the String parameter? If this has to > be done with a Runnable() object to I have to pass it as a param to the > constructor? The easiest way is to make the String variable final and the subtype Runnable an anonymous inner class. Runnable is always subtyped, as it's an interface (and has no constructors). Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > The easiest way is to make the String variable final and the subtype > Runnable an anonymous inner class. Runnable is always subtyped, as it's an > interface (and has no constructors). > > Tom Hawtin It cannot be final as the contents of all of the Strings are unknown at compile-time :( Allan >> The easiest way is to make the String variable final and the subtype >> Runnable an anonymous inner class. Runnable is always subtyped, as it's an [quoted text clipped - 4 lines] > It cannot be final as the contents of all of the Strings are unknown at > compile-time :( final (as applied to a local variable) means that it can only be assigned once. As a local variable, that will have to be during that run of the method. public void addUser(User user) { assert !java.awt.EventQueue.isDispatchThread(); final String name = user.getName(); java.awt.EventQueue.invokeLater(new Runnable() { public void run() { assert java.awt.EventQueue.isDispatchThread(); list.addElement(name); } }); } Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> It cannot be final as the contents of all of the Strings are unknown at >> compile-time :( [quoted text clipped - 15 lines] > > Tom Hawtin Doh, of course, I feel a little stupid now! Anyway, so the above code could be executed from any thread, other than the EDT? Thanks Allan > I have heard that Swing isnt thread-safe, but I > assumed that this meant that calls to any > operation across multiple threads should be > synchronized, but it goes further than this it > seems. Yes. Because calls that update the graphical image have part of their execution deferred to the Event Handling Thread, while your computations and alterations on the thread where you do your work proceed apace, you are quite capable of mangling the dataset the repainting process intends to render to the screen, before that rendering process begins, or, most dangerously, while it is in progress, so that unrolling the method calling pushdowns on the EHT stack might bring back a list walk doing "nextItem" using a list item which no longer exists to point at anything. > I have had a look at the documentation on > the Sunwebsite about this and what came to mind > was - why? Why have they made it this way? Because screen painting is extremely labor intensive; by doing lazy refreshing, they can sometimes junk an entire repaint requirement that has been overtaken by events by yet another repaint request for the same components, that supersedes the previous one. This is called "doing dangerous optimizations", and it will continue to bite computer programmers until the "never" day when computer speeds become infinite. FWIW xanthian. Free MagazinesGet 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 ...
|
Reply to this Message
|
 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.