Re: bug 96 (Re: [Audacity-devel] 1.2.0?)
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Markus M. <me...@me...> - 2003-12-15 00:59:00
|
You go to this address: https://lists.sourceforge.net/lists/listinfo/audacity-devel Then enter your email adress at the bottom and click on "Edit options" Markus Am Mon, den 15.12.2003 schrieb Kimberly Chicchi um 01:55: > Who do I contact to be removed from this list? > > Markus Meyer <me...@me...> 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 > > > Am Mon, den 15.12.2003 schrieb Vaughan Johnson um 00:30: > > Markus Meyer wrote: > > > > >Vaughan, > > > > > >Am Fre, den 12.12.2003 schrieb Vaughan Johnson um 20:56: > > > > > > > > >>Right. That's the basis of this discussion, allowing only > one Audacity > > >>process at a time. The bug is about how, when you > double-click a .AUP > > >>file on Windows, Windows starts a new process rather than > using the > > >>currently running Audacity process. How do we make Windows > not do that & > > >>do what we want? > > >> > > >> > > > > > >I don't think the (short) existence of a second process is > the problem > > >as long as the process terminates without doing any > conflicting work. > > > > > > > True, but if we can just talk to the already-running one > instead, that's > > probably cleaner, & has fewer pieces to go wrong. > > > > > > > > > > > > > >>Up until yesterday, Audacity gave the user the choice of > going ahead > > >>with the second process, after a warning about possible > crash & data > > >>loss. As of yesterday, that's now an error alert that says > how to work > > >>around the problem (give the Open command in the > already-running > > >>process), and exits the second process after the user > clicks OK -- no > > >>more choice to go ahead with the second process. > > >> > > >> > > > > > >That's a good workaround. I haven't checked this on Linux, > but I think > > >we should prevent the start of a second process per user on > _all_ > > >platforms, just in case. I don't think it will annoy Linux > users too > > >much (they know the behaviour from Mozilla etc., plus they > don't use > > >things like the Windows Explorer so much I believe), and it > will prevent > > >subtle, hard to track down error reports from users. I > don't know for > > >the Mac people, though. > > > > > > > Sorry I wasn't clear. The code I changed is for all > platforms, at the > > beginning of AudacityApp::OnInit(). > > > > > > > > > > > > > > > >>>I have not looked at Otto's fix, but the correct solution > would be to > > >>>send a message to the already running instance, asking it > to open the > > >>>specified file (or a new file, if the Audacity process > was started > > >>>without a parameter), then immediately exit the second > process. > > >>> > > >>> > > >>That should work, but requires DDE or COM on Windows, > right? And if > > >>we're doing that, can't we just talk directly to the > running process > > >>without starting a new one that tosses the command to the > running one > > >>and exits? I think that's how Excel does it, using DDE. > > >> > > >> > > > > > >Disadvantages of this approach are: > > > > > >- Non-crossplatform solution > > > > > > > - Actually, I was talking about using wxClient (certainly if > this bug > > appears on other platforms), which would be cross-platform, > as I wrote > > later in my email. Here I was talking about what the > underlying > > mechanism would have to be on Windows, in mind of that quote > from msdn > > that indicated the 3 methods of invoking shell verbs > (command line call, > > DDE, or COM) -- the latter 2 being the only ways I know to > fix this bug. > > > > But cross-platform may be irrelevant. Any Linux or Mac users > see this > > bug, or is it Windows-only? > > > > > > >- Not all programs / situations may respect the registry > settings > > > > > > > Sorry, I don't understand. This is about Windows shell > verbs, so what > > other programs / situations are pertinent? > > > > > > >- Won't work when user double-clicks Audacity icon / > chooses program > > >from start menu (to open a new empty project) > > > > > > > I think it could, on Windows. I think that just sends the > shell Open > > verb to Audacity, with no file parameter, so it opens a new > project. > > Sorry, I don't really know that much about the Windows > shell, and > > especially DDE. That's why I'm hoping there's a simpler > solution. > > > > > > > > > >But of course you're right that it should be first priority > to get the > > >release out now. So I'd say as long as the user can't do > anything wrong > > >(which he can't when the error message is shown as > described), it's ok. > > > > > > > > > > > Right on. Thanks for your thoughtful feedback, Markus. It's > more fun to > > think about creative things than how to work around > Microsoft's > > idiosyncracies & maintain cross-platform capability, so I > appreciate > > your brain cycles. > > > > -Vaughan > > > > >Markus > > > > > > > > > > > >>But the real point is: Is there some other way to get > Windows to just > > >>treat the Open shell verb as something like an Open menu > command event > > >>to the already-running Audacity process, so we don't have > to implement > > >>any of that for 1.2.0? > > >> > > >> > > >> > > >>>For this, I think a cross-platform solution would be the > cleanest thing > > >>>to do. wxWindows provides wxServer / wxClient which > already uses DDE on > > >>>Windows and Unix domain sockets on Unix (TCP/IP sockets > shouldn't be > > >>>used for security reasons). > > >>> > > >>> > > >>> > > >>> > > >>Right, I mentioned that wxWindows capability. And I > absolutely agree in > > >>principle. But two points: > > >> > > >>1) I think that's probably too much to add for 1.2.0, and > we should just > > >>stick with what I implemented yesterday for 1.2.0. > Shell-based > > >>client/server capabilities also fit in with the scripting > features being > > >>discussed for future implementation in Audacity, I think. > > >> > > >>2) All the windows/frames code is very platform-dependent > in Audacity > > >>already, and if this is a bug only on Windows, it may > require a > > >>Windows-only change, even if we use wxWindows > client/server stuff to > > >>implement it. Does bug 96 show up on Linux or Mac? > > >> > > >> > > >>Thanks, > > >>Vaughan > > >> > > >> > > >> > > >>>Markus > > >>> > > >>>I'd propose a platform-independent solution. > > >>>Am Fre, den 12.12.2003 schrieb Vaughan Johnson um 01:13: > > >>> > > >>> > > >>> > > >>> > > >>>>bug 96: > > >>>> > > >>>>On Windows (maybe others as well) you can double click > an .aup file and > > >>>>Audacity is started. When Audacity already is running a > dialog is opened > > >>>>asking if a second Audacity should be created. A few > months ago when you > > >>>>answered yes Audacity crashed which is rather awful on a > WinME system, > > >>>>most of the time crashing the full system. > > >>>> > > >>>> > > >>>>I looked into bug 96 a bit further & I think Otto's code > is > > >>>>unfortunately not relevant. The sample code all has to > do with handling > > >>>>multiple frames, and on Windows, gParentFrame is not > used at all. > > >>>> > > >>>>So, is bug 96 Windows-only? If it's on other platforms > as well, Otto's > > >>>>fix is worth implementing, but I'll let somebody else do > it because I > > >>>>can't test it. > > >>>> > > >>>>For Windows, when a .AUP file is double-clicked, we need > to tell the > > >>>>currently running process to execute > AudacityProject::OnOpen, rather > > >>>>than Windows starting a new process to open the project. > I haven't > > >>>>figured out any easy way to do this. Here's the closest > documentation I > > >>>>found on MSDN: > > >>>> > > > >>>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_verbs.asp > > >>>>... > > >>>> > > >>>> > > >>>> How the Shell Invokes Verbs > > >>>> > > >>>> There are three ways that the Shell can invoke a verb. > > >>>> > > >>>> * As a command line call, as specified in a *command* > key. > > >>>> * Through Dynamic Data Exchange (DDE), by using a > *ddeexec* key. > > >>>> * Through COM > > >>>> > > >>>> and IDropTarget > > >>>> , > > >>>> by using a *DropTarget* key. > > >>>> > > >>>> Invoking a verb normally launches the application > specified by the > > >>>> verb's command subkey using CreateProcess > > >>>> . > > >>>> However, if your application supports DDE > > >>>> , > > >>>> you can have the Shell initiate a DDE conversation > instead. > > >>>> > > >>>>We're using the first way of verb invocation. The > problem is that, with > > >>>>the file type associations in the Registry, the Open > command uses > > >>>>CreateProcess rather than trying to get the > already-running process to > > >>>>handle it. I believe we could do this with the other > ways of verb > > >>>>invocation, & I see that wxWindows abstracts & supports > DDE, but I don't > > >>>>know that this is something we want to do for 1.2.0. > > >>>> > > >>>>Anybody know an easy way to do this? > > >>>> > > >>>>In the meantime, I changed Audacity (1.2 branch only) to > disallow > > >>>>starting a new process, rather than asking if the user > is sure they want > > >>>>to risk crash & data loss. > > >>>> > > >>>>Thanks, > > >>>>Vaughan > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> > > >> > > >>------------------------------------------------------- > > >>This SF.net email is sponsored by: SF.net Giveback > Program. > > >>Does SourceForge.net help you be more productive? Does it > > >>help you create better code? SHARE THE LOVE, and help us > help > > >>YOU! Click Here: http://sourceforge.net/donate/ > > >>_______________________________________________ > > >>Audacity-devel mailing list > > >>Aud...@li... > > > >>https://lists.sourceforge.net/lists/listinfo/audacity-devel > > >> > > >> > > > > > > > > > > > >------------------------------------------------------- > > >This SF.net email is sponsored by: SF.net Giveback Program. > > >Does SourceForge.net help you be more productive? Does it > > >help you create better code? SHARE THE LOVE, and help us > help > > >YOU! Click Here: http://sourceforge.net/donate/ > > >_______________________________________________ > > >Audacity-devel mailing list > > >Aud...@li... > > >https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. > > Does SourceForge.net help you be more productive? Does it > > help you create better code? SHARE THE LOVE, and help us > help > > YOU! Click Here: http://sourceforge.net/donate/ > > _______________________________________________ > > Audacity-devel mailing list > > Aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Audacity-devel mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > Kimberly Chicchi > http://www.pitt.edu/~kicst5 > > > ______________________________________________________________________ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing |