Robert Roessler: > What I see in the GTK [on Windows] widget incarnation of Scintilla is > that a click *in* the last char on a line (but to the right of the > *midpoint*) is returning the -1 code for "no char close to here". All > other cases work as expected/wanted... in particular, horizontal > matching seems to give a "hit" if within half a char width to the > right or left of a char that is surrounded by spaces. So one might > assume that this would also work at the end of a line...
I see it too with Windows native version. There is a small chance this was deliberate but I can't recall any reasons why this could be helpful so it should be fixed. > I have tried to get debugging prints to work from > Editor::PositionFromLocationClose(), but am having no luck with my > usual approach of inserting Windows kernel debugger calls to > OutputDebugString and monitoring the output with Dbgview from > Sysinternals - I see none of my trace messages when running in the GTK > widget environment. OutputDebugString should work. Make sure you are using the expected ...W or ...A version as I suspect GTK+ will prefer Unicode APIs. > Finally, I notice that when I use a SciLexer.dll with my trace > messages with SciTE, the internal functions > Editor::PositionFromLocation() and Editor::PositionFromLocationClose() > are called at a very high rate with any mouse movement - no buttons > down etc. Is this happening to support "hotspot" styles whether they > are in use or not, or is this happening for some other reason? Hotspots, dwell events and cursor choice. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
