Neil Hodgson wrote:
Eran:
Whenever a line is changed I add a marker on the margin indicating this
line was changed, if the file was saved, all marker a switched to green
markers.
This seems to work fine, however, it seems that adding the marker to the
editor messed the lexing of the document.
I haven't looked closely at this issue but in general, Scintilla is
not very robust in handling reentrant changes like this. A common way
of avoiding problems is to defer calling back into Scintilla until
after the current event, by posting your application a message to
perform the marker addition.
'Messing with the lexing' I mean that if I insert into the text a
comment block starter '/*' for example, the document is not colored to
green (as it should).
The most likely cause is the call to CheckForChangeOutsidePaint in
Editor::NotifyModified when it receives the SC_MOD_CHANGEMARKER
notification.
A change marker feature like in Eclipse or VS.Net 2005 is quite
complex particularly in its relationship with undo / redo and the
three change states (original, changed, changed and saved).
Neil
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
I did what you recommended (posting my app a message - didnt work), but
finally I managed to pull it, what I did was:
I still added the marker when catching the SC_MOD_INSERTTEXT |
SC_MOD_DELETETEXT, after I added all the needed markers according to the
line number added in the notification,
I called SCI_COLOURISE(SC_GETCURRENTPOS, 1) - colored single byte?, the
funny thing is that it worked, it fixed all the lexing issues I had. I
tested this for performance on a failry large
source file (~300K of code) no problems there.
What do you think? Can anyone explain why coloring a single position,
fixed a whole page?
Eran
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
