#1
  1. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2002
    Location
    Bay Area California
    Posts
    371
    Rep Power
    19

    How can I disable an <input type='image'> button?


    Hi all.

    This is prolly an easy one, but for the life of me, I can't figure this out.

    I have a slew of graphical buttons in an online app that submit forms for processing. I want to be able to disable the button clicked on (until after the POST) to ensure the user doesn't keep clicking the submit button. Here is the code for the submit button.
    PHP Code:
    <input id='submitme' type='image' 
    name='button4' src='../../images/btn_gen_rpt.gif'
    onclick='J_try_submit();' /> 
    I added the ID tag to see if I could disable the input field with the following little JS function:
    PHP Code:
        function J_try_submit() {
            
    //document.jkform.getElementById("submitme").disabled = true;
            
    document.jkform.button4.disabled true;
            
    document.jkform.action.value 'run';
            
    document.jkform.submit();
        } 
    Unfortunately, the first line in the JS is throwing a "undefined - not an object" error, so the button does not get disabled (tried both with name and ID). This little JS function works fine when I use a standard <input type='submit'...> but not with the type = "image".

    Anyone know how to disable an Imput Image type field?
  2. #2
  3. garish grotesque gargoyle
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2006
    Location
    gracing gargantuan gothic gateways
    Posts
    1,323
    Rep Power
    0
    image inputs don't get disabled the right way (obviously).

    another method is to throw a 'submitted' flag - this is how I disable double-posts on sensitive forms. try:

    Javascript Code:
    var submittedAlready = false;
    function trySubmit() {
      if(submittedAlready) {
        return false;
      } else {
        submittedAlready = true;
        // if you need to set any additional form params, 
        // or do any other work before submitting, do it here
        return true;
      }
    }


    then on your image input, the onclick should just be onclick="return trySubmit();"

    if you return false from an onclick event, it's as though the thing was never clicked. This way, if you want a submit button (image or otherwise) to be disabled, you can just make sure that an onclick returns false - this will stop the form submission action.

    Hope this is what you're after... if you need any clarification, just ask

    HTH - derelict
  4. #3
  5. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2002
    Location
    Bay Area California
    Posts
    371
    Rep Power
    19
    derelict, thanks for the tips. Everything you posted worked great, however I still have a problem. Because I don't actually ever return back to the current script (the POST goes to a report page), the current script is never truly refreshed and the value of submittedAlready stays set to true!

    There may not be a way for me to disable and then re-enable this submit without re-posting my current page :-(, which doesn't really work in the grand scheme of things.

    Thanks for the help though!
  6. #4
  7. garish grotesque gargoyle
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2006
    Location
    gracing gargantuan gothic gateways
    Posts
    1,323
    Rep Power
    0
    so, I guess I'm missing something here... are you trying to use the 'back' button to return to your submit form and re-submit? or are there multiple buttons to use for submission? I guess I'm not understanding why it would matter if submittedAlready stayed true -- seems like this is the desired functionality, to keep the form from being submitted again...

    If there are multiple buttons to post from, you need a separate flag for each, and check that flag upon pressing that button.

    if you're using the 'back' button, you can either have a 'reset' button to clear the submitted flag or try making a link on the response page so going back is done via a new http request rather than returning to the cached (and already-javascript-modified) browser version...

    can you give me a little more detail? I'm sure there's a solution, just not quite getting what the application is.

    HTH - derelict
  8. #5
  9. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2002
    Location
    Bay Area California
    Posts
    371
    Rep Power
    19
    derelict,

    The flow is like this.

    There is a PHP page that allows users to submit a report with a variety of different selection and printing options. The report page has multiple buttons. All buttons submit the page to process settings and report options, but only one button submits the page, verifies settings, and then does another "forced POST" via JS to the actual report script (passing along all the report options).

    Since the Run Report button posts to another script (which generates a PDF) there is no simple way for me to tell when that script is complete so I can then unlock the submit button so the user can run another variation of the same report.

    The worst that can happen is that the report is submitted several times (each successive POST cancelling the prior) using up some system resources. The PDF report itself is only generated once.

    I was trying to avoid confusion from the user more than anything, since repeatedly clicking the Run Report button starts the submit over and the report itself can take 3 seconds to 4 minutes depending on the amount of data processed.

    Confusing huh, ha ha?
  10. #6
  11. garish grotesque gargoyle
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2006
    Location
    gracing gargantuan gothic gateways
    Posts
    1,323
    Rep Power
    0
    is the PDF bieng generated in a popup called by the first script?

    when you say 'all the buttons submit the form' this implies to me that it causes a page reload -- which should clear any js vars floating around... are you using some remoting for this to stay on the page, or am I still missing something (well, I'm missing a lot of things; this may be one of them)?

    if the PDF is generated in a popup, the solution ranges from trivial to somewhat complex depending on if the PDF script generates just the PDF with a matching content type or an HTML container page.

    if the PDF is in a popup generated by the first script, and it's in an HTML container page, you could always do something like:

    onload = function() {
    opener.submittedAlready = false;
    }

    in the popup page code. or you could guesstimate and set a timeout of 10 seconds before re-enabling the button (setting the timeout in the trySubmit function).

    Can we give this one more go with an explaination of what actions cause new windows or page refreshes, and how the report page is laid out? I guarantee there's a solution, however hackish, and I always like a challenge...

    HTH - derelict
  12. #7
  13. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2002
    Location
    Bay Area California
    Posts
    371
    Rep Power
    19
    derelict, excellent comments and thoughts again - kudos!

    Since all buttons refresh the page, they do indeed allow the JS var "alreadySubmitted" to set back to false, but since the form itself is so fast (way before the PDF generates), I decided this wouldn't accomplish anything.

    I indeed am doing some tricky things with this script that make it harder to deal with. Our code does not generate a new window when generating a PDF. I always hated those extra windows. The PDF is sent directly to Acrobat upon completion by the other called script. This was designed, again, to be less confusing to our customers who get lost when too many windows atart appearing.

    You are right that it would be easy to examine another window's state if the PDF were in a pop-up, but alas we cannot go this route.

    It's funny you should mention the timer. I was thinking the same thing. I may be able to use a simple 5-second timer in the calling script, just to ensure no double-clicks or extra clicks in the first few seconds.

    Thanks again for the great ideas!
  14. #8
  15. garish grotesque gargoyle
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Mar 2006
    Location
    gracing gargantuan gothic gateways
    Posts
    1,323
    Rep Power
    0
    so what happens when the other script completes? how does the PDF get sent directly to adobe?

    another method makes the server do the work... if you're keeping a log of report prints in a db it should be pretty easy...

    You simply start the report print record before showing the report page, and use the print ID as a form var in the report page.
    Add a status field to your report log, and initialize it to 'ready'.
    When you submit the request for PDF generation, check this flag based on the print ID and only run the generator if the flag is 'ready'.
    When you start the generation, set the flag to 'running', and when it completes, set it back to 'ready'.

    You can also do fun things like track the number of times the report was modified and prepared... even deny the user ability to prepare more than X times, etc.

    then you kill any disabling code on the front end... you may be sending multiple submits, but your server's only doing the hard work once at a time.

    This may work if nothing else does... but I'm still not conviced it can't be done on the front end. Lemme know!

    HTH - derelict

IMN logo majestic logo threadwatch logo seochat tools logo