>Hi,
>I have designed a generic form WAIT that consists of nothing but a
>progress bar and a Cancel button. The borderstyle is set to
>bsDialog and things typical of a modal form. WAIT is generic
>in nature used to inform users of any long process that the
>application's current form/window is doing.
>Say I have a form MAIN which needs to do quite a bit of
>processing. All the logic to do the job is found in the
>calling form; WAIT is simply updated from the caller
>periodically to inform the user of the progress.
>Here is the problem. If I activate WAIT with SHOWMODAL(),
>it will stay modal until the user clicks OK to put it away.
>Hence the logic in the caller cannot continue - makes no
>sense right? <- Problem (1)
>If I use SHOW() instead, WAIT will come up and the caller
>can continue with its logic. However, the app will not respond
>to the user click (on WAIT's buttons) during this period until
>whatever the caller needs to do is finished. <- Problem (2)
>I solved this problem [partially actually] by inserting
>Application.ProcessMessages() in the caller's logic. By
>doing this, the supposing "modal-like" WAIT form behaves like
>a normal modeless form, responding to user click where
>appropriate. However, this caused another diaster - the WAIT
>form can end up buried under the caller form or some
>other windows. <- Problem (3)
>I heard that callback function or something may solve my problem.
>However, it seems to be tied very much to DLL programming, which
>I do not use at this point of time.
>Any suggestions or ideas? I am sure there is a proper way to
>do this. The only way I can think of is to design different
>WAIT forms for different windows - not elegant but it should work.
>Seems to defeat the purpose of code-sharing though.
>Appreciate any help in advance. Replies to forum and cc:
>to email greatly appreciated.
>Regards,
>DL
>8.19.96
>d...@pacific.net.sg
