I'd like to coninue this thread, because I believe it's important:
Acrobat and Acrobat Reader are strongly missing the MDI feature.
Probably the biggest share of "common" users will only open a single document at a time. But there are others around that sometimes have more than one single document open and who don't want to get their screen cluttered up with Acrobat documents.
From the thread above there's a Hyperlink to the Acrobat blog, justifying why MDI has been removed from the Acrobat GUI.
I believe the reasons given in there are wrong:
- Feature Parity with Macintosh was desired. As stated before, the Mac OS does not have this option. While I will be the first to admit that feature parity is not 100% between Windows and Macintosh, it is a goal that we aim for.
As written at the top of the blog, "MDI is not applicable on the Mac OS." So this is simply a system feature not available to Mac OS but to Windows. Parity in regard to system environment can never be achieved. Otherwise, Acrobat would have to strip keyboard support, because smartphones like the IPhone lack the presence of a keyboard.
Utilizing MDI is quite transparent to the software when being programmed properly. The client area to draw into won't be different. And the Mac OS will simply display like an MDI environment with just one document in it.
- In version 8, we made SDI the default in the viewing mode. Making SDI default, but still providing MDI in version 8 was done to start the deprecation of MDI.
This is no reason at all. It's just a description of a decision you made.
- Microsoft advised that to work as good as possible on Vista, applications should avoid MDI.
MDI is currently still available in any document centric Microsoft application. And it's available in any current document centric Adobe software - except for Acrobat.
WPF is commonly used as the successor of MDI, yet multiple-document GUIs are fully supported in Windows.
- Acrobat and Adobe Reader’s new UI modes would not work with MDI. Form editing mode, portfolio mode, and portfolio preview mode all wanted a complete refresh of the UI. MDI mode always left a bit of the UI skin under the care of an MDI main frame, so there would have had been no way for those UI modes to re-skin that part of the UI if MDI mode was left in place.
Perfoming these modes in MDI, WPF or any other multi-document environment would just have been a matter of good program design. Nothing more.
And again, if Mac OS does not support MDI, it's still possible to abstract the display concept to address SDI/MDI differences transparently in the Acrobat application. Microsoft Office even demonstrates how this is done: In all the MS Office applications there is an option to switch between MDI/SDI ("Show in Task bar").
- A cost compelling reason was that MDI and SDI mode essentially became another view mode in which all work flows had to be tested. This increases the cost of testing the product and the cost of fixing bugs. Often a fix to a bug in one view mode would cause adverse reactions in the other view mode. The decision to support only one view mode on Windows was made to simplify this. Furthermore, more time spent in this area could mean less time spent developing and fixing bugs in other areas.
That's true, alright. - But automated testing tools also decrease the cost of testing. And as far as I know, testers do not develop software. That's the developers' task. So performing more testing in this area does not result into spending less time for developing. This is particularly true once the framework had been established to deal with MDI/SDI transparently.
I strongly suggest to return to MDI. The implementation classes should still be available from Acrobat 8. Perhaps they'd need a redo in order to support a better, transparent program design.