Hello Everybody!!

I'm looking for any techniques which will keep a submit disabled until a report (pdf, html, excel) renders in a new page..

We have this requirement to prevent users from re-clicking, especially on long-running reports.


Additionally, this is implemented in HTML forrms created in WF8 HTML composer...

At this point..

1. I believe I can get the button disabled on the clickEvent (button click)..(by using the document.getElementById("btnRun").disabled = true)

2. When the called fex has this HTMLFORM BEGIN/END and the output is PDF..then

a. if it is at the top of the fex..the PDF does not render correctly ..it presents the output as markup language...not PDF)..like this:

%PDF-1.4 6 0 obj << /Length 7 0 R >> stream BT /F1 1 Tf ET /GS1 gs 0 Tc 0 Tw 0 0 0 rg 0 0 0 RG 0 J 0 j 10.000000 w 10 M []0 d 1 i q 0.050000 0 0 0.050000 0 0 cm BT /F1 1 Tf 240 0 0 240 360 15280 Tm (PAGE )Tj 240 0 0 240 1224 15280 Tm ( 1)Tj 240 0 0 240 360 14680 Tm (MODEL)Tj ET 0.00 0.00 0.00 RG 360 14560 m 1080 14560 l S BT 240 0 0 240

b. if it is at the end of the fex (after the PDF)....it is not invoked at all.

TABLE FILE CAR
PRINT MODEL
ON TABLE PCHOLD FORMAT PDF
END
-RUN


-SET &NUM_REC = &RECORDS;
-HTMLFORM BEGIN
<script language="javascript">


setTimeout(resetForm(), 10000);

function resetForm() {
return function(){

opener.document.getElementById("btnRun").disabled = false;
opener.document.getElementById("btnRun").value = "go";
opener.document.getElementById("txtTitle").innerHTML = "finsihed '" + &NUM_REC + "'";
}
} //end fcn



-HTMLFORM END

3. There is "Wait for completion..." request/action..but I'm not how it works..nor if it is integrated w/ a page opening in a 2nd window.

Any insights would be greatly appreciated.

Wm

This message has been edited. Last edited by: <Emily McAllister>,

There is an onbeforeunload event that you could use on your destination window -- the window that opens with the report in it. That event executes when you close that window.

It's not perfect though, because someone could close the window prior to completion and start running a new report right away. But -- that might be something you want to offer them, because if they select the wrong parameter you don't want to force them to wait 20 minutes before they can run it again.

Option 2 is to have the report include a button in it that you can connect your opener.document logic to. That is, the user can only unlock the Submit button by clicking on something inside your final output, or having it go off on the output's onload event.

I'll be honest, a user with any moxie will figure out they can refresh the calling page and get their Submit button back. Or open a second copy. This will be a hard one to enforce with smart people.

Thanks John...

I agree w/ all you are saying.
the HTML composer has a 'wait for completion..' method..which works fine if the output is HTML.

If it is PDF or Excel..then that does not get invoked..and the button stays disabled.

From my perspective..the 'wait for completion' should be output type agnostic..and it doesn't seem to be.

The closest we've come is trying to get the users to select Run in New Window. We find they are less likely to hammer the Submit button. First because there is an indication that the report is still running and second because each submit opens a new window.

I've been looking into ways to make that setting the default, but I'm not sure yet.

Two days ago someone consumed all the WebFocus initiators using multiple Submits. This does not sit well with the other users. :-)

I believe there is room for a slight improvement here. (and I can put in a NFR)

That 'Wait for completion...' task (in the HTML composer) should be output agnostic. Since the xmlroot document is, I assume, communicating behind the scenes aleady with the client, then it should not be too much of a stretch to have it receive something/update something regardless of the output format..because, regardless of what is running ..it has to complete some how (normal end, agent killed, abend).

Any of those end events should tell the form that the process completed..and do its thing..

then..error conditions (ie non normal conditions could be handled one way..normal conditions another.

but..what do I know..

W,

What are your redirection settings? I know when I first upgraded to 8.0.08, I had to set my excel to always save on the server and then send the output. The reason I had to do this, was because in the default prompt popup, if I ran an excel report, I wouldn't get the run button back after submitting Excel requests. I don't know if this will help, but I would suggest seeing if this has an impact as I believe it might be the difference between sending a response call or not.

What we do (although only in a few cases) is disable the submit button until the target window fires its onload event.
In JQuery terms, those events are called 'submit' and 'ready'.

For that to work, you need to attach events to onsubmit in the launch page and to onload in the target window (attach the event handler from your launch page though and not from the target window!).

You might also want to catch form-validation errors and if those occur, not disable the submit button (or something like that - I'm not at all clear on the correct behaviour there).

Unfortunately, IBI made that a bit complicated... Until they implement our NFR for a return status in OnExecute, you can instead use the function replacement pattern that I shared around a week ago...