Stefan Küng wrote:
> Roger Lipscombe wrote:
>> I'm looking into changing the way that hook scripts run, so that they
>> don't block the UI. The issue tracker hook script is the most obvious
>> example of this problem. I'm planning on having a dialog box pop up
>> while the hook is running. It would contain text, something like
>> "Please wait while the Issue Tracker hook runs".
>>
>> It might contain a "Cancel" button, which wouldn't kill the script
>> (that's relatively hard), but it would abort the wait, and would
>> return to the calling dialog as if the script failed. I'll have to
>> think a little bit about how the background thread would be
>> "garbage-collected" later -- we don't want TortoiseProc instances
>> hanging around because the hook script is still running somewhere.
>>
>> (My model is the "Wait"/"Switch To"/"Cancel" dialog that you see when
>> an OLE server is blocking).
>>
>> I'm thinking that it might work something like the attached (if you
>> don't see any attached, let me know and I'll upload it somewhere).
>> The interesting bits are in CModalStateDlg::OnBnClickedButton1() and
>> CWaitForAsyncOperationDialog.
>>
>> This pattern generally works pretty well. I've used it in the past.
>>
>> Where I'm a little unsure is where to attach this to TortoiseProc. I
>> could implement it in CCommitDlg::OnBnClickedBugtextbutton, or I
>> could put it in CHooks::RunScript. That might require that RunScript
>> be passed an hWnd to parent to. Currently, CHooks doesn't have much
>> in the way of UI knowledge, and I'm reluctant to change that.
>>
>> Thoughts or comments?
>
> I tried your demo project. Seems to work. But: closing the 'please
> wait' dialog and then closing the main dialog leads to a crash because
> the thread executing the 'script' is still running and of course isn't
> shut down correctly.
>
That's not a huge problem to deal with: either prevent the 'wait' dialog
from being closed until the thread exits, or just abandon the thread. I
didn't do that in the demo project. It requires a little bit of finesse
to ensure that the thread is cleaned up eventually, but it's not a big
problem.
> Maybe registering a window message which the script can send back to
> the commit dialog with info once its finished could help. Such
> messages can be sent even by other processes, so it would be possible
> to start the script as a different process - that way the commit
> dialog doesn't have to care about a thread still running.
>
This won't work for hook scripts that can't send registered window
messages (e.g. VBScript).
The background thread thing is a relatively easy fix: in RunScript,
where we're waiting for the process to exit, simply add another handle,
hAbandon. Closing the 'wait' dialog sets this handle and waits for the
thread to finish. This will let the process continue to run happily; we
just won't care about it. OK, the output is still redirected to
temporary files, which we won't have a chance to clean up, but we could
redirect to pipes instead.
Alternatively, if you do want to use registered window messages, we
could spawn another instance of TortoiseProc to host the hook script,
and it could post the messages back. I'd prefer a different
TortoiseHookRunner.exe, but that complicates the
build/package/installation story.
Let me know your thoughts and then I'll press on with an implementation...
Cheers,
Roger.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-04-22 07:54:31 CEST