On Tue, 2003-12-16 at 01:20, bulia byak wrote:
I added statusbar flash to sp_file_save_document saying "Document
saved."
However I see no way to find out whether the save was actually
successful -
of course this needs to be displayed only on success. But sp_module_system_save returns nothing useful. Is this by design? In fact
it
does have a return with value, even though it is declared as void.
No good reason. I'm thinking about switching this to throw an exception as I convert things to C++... Any comments are welcome.
So with an exception, the fact that the function returns at all is an indication of success, right? If so, that's nice.
While at it, I added a check of sodipodi:modified so that unchanged
document
is not saved. I wonder why this was not done before - are there any
pending
problems with sodipodi:modified? It works nice in my testing so far.
I've tried to keep this up-to-date in all the modules code. In 0.35 it was pretty broken, I think I've fixed it everywhere for 0.36. If you find anyplace where it isn't working - tell me. It wasn't working for any time of extension save before. I believe currently it is cleared twice on saves that use an internally defined module. But this is another thing I'd like to fix as I'm moving all the code to C++. I'm taking the oppurtunity to 'clean things up' as I go.
So far it saves when modified and does not otherwise, quite reliably. In this case, it's better to err on the side of caution, so if it over-saves, I won't mind; only if it fails to save a changed document we have a problem.
_________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
On Tue, Dec 16, 2003 at 06:36:23PM +0000, bulia byak wrote:
So far it saves when modified and does not otherwise, quite reliably. In this case, it's better to err on the side of caution, so if it over-saves, I won't mind; only if it fails to save a changed document we have a problem.
If the `Save' menu item isn't greyed out, then it should attempt to save, or at least read in the file and check that no save is necessary. (This may also alert us to problems with the modifiedness tag.)
Rationale: the user may have moved (accidentally deleted) the file since the last save.
If we grey out the `Save' menu item, then the user knows that they must force a modification if they want save to work. (May be less effective with keyboard shortcut, though.)
It can be useful for the user to know if the document has been modified. (E.g. does it need re-uploading or reprinting or whatever.) Greying out the `Save' menu item is one way of providing this information; though if we really value this information then a "louder" indication may be warranted: e.g. change of title bar (append ` (modified)'), or status bar change.
pjm.
On Tue, 2003-12-16 at 18:43, Peter Moulder wrote:
On Tue, Dec 16, 2003 at 06:36:23PM +0000, bulia byak wrote:
So far it saves when modified and does not otherwise, quite reliably. In this case, it's better to err on the side of caution, so if it over-saves, I won't mind; only if it fails to save a changed document we have a problem.
If the `Save' menu item isn't greyed out, then it should attempt to save, or at least read in the file and check that no save is necessary. (This may also alert us to problems with the modifiedness tag.)
This is planned, but also requires SPActions do be de-globalized.
Theoretically, SPButtons should update their active/disabled/toggled states based on their actions, but since all SPButtons for a particular verb currently share a common SPAction, I had to break that temporarily for things to behave sanely.
Long-term fix is as I mentioned earlier to Bulia -- make SPActions per-SPView (permitting per-document state).
-mental
participants (3)
-
bulia byak -
MenTaLguY -
Peter Moulder