in reply to Window Close / Process Termination Handler on Windows

This is sort of a weird idea and not a direct solution to your question and there are some issues to be dealt with however, in theory this kludge would work...

Since the problem occurs when closing the console window by the "x", make it impossible for the user to do that!
I am going partly from memory on this one, but if you start a Tk gui as a detached process (no console window), it is easy to intercept hitting the "x" on the gui window. There are a couple of ways: see Re: Catching WINDOW close event and take actions and from my memory any code right after Mainloop; executes after the "x" is clicked.

I had one GUI app where I implemented some code after Mainloop; to make sure all of the files were saved if the user clicked "x" instead of using the gui to "save and exit" - it is possible to restart the Mainloop. You don't need any fancy buttons...a simple text display widget would be enough. It is possible to have a routine run right after the Mainloop starts (no user "click" required), but I don't remember the exact way to do that.

On a different tack, why are the user's hitting the console "x" button in the first place?
In my experience that is because they think that the program is hung and because of that, closing the window won't matter.

See if you can just print a "dot", "." every so many work units. Do not have a separate timing routine that prints a dot every 3 seconds or whatever. The users will figure out that that is BS. Make each dot represent some unit of actual work performed. This typically will lead to a jerky timing of dots and the users trust that more than some kind of regularly timed dots. Maximum user patience is somewhat south of 90 seconds.

It is also possible that your program shouldn't even have a constantly displayed UI! In Unix lingo this is a daemon, in Windows lingo this is service. If your command line program is just a monitor for this continuously running process, closing it would have no effect upon the underlying process.

  • Comment on Re: Window Close / Process Termination Handler on Windows

Replies are listed 'Best First'.
Re^2: Window Close / Process Termination Handler on Windows
by rminner (Chaplain) on Aug 29, 2018 at 21:28 UTC
    Hello Marshall,

    Replacing the console window with a gui window would indeed solve the problem. Another solution would be to convert it into a daemon and writing a gui client to display the status messages.

    The reason why i am not doing any of this is, that the program itself is an interim kludge for a closed source CTI (computer telephony interface) program which is used in a hotline. The hotline software fails to display basic things which one would expect of such a software, such as who is logged in, what their status is, what the call statistics are (SLA), and so on. The kludge which i quickly whipped up a few year ago, is a simple tcp proxy reading the communication between the client and the server presenting the information above through printing it to the console whenever there is any change. There is no user interaction, it just displays the infos, and it updates frequently. The users do not get the impression of it being hung.

    Then why did i want to add a handler for program termination? When a user is done, they will close the windows. So far so good. If they close however the tcp proxy before the client programm, then the logoff in the client programm will never reach the server, because the tcp proxy is down. With the given cti server software the hotline agent will still be active and receive call, thus causing failed call counts to go up. Reason being that an explicit logoff is required to be removed from the hotline rotation. My intent was to inject the logoff message into the tcp stream whenever the simple tcp proxy is closed, thus eliminating the problem. But for that i would have needed a working "close" or "destroy" handler.

    Since this software is supposed to be retired soon, there is no point in investing time into a major rewrite. I would have just added the logoff, if there would have been an easy way to call it upon window destruction. If i started converting that quick and dirty kludge to a gui application, then i could immediately write a new GUI client for the CTI software, since i know enough about the protocol to do so. This would also eliminate the need for a tcp proxy. Considering however that it is a soon to be retired application with a small user base, i can not justify putting that much time into it.
      Thanks for your reply.
      I see that you understood my suggestions and I see why they aren't appropriate for this specific situation.

      I saw a post suggesting using the Window "START" command in a .bat file. There might be some way to use that to solve your problem. I don't know at the moment.

      However now that the Monks know more about what you are doing, there is an increased likelihood of a simple solution, perhaps not a general solution, but a solution that will solve your specific problem.