akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) (04/02/91)
aaron@jessica.stanford.edu writes >robertk@lotatg.lotus.com (Robert Krajewski) writes: >>woody@nntp-server.caltech.edu (William Edward Woody) writes: >>akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: >> > >> >The seperation makes a different to users. I had a user who kept going >> >back to the icon in the program manager (that was the one that she new >> >about because that is the one she used to start Word with), and double >> >clicking on it, which resulted in her repeatedly getting the same >> >message. Finally, in frustration, she said "Yes I KNOW!! So RUN it!!" >> >>Exactly. The computer knows what's going on, so why can't it remedy >>the problem and help her get work done ? > >Because "the right thing to do" is not clear. Windows can't always tell if the >app allows multiple instances or not by examining the .EXE file. So, should >Windows throw the file at the existing instance or start another afresh? >Remember, an app that is otherwise multiple-instance compatible could still >allow only one instance for whatever reason. The problem is that Windows hasn't really addressed the issue of existing app vs running app. See my reasoning below. >> Strictly speaking, the problem your friend is experiencing is a >> problem with Word. As a lot of people have pointed out, yes, I know, it is a problem with Word. I didn't say that in my original posting because it seemed so obvious. The problem is: given that an application is running, and an "WinExec" call is executed, what should happen? (I am assuming that Progman, Winfile etc essentially do a WinExec when asked to run an application.) 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.) Note that all applications I've mentioned here are by Microsoft. We can say that Word is written by a different department, which is not supposed to have anything to do with the OS group, so discount Word. We still have one each in each category from the set of distribution software for Windows. 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. Now, an app would work something like this. Word-type programs (single instance) would have the system menu for a second instance disabled, and when something is double clicked, would get the WM_COMMANDLINE message, and in response to it would open a new document in the existing instance. Apps like Notepad on getting WM_COMMANDLINE would run a second copy of themselves on the new file. >Windows *can* do it the Mac way--why Microsoft didn't choose to add the >functionality is beyond me. I put it in an editor I'm working on and it >took about 10-20 lines of simple code. You basically get the handle of the >previous instance and send it a message with the file to be opened. > >>The real problem is that Windows does not define higher-level >>mechanisms for things that the Macintosh does already. See, the way >>it ought to work is that the File Manager ought to notice that an >>instance of Word (or another other MDI application) is already >>running, and then sends a DDE message to it (with standard semantics >>and a standard interface) to open up a new file. I don't agree with Robert here. WinFile is *just* another application. It is *not* part of the OS. The OS (i.e. windows) should see that there is another instance of the app running, and should bring it to the foreground. So if Joe Block, Jane Plank and I write our own little file managers, if we launch an application the OS will take care of things. The problem in Windows (as shipped) is that there are three locations where icons can exist, Progman, Winfile and the desktop, and these three icons don't know about one another. >But what if you really want a second instance? I discussed that above... and others (including Aaron) have the same kind of idea. >>Basically, it would involve extending the currently >>anemic file association mechanism. I am not sure why Robert thought this is a problem with the file system. The file system sucks, but in this case the problem is in Windows itself. Robert, could you elaborate? >Anyway, all I really want to see is more programs that don't act like >Word. Launching the second instance is ok. Passing the file to a previous >instance is fine. But the Word reaction is silly; Word *should* know better. >Windows doesn't have to: it told Word to open a file using the well-established >command line interface. What I find funny is that Word etc could have dealt with this rather than put up the message box, which serves NO purpose. I would guess that a user who has just double clicked on Word/WinFile icon wants either to launch a second copy, or wants the first copy back. By using the messagbox, the programmers have managed to make sure that neither desire is met... Of course, ProgMan is even better... I have noticed that double-clicking is something that people take a little time getting used to. Now, if your ProgMan window/Icon is hidden behind a bunch of other windows, and you see Progman in the filemanager, and double click on it in hopes of getting back to the Progman, *nothing* will happen. So, you will assume that you didn't double click correctly... So you will double click again. And nothing will happen. So you will double click again... 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... Take the existing implementation of microemacs for windows (thank you whoever wrote it...). Now, I am editing a file, and I see (in the file manager), another file I want to edit. I double click on this file. WinFile obligingly launches another copy of microemacs.... So, I can't use the emacs mark-and-yank between that file and the file I was originally editing... Sigh. -- Anant Kartik Mithal akm@cs.uoregon.edu Research Assistant, (503)346-4408 (msgs) Department of Computer Science, (503)346-3989 (direct) University of Oregon, Eugene, OR 97403-1202
jmerrill@jarthur.claremont.edu (Jason Merrill) (04/03/91)
>>>>> 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
mqvortru@iiic.ethz.ch (Michael Heide Qvortrup) (04/03/91)
In article <1991Apr2.033520.21271@cs.uoregon.edu> akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: >... >I think that this is confusing for a user and that having as many >... >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. > And this is not confusing for the user? I agree, that the message "WinWord is already running" is completely stupid, and should have been avoided, but the solution with YAO (yet another option) is really worse! >I don't agree with Robert here. WinFile is *just* another application. >It is *not* part of the OS. The OS (i.e. windows) should see that >there is another instance of the app running, and should bring it to >the foreground. So if Joe Block, Jane Plank and I write our own little >file managers, if we launch an application the OS will take care of >things. The problem in Windows (as shipped) is that there are three >locations where icons can exist, Progman, Winfile and the desktop, and >these three icons don't know about one another. > So you think, that the OS (which it really isn't, it's just Windows) should force me to do things the way IT want me to do them, you know just like the Mac :-)? I find that it is much better to provide the functionality for several diffe- rent ways, and then let the programmer of the application decide how he wants it solved. >>But what if you really want a second instance? > Exactly my point. >What I find funny is that Word etc could have dealt with this rather >than put up the message box, which serves NO purpose. I would guess >that a user who has just double clicked on Word/WinFile icon wants >either to launch a second copy, or wants the first copy back. By >using the messagbox, the programmers have managed to make sure that >neither desire is met... Right you are; this solution is no solution. >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... I see the problem here, but I don't think, that your solution is all that fine either. Basically you want the application to have multiple document capability. Fine, I would like that, too. You also want the application to recognise multiple instances of the same document. That I don't really like. It makes sense in some apps, e.g. programming editors, but certainly not in all. I can imagine at least one scenario, where I most certainly don't want my document shared. Say, I'm working on a document (this need not be a text), and I see two ways of doing something. Now, I want to check them out, but I don't want to change the same document first one way and then the other. But, my OS wont let me start my app again, as in separate copy running, and my app SHARES my new copy with the old, which means, that changes are eccoed to the original! IMHO, now the OS has become too restrictive. My solution would something along the following (and the app implements it, not the OS). The app gets the message about starting with a new document, it then notices that it is already running, fine don't start another copy. Then it notices, that the new document is a copy of something already loaded. Now I would like the app to ask me whether I want a shared copy of the document, or if I want a distinct copy. Just my attribution to the ongoing thread. --Mike
robertk@lotatg.lotus.com (Robert Krajewski) (04/05/91)
In article <1991Apr2.033520.21271@cs.uoregon.edu> akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) writes: The problem is: given that an application is running, and an "WinExec" call is executed, what should happen? (I am assuming that Progman, Winfile etc essentially do a WinExec when asked to run an application.) WinExec should just make a new instance of the application. Of course, it might fail because the application can't have more than one instance (because it's a large model application), or because the application itself enforces such a policy. Anyway, WinExec isn't the right place to fix this message. >Windows *can* do it the Mac way--why Microsoft didn't choose to add the >functionality is beyond me. I put it in an editor I'm working on and it >took about 10-20 lines of simple code. You basically get the handle of the >previous instance and send it a message with the file to be opened. This is a reasonable solution, which fixes it for just one program: yours. What I was talking about below was a more general mechanism for solving the problem. I don't agree with Robert here. WinFile is *just* another application. It is *not* part of the OS. >>Basically, it would involve extending the currently >>anemic file association mechanism. It's not the file system per se that sucks (although a better one like OS/2 HPFS or Mac HFS *would* make life easier). The reason why I mention extending the file association mechanism (which shows up as the [Extensions] section of your WIN.INI) is that I *don't* want WinFile to be special. Any other application has access to the same data. Anyway, associations between files and applications are globally useful. We would like to take something a little higher level than merely starting a program, and offer the some support for it in the OS. (Or at least we should know where to look for the right thing to do !) The Mac got that right seven years ago. For example, one reasonable extension that could be made is that the line: wri=write.exe ^.wri would not only mean: If you open <something>.wri, use the command line write.exe <something>.wri but also If there is already an instance of write.exe (which can be determined quite cleanly), send it an ``open new file'' message with the parameter <something>.wri. If the message fails (the instance does not handle it), go back to the old way and try launching a new instance. Having a general mechanism is nice because it means that programs like Bridge, which exist for the purpose of hooking other applications together much like a shell, can treat applications and documents like objects, with operations like Open. That's really the one advantage of coming up with a general protocol for doing this, instead of the application implementing it itself. In the Mac world, this ``open file'' operation will be a standard AppleEvent, and MultiFinder will stop using the file-open-dialog-circumvention kludge. Note that the <open-new-file> message could be its own proper message (defined by Microsoft), or it could be part of a new set of things built on top of DDE.