b9ecec7c74
When e.g. viewing mail attachments (that have been stored r/o to some download directory by the mail application), it would be nice if the user could easily temporarily modify them (say, play around with a spreadsheet, changing some numbers and triggering recalculation of formulas) by clicking the "Edit File" button and not being asked to create a copy for editing. This patch tries to make editability of a view independent of the r/o status of the medium: * SID_EDITDOC (the "Edit File" button) now only toggles the r/o status of the view. It no longer asks to create a copy for editing if the underlying medium is r/o. * When a modified document is toggled to r/o via SID_EDITDOC, LO still asks the user to save or discard the changes. However, if the underlying medium is physically r/o (see next), saving the document opens the "Save As" dialog, instead of just doing a "Save" operation (which would fail on the r/o file). * A new state of "IsOriginallyReadOnly" needed to be added to the medium, to keep track whether the medium was originally opened r/o (and is thus assumed to be physically r/o), as toggling SID_EDITDOC in the view also changes the open mode of the underlying medium. Instead of trying to fully understand and disentangle that horrible mess, I just added yet another state to the mess... * The title of the document window now contains "(read-only)" if and only if either the view is r/o or the medium is originally r/o (or both). Change-Id: I89d9c6adf0baab411e737a5f4e6f4e770e7a70be |
||
|---|---|---|
| .. | ||
| inc | ||
| prj | ||
| qa | ||
| sdi | ||
| source | ||
| util | ||
| workben/custompanel | ||
| AllLangResTarget_sfx2.mk | ||
| CppunitTest_sfx2_metadatable.mk | ||
| JunitTest_sfx2_complex.mk | ||
| JunitTest_sfx2_unoapi.mk | ||
| Library_qstart.mk | ||
| Library_sfx.mk | ||
| Makefile | ||
| Module_sfx2.mk | ||
| Package_inc.mk | ||
| Package_sdi.mk | ||
| README | ||
SFX is the "old" framework, used for historical reasons. It contains base classes for document model, view and controller, used by "old" applications like sw, sc, sd (while "new" applications are based on the "new" UNO based framework in "framework"). The SFX framework is based on dispatching slots identified by integers (SlotIDs) to SfxShells, and there is a dedicated IDL compiler (svidl) involved that generates C++ slot headers from SDI files in modules' sdi/ subdirectory. Document load/save code is maintained in [git:sfx2/source/doc/docfile.cxx] SfxMedium class, which handles all the twisty load and save corner cases. [git:sfx2/source/applappl/sfxhelp.cxx] Start procedure for the online help viewer top level window; handling of help URL creation and dispatch. There are also some UNO services here that could really be implemented anywhere, e.g. the DocumentProperties or DocumentMetadataAccess.