Re: bug 96 (Re: [Audacity-devel] 1.2.0?)

[Vaughan J. <vjo...@co...>]

Thanks for the clarification, Markus.

1. Yes, that's how I hoped Windows file type association with DDE works. 
I didn't know, but you're right about how it starts the .exe. I was 
postulating hopefully (unwise, I know) that it used the same mechanism, 
but with no file-to-open parameter. That is, if Windows Explorer can use 
DDE to determine to send the message to the running process rather than 
starting a new one, it could do it in either file-open or exe-open case. 
But it doesn't.

Actually, as far as I know, for file-open, Excel might do concept #2, 
starts a second process that passes the file-open parameter to the first 
one, then exits. As you wrote, the user wouldn't see the second process 
at all. Doing an Excel file-open with Task Manager open, it just shows 
one Excel process and multiple "applications", but the second process 
could exist so briefly that Task Manager doesn't show it. I just checked 
the exe-open though, and it actually starts another Excel process with 
its single new spreadsheet "application". So, that confirms what you 
wrote about exe-open being different.


2. Yes, I understood that mechanism the first time, although I think 
something can always go wrong, no matter how well-implemented. ;-)      

We already have the check for the already-running process, using 
wxSingleInstanceChecker, so of course I wasn't concerned about running 
two Audacity processes, as long as the second one doesn't actually do 
anything substantive and step on the first one's data. So, I agree that 
concept #2 is the way to go. (After 1.2.0.)

All platforms use that wxSingleInstanceChecker code, but do they follow 
the same sort of startup procedure, i.e., always try to create a new 
process? Sorry, I don't know Linux or Mac well enough.


-Vaughan



Markus Meyer wrote:

>Vaughan,
>
>without trying to intermix my comments this time, just a few remarks,
>because I feel I wasn't able to point this out correctly before. Sorry
>for that.
>
>I believe we're talking about two different concepts here.
>
>1. The "shell verbs" method. Using this method, a program implements a
>DDE server (could do this using wxServer e.g., but can be native, since
>it really is only important on Windows). Whenever the shell wants to
>open an .AUP file, it looks into the HKEY_CLASSES_ROOT key, finds the
>extension, the file class and finally the shell verb description. It
>then looks if already a "Audacity" process is started, if no, it starts
>it. Then it sends the "open" command to the Audacity DDE server.
>
>I could be wrong, but IIRC the shell verbs stuff is only respected in
>the following cases:
>- When an .AUP file is opened. When "audacity.exe" is double-clicked (or
>the program is started from the start menu), the shell verb doesn't have
>any effect, because it is tied to the file extension.
>- When a program uses the ShellExecute function (rather than
>CreateProcess or WinExec). The shell (i.e. the Windows Explorer) uses
>this function, but other programs may not.
>
>2. The IPC solution. This works like the following: The first thing each
>Audacity process does is to see if there is another Audacity process
>running. It does this by trying to open some connection to an already
>opened Audacity process (of the same user). If it is, the second process
>sends a message to the first process saying "open this file", then
>immediately quits. Note that if properly implemented this _cannot_ go
>wrong. There is no inherent problem with having the same program open
>more than once on any operating system. The problems begin when
>temporary files or preferences are opened etc. Needless to say that a
>proper implementation would do the second-process-check _before_ any
>ressources are opened, so it would be safe.
>
>Note:
>- For each solution you'd have to implement some "server" (for the
>shell-verb-message or the internal message).
>- Solution (2) will work on all platforms automatically. Furthermore,
>the user won't even see that there isn't really a second Audacity
>process started when implemented properly (apart from that the shell on
>*nix will return immediately, even if not started with the '&' sign).
>
>Hope I was able to make things a bit clearer.
>
>
>Markus
>  
>
>  
>