in reply to Detect Stop Button

sure it's possible in some situations.

If you have a script, to which a user is posting a form, and the content-size (or whatever) header says the user is posting 10k, but only 5k gets transmitted, chances are the user hit the stop button.

That is the only way I see you detecting the user pressing a stop button.

If you're using CGI.pm, you'll probably want to slap the code to check for this in a BEGIN block, and read off STDIN yourself.

You probably want to describe better what your script is doing, as there might be other (fork fork) strategies you'd be better suited taking when approaching your particular problem.

 
___crazyinsomniac_______________________________________
Disclaimer: Don't blame. It came from inside the void
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

  • Comment on (crazyinsomniac) Re: Detect Stop Button

Replies are listed 'Best First'.
Re: (crazyinsomniac) Re: Detect Stop Button
by hakkr (Chaplain) on Nov 26, 2001 at 19:58 UTC
    My script is writing a bunch of html files to disk created from Mysql searches. It only perfoms the searches and writes the files if it recieves all the form data.
    Thanks anyway I'll try and be more detailed in future.
[reply]

      Perhaps another approach may work. Depending upon your application, you may want to provide a mechanism for the user to stop the process:

      In your script, create a session key (incorporating the process ID and perhaps hostname of the running script, for example) and store it in a cookie. Before the "meat" of the script begins ("...writing a bunch of html files to disk created from Mysql searches..."), write out some HTML containing a button or a link which when clicked, launches a second script which uses the value in the cookie to identify the first script's process and kills it.

      I realize this is not the solution you asked for. As you can see from the other responses, due to the asynchronous natture of HTTP discourse, there is no completely reliable way to detect browser disconnection.

      Pressing Stop itself is not even reliable: I've seen circumstances with Internet Explorer (v5.5 SP2) where clicking Stop (or hitting Esc) had no immediate effect -- the spinning globe just kept spinning. I haven't made a study of the prevailing conditions at the time, but invariably the browser was waiting for some object or another (i.e., image or ad) to load.

      Perhaps offering users an alternative to waiting might be attractive enough that they'll prefer it over simply browsing away from your results page. This approach won't prevent users from hitting Stop or browsing away from your page, but it might cut down the number of instances of it.

      dmm

[reply]
        FYI, most instances I've seen of IE not stopping when you tell it to are JavaScript image loads. It's especially annoying on sloooooooow sites with lots of rollovers.
        --
        man with no legs, inc.
[reply]
      Reply from thread below: My script runs for about 1 hr so I had set my Apache TimeOut variable to a huge value (3600). This seems to work for most browsers. I think I'll try your idea of printing blank chars to STDOUT instead. The TimeOut variable effects all requests and probably leaves me with lots of Apache children hanging around

      Okay, so let me make sure I'm clear on this. You have a CGI script which runs for almost one hour. This cgi script creates a number of static html files to represent results from MySQL searches? Is the user expected to hang around for an hour to view the resulting html pages?

      It sounds like you *really* should be taking in the form information, verifying that you have all the form data, then writing this form data to a file. Then, a cron script should run every so often to see if any form data files exist, and process them accordingly. Then, the cron script could send the user an e-mail upon completion.

      By verifying your form data way before the script even runs, you will save those times where someone says "Oh shoot, I mistyped this field.. let me go back." You also can more appropriately schedule the running of this one hour script to not choke up your system.

      Besides, I can't think of ANY reason that a cgi script should run for longer than 5 minutes or so, and even that is quite silly. No one is going to watch the output for a whole hour, so you might as well e-mail them when it's done.
[reply]
        I think you're making too many assumptions about the user. If it's an "in house" type of "admin tool", it could be some kind of reporting tool so that a manager doesn't have to know how to make MySQL queries. For example, maybe they only need the information on demand about every other month, so it would be wasteful to have a cron job doing an hour of processing every day. You might think just run a command, but some people don't have any idea what that really means, and developers get tired of being command-line (and MySQL :) monkeys.
[reply]

In Section Seekers of Perl Wisdom