Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!jmerrill From: jmerrill@jarthur.claremont.edu (Jason Merrill) Newsgroups: comp.windows.ms Subject: Re: give me solid facts.... Message-ID: Date: 2 Apr 91 22:35:03 GMT References: <1991Mar27.061300.7636@nntp-server.caltech.edu> <1991Apr2.002941.5578@leland.Stanford.EDU> <1991Apr2.033520.21271@cs.uoregon.edu> Sender: jmerrill@jarthur.Claremont.EDU Organization: M.Y.T.H. Inc. Lines: 74 In-reply-to: akm@obelix.cs.uoregon.edu's message of 2 Apr 91 03:35:20 GMT >>>>> On 2 Apr 91 03:35:20 GMT, akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) said: >[...] > The current situation is that one of four different things happens, > depending on what the programmer of that application has done. > 1. Nothing (e.g. progman. To try it, *don't* issue the run > command from the program manager. If you try it from the > program manager, that progman is already active, so it > will remain active, so you won't believe me... > 2. Silly message saying that the application is already running > (e.g. Word, WinFile) > 3. switch to the application that is already running. (e.g > control panel, printman) > 4. start up a new copy of the application. (e.g. notepad, > cardfile, clock, etc.) >[...] > I think that this is confusing for a user and that having as many > variations as this is totally contrary to the concept of a consistent > GUI. I'd suggest that the simplest way to get around this is to > always bring the running application to the foreground. It would in > cases where the user passed it a filename, also have to be able to > respond to a new message, something like "WM_COMMANDLINE" with a > pointer to a string containing the command line, so that it can deal > with whatever file the user had double clicked on. I think that is > what Aaron mentions a little lower down. > To solve the problem of running a second copy, the system menu should > have an option allowing a second copy to run. This can be disabled on > those applications that cannot allow a second copy to run. So, if you > want a second copy, find the first, and ask it to run a second copy. >[...] > Even launching multiple copies of the same application has its > problems... You can end up with lots of empty notepad windows while > the window you *really* want is lost... Or, you could start editing > file.txt by double clikcing on it in WinFile, then double click on it > again, get two instances of notepad with the same document, one with > some changes, one without, make some new changes in copy two, double > click on the filemanager icon again, make a third set of changes, and > save everything back in LIFO... loose your most current changes... Now, it really seems to me that this is an application design problem more than a Windows problem, and that you can write apps right now that would support this sort of interaction. When an app is first run, it checks the Windows environment to see if there are any other instances running. I assume that Word and Progman do this already, but just don't do anything useful with the information. If a single-instance program such as Word is run and discovers that a copy of it is already running, it could do one of two things: If it was run without a command line, simply bring the previous instance into the foreground. If it was run with a command line, parse the command line and tell the previous instance to open a window on the desired file using DDE calls. A multiple-instance program such as Notepad would not really need to support this checking. If you want to protect against multiple instances editing the same file, a program could do this: When it is first run, it checks the environment for other instances of itself. If it finds some, it goes to each of them in turn and asks them, again using DDE, what file they are editing. If it is the file specified on the command line, give an error and refuse to open it. It could do the same checking on a File Open command. Anyone see any problems with this? -- Jason Merrill jmerrill@jarthur.claremont.edu