Robert Roessler wrote:
... and implementation. :)
More issues with my display of OCaml compiler warnings/errors in-line in my Scintilla buffer - to recap, I am using markers to "point out" errors in the source code, and markers to also identify warning/error messages (and compiler output in general). Most recently, I am also using indicators to further connect portions of the source code with corresponding errors/warnings.
So, at some point, this stuff needs to go away. Because of the way markers are defined to work, I MUST process SC_MOD_BEFOREDELETE notifications and remove the markers at this time.
Logically, this is also a good time to remove the other decorations added to the user's source code - like the indicators. BUT, they cannot be removed during the processing of the SC_MOD_BEFOREDELETE, because of the way "modify" notifications are defined to work (no text/styling changes).
Next, I tried to use SCN_MODIFYATTEMPTRO notifications to remove the indicators... ultimately, this does not work out either, since Undo does NOT trigger this notification! :(
I find this surprising - logically, if a doc has an Undo stack present, and THEN has "read-only" set for it, shouldn't an Undo attempt trigger the SCN_MODIFYATTEMPTRO notification? Note that setting "RO" status does not do anything extreme like clearing the Undo stack, removing that as a "reason" for working this way.
Looking at the Scintilla code, the behavior that I expect (the "doc is RO" notification) is blocked very early by muddling the "CanUndo()" definition with "readOnly" (in CellBuffer::CanUndo(), which is used by Document::CanUndo(), which is used by Editor::Undo()), rather than allowing things to get further along (like the other modification attempts) and THEN saying "NO" and issuing the SCN_MODIFYATTEMPTRO. Sigh.
I believe this to be fixable, and am willing to do so... does anyone see a problem with issuing this notification (attempting to Undo/Redo with a doc that is AT THAT TIME set read-only)? All I am proposing is just issuing the expected "NO" when trying to do something that already is being blocked anyway.
All right. I made the [fairly simple] changes and it works fine. :)
Basically, after adjusting CellBuffer::CanUndo() so that its result is determined solely by the undo stack status, the other minor changes were just making Document::Undo and Document::Redo match Document::DeleteChars and Document::InsertStyledString WRT checking cb.IsReadOnly() and doing a NotifyModifyAttempt() as required.
Finally, since Document::Undo() and Document::Redo() can now "fail", I added checks on the ONLY places these are called (Editor::Undo() and Editor::Redo()) for this possibility (a single if).
I will mention that SciTE's Edit menu is *able* to show an enabled Undo/Redo entry IF the buffer is modified and THEN Read-Only mode is selected - but this is a somewhat unusual situation, and *nothing* is actually wrong in the sense of any possible document corruption - Undo and Redo are still BLOCKED in Scintilla from actually doing anything by the Read-Only status. Note that both the SciTE and builtin Scintilla context menus already have extra code that "does the right thing".
For anyone interested, I have placed a zip containing these changes PLUS my "lazy" Undo/Redo mods (since they involve the same files) at
http://www.rftp.com/lazyplus.zip
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
