how can I find out what processes are running as a result of the current one in java?

[zskillz]

here's the deal... I wrote a little program that opens one large file and then creates many little files out of it... it does not necessarily finish making those smaller files in the order that it started making them. (some may take longer then others to process).

I want to create a GUI for it that is temporarily disabled while those processes are still running so that the user doesn't try and run it again accidentally.

now I have never done something like this before, and i'm not really sure if the way that I'm thinking of is really the best or easiest way (so if not, then by all means, make some suggestions ) but here's what my plan is.

I want the user to start the process by pressing a button
i want the program to disable the use of that button until the process is finished.

I was thinking that the best way to do that was to check what "threads" (may be the wrong word) had spawned from the original thread (perhaps by checking the stack or something) and making sure that those completed before the GUI was allowed to return to it's usable state.

does this sound like the right way to go about doing this sort of thing? or am I looking at it all wrong. I'm sure it's a common issue, but I don't really know what to do!

thanks in advance,
-Z

[qball]

If what you want is:

Quote:

I want the user to start the process by pressing a button
i want the program to disable the use of that button until the process is finished.

Which is pretty common behavior, is actually accomplished fairly easily.

In GUI terms, the button has a clicked event. This is how you know the button was clicked. This event will contain the code to do what you want the button to do. The button also has an enabled/disabled property. Enabled means you can click the button, disabled means you can't.

So simply, the event code for clicked will look like this:

//user no clickey
this.enabled = false;
//...
your code
//...
//user can clickey
this.enabled = true;

That's the GUI way. As this is the nature of buttons.

So, no matter what GUI you use, java, VB, PB, Javascript, whatever..., it is basically going to work this way.

With java, there basically exist 2 GUI frameworks. AWT Abstract window toolkit, and Swing. Either way, you'll get the buttons to behave as desired, by just doing the above.

[strangerstill]

Hmm... how are you planning to spawn the child threads?

I tend to use SwingWorker: http://java.sun.com/docs/books/tutor...ml#SwingWorker
in your case, what I would do is something like their IconDemoApplet:

private void processFile(final String filePath, final int index) {
    final SwingWorker worker = new SwingWorker() {

        public Object construct() {
            // do stuff;
            return; //return value not used by this program
        }

        //Runs on the event-dispatching thread.
        public void finished() {
            markFileDone(index);
        }
    };
    worker.start();  //required for SwingWorker 3
}

markFileDone would then be a method elsewhere in the enclosing class which would set a boolean in an array, and when the whole array is set to true i.e. all files have been processed, it will re-enable the button.

[zskillz]

yes... that class is exactly what I'm looking for strangerstill....

however, i then have a question about the whole array thing. I'm not sure why I would bother doing all that if I could just do something like check the stack and see if any threads that were spawned off of the primary thread are still running.

wouldn't that be an easier way to do it?

-Z

[zskillz]

wellwellwell... i have an update...

apparently whatever i am doing, it is not threading.... I just wasn't testing it on a big enough information set.

so... here's the update.... my problem seems to have solved itself... the GUI just sort of freezes until the process is finished anyway!

wierd. now I'm positive that I don't understand threads.

-Z

[strangerstill]

hmm, I'm not sure I do either.
looking at the API again, it seems what you'd want to do is to create a ThreadGroup and then create a bunch of Threads bound to that ThreadGroup, then you can use ThreadGroup.activeCount() to find how many threads are still running.

The way it seems to me, in Java you do need to explicitly tell the VM to generate threads otherwise all you have is the event-dispatching thread, if you run long operations in that you will lock up your GUI till it returns.

now it might be what you want in this case to have the GUI suspended till the method returns but that's not very nice on the end user, for instance the window will be unable to redraw and you won't be able to provide any feedback on how the operation is going, or even provide a 'cancel' interface - remember that time spent not knowing what's going on or how to do anything about it feels five times as long as time spent watching a progress bar! truth!

[zskillz]

hha! funny that you mention it though, but I have spent some of this morning trying to implement a progress bar for the process!

I am however interested in the threadgroup stuff!!! that is some interesting reading and I'll see what I can get from it.

-Z