Olaf’s Thoughts About Development

When you send a file via WebApplication.SendFile(), then your form may be locked, thus unusable, after the file has been received. This articel explains the reason and how to avoid that.

Sending files with IntraWeb is very easy. Just place a button on
your form and attach the OnClick event:

Send Excel
file

procedure TIWForm7.ButtonSendClick(Sender:
TObject);
begin
  //Create a file
(Excel sheet, report PDF etc) on the fly and store it somewhere
 
//This also works with static files of course face="Courier New">
  WebApplication.SendFile(’c:\temp\test.xls’,
true);
end;

The first parameter is the location of the file (do not use relative paths,
esp. when running as ISAPI), the second one tells to send the file as
“attachment”. This will open a file dialog at the user’s browser:

The user now has the choice to save the file or to directly fire up the
associated application (Excel in this example). After that the current form of
your application will re-appear. Easy and works great!

There is a catch though:

After returning to the form your user won’t be able to click on any control -
the form is “dead”, it does not accept any user input anymore. If you read
through the docs or the FAQ (yes there is one ;-), you will find a hint, that
SendFile (and SendStream) do not work with LockOnSubmit. So you just have to set
LockOnSubmit to false on every form where you are going to send a file.
Easy!

This solution is annoying?

Yes, of course it is! Why do you have to disable some useless option, on
every form? Why can’t IntraWeb just do that for you automatically? To understand
the answer “IW can not do that automatically, and this option is ver useful”,
you have to understand what LockOnSubmit and its sister LockUntilLoad are
actually good for.

Click Happy Users

Click Happy Users are those who are impatient and start clicking into Web
forms while the form still loads or when it just submits back to the server.
This may produce unexpected errors, such as session timeouts. The user is in the
middle of something and just because he was a little too impatient, he might
loose his session in the worst case. This is very uncomfortable and
something you don’t expect from applications - even if they are running on
the web. 

To handle both situations IntraWeb activates an invisible “Lock” right when
you click on any button on your form (LockOnSubmit), and this Lock will be
disabled when the response finished rendering (LockUntilLoaded). This is very
effective and makes your application more robust.

When you send a file via WebApplication.SendFile(), then the Lock does not
get unlocked after the file has be received unfortunately. This is because the
browser does not fire any JavaScript event after the file has been received,
canceled or what ever. It just saves the file and the current form has no chance
to unlock the Lock which has been turned on when you clicked the button.
IntraWeb can also not predict that you are going to send a file in a button
click event, it’s already too late (the lock is already turned on), when
IntraWeb gets to the SendFile code.

Turning off this locking is not really an option because you will all this
“happy click” prevention.

The real solution

The solution is simple, but effective. Attach the following lines to the
button’s ScriptEvents property (only for buttons/links which are used
for sending files):

ReleaseLock();
GActivateLock=false;
return
true;

This is JavaScript code which will get executed before your button submits
back to the server and fires the Delphi OnClick event. It will turn off 
the lock only for this button, which will make your form respond as expected
after the file has been received.

Don’t forget the final “return true;” - if you omit that, then your
Delphi OnClick won’t be fired.

This entry was posted on Monday, November 13th, 2006 at 1:00 and is filed under Miscellaneous.You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.