Program displays filenames in a JTextArea as it walks the directory tree but I don't know how to stop it via a keypress

Question

There are two windows: a GUI for user input and Output window for list of filenames found. Execution must be user-stoppable via a keypress and must leave both windows open because the program processes subdirectories, so it can run a long time, possibly stepping thru 100_000 files, either producing tons of output or none at all, depending on how user's filename pattern matches files encountered in the selected starting node.

Here's my question:

How do I look for a keypress (e.g., ESC or CTRL-C) to allow user to terminate? (Clicking red X isn't an option since that closes windows; user needs to see what's been found before termination. Doing so does not close either window anyway since all buttons are disabled once tree walk begins.)

I've tried putting keyListeners in several places, but once the "Start" button is clicked, all the swing components are disabled.

This seems like such a common situation that I'm surprised I can't find any textbook, thread, or Google info that directly answers the question. So I'm afraid it's not gonna be at all easy. That would be no surprise. I may have found a clue here but I can't get it to compile and the link contained there doesn't lead to that code snippet.

The search begins when the Search button is clicked:

  private void jbSearchActionPerformed(ActionEvent evt) { 
     SearchyGUI.doIt();
  }                                        

The doIt() method walks the directory tree by an extension of SimplefileVisitor:

  public class OverriddenFileVisitor extends SimpleFileVisitor<Path> {
    ...
  }

  public static void doIt(){
    try {
      visitor = new OverriddenFileVisitor();
      info.setVisible(true);
      Files.walkFileTree(SearchyGUI.p , visitor);
    }
    catch (Exception e) {    }
  }   
}

Output is written to jTextArea1 via the report() method:

  public static void report(String s){
    Output.jTextArea1.append(s + "\n");
  }

This is done primarily in the visitFile() method of SimpleFileVisitor:

 public FileVisitResult visitFile(Path f, BasicFileAttributes a) throws IOException {
    report(foundkt + "--" + f.getFileName().toString());
    return FileVisitResult.CONTINUE;
  }

Here's the main class:

public class SearchyGUI {

  static Output info;
  static Path p ;
  static FileVisitor visitor ;
  static GUI gui 

public static void main(String args[]) {
    java.awt.EventQueue.invokeLater(new Runnable() {
      public void run() {
        gui = new GUI();
        gui.setVisible(true);
      }
    });

    java.awt.EventQueue.invokeLater(new Runnable() {
      public void run() {
        info = new Output();
      }
    });
  }

Answer 1

The Key Bindings API is probably the best choice for monitoring key strokes.

I would also add a [Cancel] button to the UI, which shared the same action...

public class CancelAction extends AbstractAction {
    public CancelAction() {
        putValue(NAME, "Cancel");
    }

    public void actionPerformed(ActionEvent evt) {
        // Perform the cancel operation...
    }
}

Then some where else in your code...

CancelAction cancelAction = new CancelAction();
JButton cancelButton = new JButton(cancelAction);
InputMap im = getInputMap(WHEN_IN_FOCUSED_WINDOW);
ActionMap am = getActionMap();

im.put(KeyStroke.getKeyStroke(KeyEvent.VK_ESCAPE, 0), "Cancel");
am.put("Cancel", am);

Now the other problem you're going to have is the fact that you look like you are running a long running task within the context of the Event Dispatching Thread. This is going to prevent your program from being able to update the UI or allow the user to interact with the UI.

If you need to make changes to the UI (ie, show the output of the file processing), you should try a SwingWorker.

The main reason being is that it allows you to execute the long running task in another thread, but provides the mechanism for re-syncing updates back to the EDT, where it is safe to make changes to the UI.

Take a look at Concurrency in Swing for more details.

Regardless of which direction you take, you're going to need to supply a reference to the object that is carrying out the task and provide some kind of "cancel" flag, which the "task" object will need to monitor

Answer 2

Well, I made it stop. I guess if you wander the woods long enough you'll find a gnome. I read Robin's hint last week and sort of gave up. Then I read some more and more. And then more. But Robin assured me that gnomes DO exist in these here woods!

The code I used was a modification of some I found for a MatLab/Java app. (Why'd I even look at it?? Best apparent Google hint.)

I made the "file visitor" (directory tree walker component) startable as a thread as Robin advised:

public class OverriddenFileVisitor extends SimpleFileVisitor<Path> implements Runnable{
// ................................................................^^^^^^^^^^^^^^^^^^^

In doIt() I made a couple of changes, moving the lines that process the directory to the now-runnable class and started the file visitor as its own thread in doIt():

public static void doIt(){
  try {
   new OverriddenFileVisitor().startTh();
                            //^^^^^^^^^^
   //(moved) Files.walkFileTree(SearchyGUI.p , visitor);

   ...

I added the new method in the previous line to OverriddenFileVisitor class: (This is the main part of the MatLab/Java code that made sense to me so I used and modified it.)

public void startTh() {
  Thread t = new Thread(this);
  t.start();
}

And I inserted the overridden run() method for the class:

public void run() {
  try {
    Files.walkFileTree(SearchyGUI.p , this); // Used to be in doIt().
  }
  catch (IOException ex) { }
}

It ran and gave correct results and stopped when I hit Exit button, which "became" enabled after revising the file visitor to run in its own thread, which is what @Robin Green was saying. I almost feel like I know what I've done.

P.S. Note that I already was able to get my output via invokeLater()--last several lines of original question.

It's not finished but it's much more satisfactory.

Answer 3

The way I had left this program last night was unsatisfactory since Exit resulted in user not being able to see the output so far displayed (it could be useful). So I established window listeners and used the close event to set a boolean aborted to true to prevent further output to the window, but the thread kept running, which led to intermittent problems if another search was started before the thread ended.

Here's how I fixed it.

The FileVisitor interface has 4 methods to implement to walk the tree--two for each file visited, two for each directory. Each returns a FileVisitResult which is normally FileVisitResult.CONTINUE. By changing the return value to FileVisitResult.TERMINATE in the file visitor thread, it terminates appropriately! That is, I set a flag that the thread could check and take appropriate action, which is exactly what @MadProgrammer suggested.

  public static FileVisitResult disposition = FileVisitResult.CONTINUE;
  ...
  private static void report(String s){
    if (! aborted)
      try{
        Output.jTextArea1.append(s + "\n");
      }
      catch (Exception e){ 
        aborted = true ; 
        disposition = FileVisitResult.TERMINATE;
      }
  }
  ...
  @Override
  public FileVisitResult visitFile(Path f, BasicFileAttributes a) throws IOException {
    f1 = new File(f.getParent().toString() + "\\" + f.getFileName().toString());
    long filesize = f1.length();
    report(f.getFileName().toString() + "\t found in " + f.getParent().toString());
    return disposition;
  }

I am one happy camper! Thank you BOTH for your ideas and input.

Answer 4

The problem is you are hogging the GUI thread, so the GUI thread can't process any events originating from the user.

You need to create a new Thread and do the work in there. Then, to display output from that thread, you can use SwingUtilities.invokeLater or something like that.