dsb@Rational.COM (David S. Bakin) (12/12/88)
Consider an application that allows some sort of inspection or manipulation
of one of something (like a file) most of the time, where the user would
possibly want to be investigating more than one file object at a time but
each one completely independently, except that maybe occasionally there would
be some operation to be done on a pair (or group) of the objects being used.
For example, perhaps the application would be a specialized file browser.
The user may want to have browsers open on more than one file at a time,
but his operations on any given file (scrolling, hex/ascii display mode,
editing, iconifying/zooming) are independent from his operations on any
other file being browsed. Except that once in awhile he might invoke a
"compare-two-files" command to compare two files being browsed and to
highlight differences between them.
Which of the following methods is preferable, or perhaps a better question,
what are the pros and cons of each method?
0) Have one application with a File menu. Use the multiple-document
interface style guidelines.
But the point of this message is that for the application in mind I'd like to
treat all of the objects being applied (applicated?) independently, so I don't
feel that this is as good an interface as having each file be in its own
independent (overlapping) window, even though this is against the style
guidelines. But with that understood, then:
1) Have one application with a File menu. But create each file in its
own independent window. The application ends when its window is
closed (possibly even if some file windows are outstanding).
2) Fire up the browser for each file you want to browse. A new application
instance will be created. Establish a DDE link with the instance of the
file you want to compare against and do everything with DDE transactions
between the two applications (in this case, passing entire data blocks of
the file from one application to the other). Each application ends when
its own window is closed.
3) Fire up the browser for each file you want to browse. A new application
instance will be created. Using the hPrevInstance, if you're not the
first instance then post a message to the first instance passing over
the file name, then die. The first instance then creates a new independent
window to browse the file, and since all files being browsed are now in
the same application just manages within itself the file compare and
displaying. The application ends only when the last surviving window
is closed.
I was sort of envisioning a scheme where the file browser application would
exist as an icon. When selected, it would continue displaying as an icon,
but would pop up a file-selection dialog box. Then when a file name was
entered, it would pop up an independent window for the file.
(Maybe the business about cooperating operations happening occasionally
is a red herring. Why shouldn't all applications use method #3 for
multiple instances? Is there any use to hPrevInstance than just deciding
whether windows and other resources need to be registered?)
(Actually, I'm rather new to Windows. Maybe there is an application or
utility or two that actually does this sort of thing that I could be
pointed to?)
Thanks! -- Dave
----------------------------------------------------------
Dave Bakin (408) 496-3600
c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197
Internet: dsb@rational.com Uucp: ...!uunet!igor!dsb