Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!obelix.cs.uoregon.edu!akm From: akm@obelix.cs.uoregon.edu (Anant Kartik Mithal) Newsgroups: comp.windows.ms Subject: Re: give me solid facts.... Message-ID: <1991Apr2.033520.21271@cs.uoregon.edu> Date: 2 Apr 91 03:35:20 GMT References: <1991Mar27.061300.7636@nntp-server.caltech.edu> <1991Apr2.002941.5578@leland.Stanford.EDU> Sender: usenet@cs.uoregon.edu (Netnews Owner) Organization: Department of Computer Science, University of Oregon Lines: 160 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