Neil Hodgson wrote:
Robert Roessler:
In detail, RestoreMark would take a line and a set/mask (presumably
from a GetMark call) and sets all of the indicated markers at once. A
key point to note is that, unlike multiple calls to AddMark,
RestoreMark would NOT cause SC_MOD_CHANGEMARKER-flavored SCN_MODIFIED
notifications to be issued...
How bad is turning off SC_MOD_CHANGEMARKER notifications while
performing this code. Either through calling SCI_SETMODEVENTMASK(mask
& ~SC_MOD_CHANGEMARKER) or using your own application side flag?
Why RestoreMark? In "programming around" the Scintilla marker system,
I often find it necessary to remove all markers from a line, do some
line inserts/deletes, and then put all of the markers back (after
deciding which is the line they should have been sticking to).
This only does a correct restoration where you have one marker set
in each bit and are not concerned with marker handles. I'd call your
operation SCI_MARKERADDMULTIPLE or SCI_MARKERADDSET and not try to
bundle it with notification suppression as there is an existing call
for that.
Nope, I do not care about handles (or the "duplicate markers on line"
case)... the no-notification thing (as a low-level "under the radar"
approach) seems to fit the way I see this being used. It is true that
the notifications can be turned-off or ignored, much like the whole
thing can be simulated by interpreting the bits yourself and doing
multiple SCI_MARKERADD calls - it just seemed a logical grouping of
macro-operations to bundle.
So, if you will not go for a "no-notification" version of this, are
you disposed to accept a "well-written etc" implementation of
SCI_MARKERADDSET? If I need to preserve the notification behavior, I
trust that *one* NotifyModify call will suffice for both the
[optional] notification and the RedrawSelMargin?
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
