Neil Hodgson wrote:
Robert Roessler:
You keep saying this (or close variations), but while Windows messages
and messaging are things I find easy to use, my app is using the GTK
widget version of Scintilla, and I do not really have a clear picture
of a) how async messaging would work in this environment, or b) if any
approach would work on all the platforms where GTK is nominally
supported. Besides, explicitly asynchronous control logic can be
headache-inducing (particular when not really necessary).
This is subject to the law of headache conservation. By refusing to
allow reentrance in some areas of Scintilla, my potential headaches
are instead pushed to you ;-)
A common way to queue an asynch job on GTK+ is gtk_idle_add. See
scintilla/gtk/ScintillaGTK.cxx ScintillaGTK::SetIdle for an example.
For polling jobs there is gtk_timeout_add as used in SciTE. These have
been deprecated in favour of g_idle_add and g_timeout_add but
Scintilla is still trying to be compatible with GTK+ 1.x.
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html
Hmmm... I already use both idle jobs and timeouts in my GTK-hosted
code. They aren't messaging, but you are right, they certainly are
mechanisms that allow "things" to happen "later". I am just all to
aware of the difficulties that can crop up when trying nail down
and/or synchronize those "things", as well as defining exactly what
"later" means. Sigh.
OTOH, you *could* consider allowing *style* modifications to nest
(like markers) - the code (in Document::SetStyleFor() and
Document::SetStyles()) didn't look too far from being workable already
- I just am a bit unclear about how to handle endStyled.
As am I and the code that tries to avoid restyling and redrawing
the whole window could also cause trouble. If Scintilla had a styling
cursor (endStyled) for each styling 'channel' (indicator or base
styles) then this would be more tractable. But then you wouldn't
really want reentrance as Scintilla could call all the stylers (one
for each channel) in some order that would allow one channel to depend
on the results of another.
Key to both of these, of course, is to still track enteredCount, and
be smart about issuing notifications - maybe only allow one level of
recursion, and decide to call NotifyModified a) the first time, or b)
both times, depending on how things will work with nesting (or not)
Redraw() or InvalidateRange() calls... we certainly do not want any
endless loops. :)
I think implementing this as minor changes is doomed to many bugs.
I'm imagining the movie version of Starship Troopers here.
Hey, I know that a lot of people didn't like the movie, but this is
harsh! ;) And clearly it is your headaches that we need to be most
worried about here (where would the next release or new editing
component come from?)... but could you look at
http://www.rftp.com/DocumentRBR.cxx
I already had this done and have been testing it. :)
It has minimal changes allowing Document::SetStyleFor() and
Document::SetStyles() to be reentered... but NotifyModified() will
only be called if we are less than two levels deep in recursion,
preventing things from getting out of hand.
I like to see it as allowing a Scintilla client to override or
second-guess the active lexer. It is a very limited feature. The
approach of putting endStyled back to what it would have been if no
recursion had taken place is used... note that we do not know if
*styling* calls themselves are what is being nested, just that styling
is not fully blocked from within a notification handler. Further, if
you attempt to mess with anything outside the visual update range of
whatever notification you are handling, you might not see the screen
update. Now *that* is what I call limited! ;)
If you look it over and poke [un-fixable] holes in it, I will drop
this... but I do think that a small relaxation like this can be
useful, as long as enough of Scintilla's invariants are preserved for
overall safety. Sure, something like this probably should be a "Kids,
do not try this at home!" feature... but if it isn't used, what can it
hurt (always one of my favorite arguments). ;)
Now off to add the "caret allowed here" indicator (none of that is the
linked file)...
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
