I went about trying to consolidate the only code that is needed, but it is a huge task to do. In the process I did minimize the code and managed to get the exception on JDK1.7.0_25 too, so I think this is a normal exception (normal for JDK 7 anyway) from trying to shutdown the program to quickly without adding extra code to make sure it doesn't happen. It's just a matter of timing.
I have a little application that has a Swing form and text area. I open a file and I press a button that does a search on the text by doing a string search on the text in a List. The work of searching is done in a SingleThreadExecutor and puts the start and end indexes of each word found in a List. Then I do an InvokeAndWait and send the index List into the EDT and it uses it to paint highlighting on the words.
If I open a big text file, click the button to highlight the words, then clear and click the button again, as soon as the words are highlighted and I click the red X on the Form to close the application I get:
This is repeatable and only happens on the 2nd time I perform the highlight routine. It never happens the 1st time or the 3rd time and so forth.
The check for a null border is not needed in my case. What it does is still detects a border, it is never null, even though I do not add one it still creates a compound border. This over pads the cell plus it causes a very thin dotted line to show around a cell when it is selected. So all I need is this code:
It works on all the available L&F in NetBeans. I just added it to the form through the custom code properties, pre-adding for the JLabel (Lines 28-45), although I could add it in my controller. I see how it adds the border to the cell and no matter if I add it before or after adding a border to the JList, the code takes that into account. But in my case I don't need the border on the JList. Thanks again.
Although I am using the free design in NetBeans, I generated the simplest case with a null layout and it behaves the same. This is the Windows L&F, but it does the same with Metal, Nimbus L&F.
I have been looking for a reason for this to no avail. I have a JList with an EmptyBorder (for some margin). It is in a JScrollPane. When there is a list entry that is wider than the viewport, I can click on the JList and if I move the mouse cursor any when clicking, the JList scrolls to the left, the width of the border, putting the text up next to the edge of the viewport again. This is rather annoying as it defeats the purpose of using the EmptyBorder for margin.
If I am making a request to read a value in a JTextField using tthe AWT Event Queue and storing it in a local variable, the value is not immediately available. I have to wait somehow to know it has been written from the Even Dispatch Thread to the local variable before using it in another thread. I am not sure how to synchronize this. Does anyone have a tip to point me in the right direction?
I am going through a list of words in the background thread and using regex to match all cases in a text file of the words, then highlighting them. It is very inefficient for this I know (O(n^2) ), and it takes about 30 or 40 seconds to do a text file the size of a book like "Through the Looking Glass", but for now I am doing it this way and then I will switch to using a hash table and my own string matching so it is fast. Anyway, as I match the words, I update a counter and I update an ArrayList that holds the indexes for the highlighting. When done, I invoke the AWT Event Queue with a worker that updates the Swing form with the count and paints the highlighting on the JTextArea text using the index ArrayList for each start and stop point.
I was thinking of using 2 lists, but I think just synchronizing the 2 read & write methods is efficient. I actually don't even need the executor and I have no NPEs if I just synchronize the 2 methods for now. I may get into a situation later where I want to make a copy.
I wonder if I should use Collections.synchronizedList instead of synchronizing the methods that access the ArrayList? Is there a performance difference?
It works, but I still had to synchronize some methods to prevent the same NPE, but what I have is that each SingleThreadExecutor thread invokes the AWT Event Queue with a new runnable that access the same ArrayList to read values as the SingleThreadExecutor thread, which it is invoked from, writes too.
So it appears as soon as the SingleThreadExecutor calls the AWT Event Queue, which is the last call in the thread, the thread is considered done. I wasn't taking that into consideration.
I have an object that implements Runnable and I create a new thread with this object by pressing a button on my Swing form. The thread does some stuff in the background and then updates my Swing form through the AWT Event Queue. I don't ever need to create multiple threads that run simultaneously, only one at a time. If I click the button multiple times very fast it will of course create multiple threads and it causes some problems with unsynchronized updates. So I am thinking I can lock the button and wait for the thread to finish before it can be pressed again or prevent new threads from being created until the previous ones are done.
I really don't need to created multiple threads that wait for one another, so locking the button would be fine.
Should I implement both in case later I don't want to lock the button? Is locking a button acceptable or is it bad programming practice?
Ranch Hand Scavenger Hunt
Number Posts (88/100)
Set bumper stickers in profile (3/3)