These examples are all good... but a basic point is being missed. In these examples, the AddItem sub{} is controlling when the 'Working' message window is to be destroyed. The real problem is that the... 'activity'... that's going on that needs to be monitored is running *outside* of the context of the current process. This means the 'mainline' Perl/Tk program doesn't know when the 'activity' is terminated.

As I understand it, when MainLoop is called, everything is basically 'sitting still' until (in this case) a 'button press event' happens. When that event comes from the 'Pop It!' button, the AddItem sub{} is called, which creates a new window that shows a 'Working' message. Effectively at the same time, a new process is spawned... and everything in the current process goes back to 'sleep', until another event occurs.

The 'full and complete' way to do what I want would be to use Win32::Process::Create(...$cmd...) and set-up something with signals... and when the spawned process terminates, if would issue a signal to its parent process -- that would be the 'event' that is trapped and the 'Working' message window would be destroyed.

...but I'm trying to shortcut all that work somehow (I don't even know if such a thing is possible, although I would expect it would be)... and I'm not sure how to do it. In 'normal' (non-event-driven programming), simply including 'system($cmd)' in the code would mean the main program would pause, the system() task would complete and control would be returned to the main program again... but this doesn't happen here.

Perhaps the simplest way is to forget about spawning another process and just include the code from the command -line version I have into the Tk version -- Ugh. More maintenance dramas...

John