Jacob
Jacob
Jacob Anawalt wrote:I'm sorry, so far the only code you have shared that helps me see what is going on has been your actionPerformed event, and even that, like the others, appears to rely on a lot of instance state. I can only guess what kinds of objects they are and how they are used.
What triggers actionPerformed? A single or a double click of the table row?
Who calls testContent and when?
Is testContent a member of PDFCheck? If not, of what class?
What class is errorMessage, StringBuilder?
I still think the key is to have PDFCheck.errorMessage contain only what you want based on the PDFDocument represented by the selected row.
Jacob
Jacob Anawalt wrote:Ah, that helps clear things up. So JTextArea errorMessage and whatever contentError is must also be static on PDFCheck. JScrollPane(PDFCheck.errorMessage) makes more sense now.
I still don't think the problem is that you parse all the PDF files on load for errors, but that you combine all those errors into one String on the errorMessage JTextArea. I don't think that your static members are helping you see through the design issues. I recommend having testContent return the content error String and an error message String each time it is called on a PDFDocument rather than into static class members that accumulate cruft and have to be reset.
It looks like you stick contentError or something like it into your ArrayList for the JTable. I'm not sure on this part because your screen shot shows more than just blank and "content" in the Error column. Maybe you could drop contentError completely.
You could either stick all of the error message into the ArrayList Error column and pull it back out later for your report, or keep the error messages in another collection, one per row or per PDFDocument with an error, to retrieve and fill a new JTextArea to throw in that new JScrollPane when you double-click a row and look up which row was selected with something like this:
Jacob
Jacob Anawalt wrote:One way to work around the long string issue would be to setCellRenderer with a custom renderer you extended from DefaultTableCellRenderer that would just print the first N characters, something like "My really long error messages" turns into "My really long..." via the renderer.
If you don't want that kind of text there, then keep putting contentError in and store the error message strings in a different container that you pull the values back out of.
Jacob
Jacob Anawalt wrote:It still looks like you're using global variables, that testContent is not returning values, and I don't know how you are holding and retrieving the correct row from the list of error messages.
I was thinking of something more like this quick & dirty pseudo code example:
See what I mean about a second container to store the error messages, and how I pull back out just that PDF's error message for the Error Report dialog?
Jacob
Jacob Anawalt wrote:It's hard for me as well, looking at the code with blinders on, guessing what is on either side of the snippets.
I'm working off the expectation that the most recently revealed snippet, where you add the row of PDFDocument info to data (PDFCheck.data?) looks something like this, merging what you have revealed to my pseudo code:
See how errorMessageArrayList error messages would be in parallel to data? So the index of the one (the same as the index to your JTable row, unless you're sorting or filtering - if so, adjust accordingly) is the same as the index to the other?
It looks like in your latest example you stuck all the error messages into the content error column and then you pull them out from the JTable to create a JTextArea with just that row's error messages. Is that working for you?
Jacob
Tom Hat wrote:This code snippet from your post is my "FileModel" class which put all the data in the JTable.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Tom Hat wrote:This code snippet from your post is my "FileModel" class which put all the data in the JTable.
Could I make a suggestion? I'm no GUI expert, so I certainly can't help you with the "nuts and bolts" like Jacob has; but it seems to me that you're getting bogged down in the procedural side of things - ie, "how do I code this?" - rather than having (or devising) a plan for what you want to do.
You've clearly done some of that work, but not (I suspect) enough - and if I'm wrong, I'm sure I'll be flamed by the GUI experts here.![]()
Your GUI should ONLY be concerned with display and "reaction" - nothing else - and it really shouldn't care whether you're displaying a PDF, pieces of a Google map, or a set of lottery numbers, or what you want to "do" with them once you've clicked some button or table entry.
That's the theory. I realise that the reality may be somewhat more troublesome; but in most cases it still holds true - a JTable contains "things to be displayed", and it shouldn't matter one whit what they are, or what you intend to do with them.
The problem is that GUis are incredibly verbose and "fiddly", so you tend to get distracted by all the interactions between the various visual (and pointer) components, at the expense of what it is you actually want to do.
My advice: StopCoding (←click) for a bit, and get back to that. Sometimes you can be too close to a problem.![]()
Winston
Jacob
On top of spaghetti all covered in cheese, there was this tiny ad:
Low Tech Laboratory
https://www.kickstarter.com/projects/paulwheaton/low-tech-0
|