Stefan Küng <tortoisesvn_at_gmail.com
<mailto:tortoisesvn_at_gmail.com?Subject=Re:%20New%20functionality>>
wrote on Wed, 09 Dec 2009 19:46:27:
>
> /> (2) New "editfile" command. It is currently available via CL /
> /> only but will soon be added to the repobrowser. /
> /> /
> /> Synopsis: /
> /> * the given path may either be a URL or a path within a w/c /
> /> * if it is a URL, the item will be checked out to temp location /
> /> and will be deleted after the command finished. /
> /> * if the item is not locked but has svn:needs-lock set, the /
> /> lock will be acquired (asking the user for a lock comment, /
> /> if the TSVN or project settings require it). In the latter case, /
> /> it will released automatically at the end as well. /
> /> * the document gets opened with the associated application /
> /> (using Windows standard mechanism) /
>
> You're using CreateProcess() to start a console here. I think this is a
> little bit strange to use "cmd /c" for this kind of feature?
>
Isn't it ;) But you can't actually just specify the file name,
you need someone to trigger to lookup.
>
> I think it would be better to use ShellExecuteEx() and use the hProcess
> handle of the SHELLEXECUTEINFO struct. And when using ShellExecuteEx(),
> make sure you use the "edit" verb instead of the "open" verb. We don't
> want to execute e.g., *.js files but edit them here.
>
> Or you could read the registry yourself and find the editing app (with a
> fallback to the opening app) - see CAppUtils::StartTextViewer() for an
> example of this.
>
The current implementation does the latter. It also tries to
prevent scripts from being executed accidentally.
For enhanced symmetry, maybe we should use ShellExecute ("openas")
instead of the file open dialog here. Also, we may want to
replace the calls to ShellExecute elsewhere in TSVN with a
call to some CAppUtils method.
>
> /> * after closing that application, the changes will be committed /
> /> using the standard commit dialog. If nothing was changed, /
> /> the dialog will not show up. /
> /> * final cleanup when applicable: unlock and delete temp. w/c /
> /> /
> /> Question: /
> /> It's currently an orgy of flicking dialog boxes. With all the /
> /> "auto-close" and "no lock comment" options active no /
> /> clicking is required, though. Is there a way to hide the /
> /> progress dialog unless there is error? /
>
> You could introduce a new flag in the CSVNProgressDlg which forces a
> call to ShowWindow(SW_HIDE) if the flag is set. Then whenever an error
> or something important happens you have to call ShowWindow(SW_SHOW)
> again.
>
ShowWindow() seems not to work for modal dialogs.
The MFC itself uses SetWindowPos() and that works
- at least outside WM_INITDIALOG.
Although there is still some flicker (can't prevent the initial
drawing), it is clear to the user that there is no info being
shown that he or she needs to read.
-- Stefan^2.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2429669
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-11 04:16:31 CET