[SOLVED] Parasitic cursor in code editor. lazarus / 9-Editor ---------------------------------------------------------------------- BrunoK · 2018-11-16 11:39 Win 10 Drag the edit window such as the last line is below the screen area, then use keyboard cursor down repetitively. A parasitic cursor gets scrolled up the edit window. Can someone reproduce or is it an artefact of my system ? ---------------------------------------------------------------------- Martin_fr · 2018-11-16 12:06 Does not happen for me. Win10 64bit Lazarus trunk. Please attach your editor options. Also check with Lazarus 2.0RC2 there may be caret related changes in there. If it is ok, in 2.0 test with a custom caret color too (color options) ---------------------------------------------------------------------- BrunoK · 2018-11-16 14:11 If I change in 'IDE Options'/Editor/Display/Colors/Text/Caret : Color (NotXor) from NotModified to Black or Olive for example, there is not parasitic trail. When changing back to NotModified the Parasitic trail reappears. What file (xml ?) does contains this parameter, I didn't manage to track it down. @Martin_fr, please don't loose any time on that, it is a really a very minor problem. ---------------------------------------------------------------------- Martin_fr · 2018-11-16 17:46 Quote from: BrunoK on November 16, 2018, 03:11:06 pmWhat file (xml ?) does contains this parameter, I didn't manage to track it down. In the IDE go to menu: View > Ide Internals > About IDE Locate the "primare config path" In that path is a file "EditorOptions.xml" Please provide this file. Just so, I can try under identical conditions. ---------------------------------------------------------------------- zeljko · 2018-11-16 18:27 @Martin, btw why I see 2 carets in recent trunk (don't know when they actually appeared) when code completion window is open and I'm typing ? eg Self.|Fo|  (typing Self.Fo and code completion window is open), tested with qt4 and qt5 under X11. ---------------------------------------------------------------------- Martin_fr · 2018-11-16 18:53 I currently only have gtk on linux (Fedora 28). Not using it much, but no problems yet. "2 carets" => both blinking? But only one responds/types input? Both exactly the same color, or one slightly fainter? Cant think of any recent changes... But please provide a log, compile IDE with: -dSynCaretDebug -dSYNSCROLLDEBUG -dVerboseSynEditInvalidate -dSynCheckPaintLock -dVerboseFocus -dVerboseKeys run lazarus --debug-log=/path/file Depending on how it goes, I may have to add more debugln.... The VerboseKeys, is so I can match your actions against the log. So please describe when you pressed what key, and what happened. ---------------------------------------------------------------------- zeljko · 2018-11-17 08:42 Quote from: Martin_fr on November 16, 2018, 07:53:47 pmI currently only have gtk on linux (Fedora 28). Not using it much, but no problems yet. "2 carets" => both blinking? But only one responds/types input? Both exactly the same color, or one slightly fainter? Yes, see attached screenshoot. First caret stays at the beginning where code completion is started, second one after the last typed letter. Both are blinking. Only second one responds to typing in code completion and moving. First one is always at the beginning where code completion window is shown. ---------------------------------------------------------------------- BrunoK · 2018-11-17 09:27 Quote from: Martin_fr on November 16, 2018, 06:46:25 pmIn that path is a file "EditorOptions.xml" Please provide this file. File attached. ---------------------------------------------------------------------- guest58172 · 2018-11-17 10:26 Quote from: Martin_fr on November 16, 2018, 07:53:47 pmCant think of any recent changes... r59490 maybe ? ---------------------------------------------------------------------- Martin_fr · 2018-11-17 10:58 Quote from: BBasile on November 17, 2018, 11:26:19 amr59490 maybe ? Unlikely, the forms (and its parents visibility does not change there). But you could test it, its a small change, and it can be undone, without rolling back anything else. I think the 1st and 2nd should also be easy to unroll More likely candidates: 58647 SynEdit: Caret Color (July 2018) 58644 SynEdit: fix default caret painter class (set to system) (July 2018) 58534 SynEdit: Option to have a static (none blinking) persistent caret. Issue 0033653 49115 SynEdit: fix to system caret / Restore system caret as default, if not using multicaret (May 2015) They are all based on the last one (49115). ---------------------------------------------------------------------- Martin_fr · 2018-11-17 16:20 Ok, I can reproduce the issue of BrunoK. One of the reasons I did not reproduce right away is that on the bottom of my screen is the task bar. And it is not sufficient, to hide the editor's bottom behind the task bar. It really needs to be out of the screen. The other reason, it does not happen to me (though I had tried without) is that I have a "current line highlight" As a workaround, it should be possible to set a "current line highlight", specify a background color equal to the editors background. ---------------------------------------------------------------------- Martin_fr · 2018-11-17 17:26 Any idea where to get the qt5pas for fedora 28? ---------------------------------------------------------------------- Martin_fr · 2018-11-17 19:54 Reproduced the qt issue too (with qt4 on win). The problem is that LCLIntf.CreateCaret does return false (aka caret failed to be created). So SynEdit does not remove it. During autocompletion SynEdit uses its own caret, so the system caret remains. ----- @zeljko please test In unit SynEditPointClasses line approx 2765 Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function TSynEditScreenCaretPainterSystem.CreateCaret(w, h: Integer): Boolean;begin  // do not create caret during paint / Issue 0021924  Result := HandleAllocated and not InPaint;  if not Result then    exit;  inherited CreateCaret(w, h);  inherited SetCaretPosEx(-1, -1);  Result := LCLIntf.CreateCaret(Handle, 0, w, h);  SetCaretRespondToFocus(Handle, False); // Only for GTK  debugln(['==SYSTEM CARET +++ CREATED ', result]);  // <<<<<<<<<<<<< insert  if not Result then inherited DestroyCaret;end; and get the output   lazarus --debug-log=file or run with console. --- Edit: https://bugs.freepascal.org/view.php?id=34563 @zeljko, if the above does log false for you, please update/confirm on the issue. -- A workaround for the QT issue has been applied in r59580 @zeljko, please confirm if this "fixes" it for you => then it can be merged to 2.0 ---------------------------------------------------------------------- Martin_fr · 2018-11-17 22:47 @BrunoK It is actually not an issue with scrolling. It happens whenever the caret is "unpainted" outside the screen. Place the caret at the bottom of the editor. Move the bottom so it is off screen. Click the desktop, or otherwise un-focus the editor. This will trigger the editor to hide the caret. When you activate the editor, do so by clicking in the visible text area, so the caret is re-created at a new position. Move the editor back into view, and there will be a permanent caret, where the old caret used to be. I dont have win 7/8, but under Vista this error does not happen... Still evaluating, what (if) the best way is to deal with it. ---------------------------------------------------------------------- Martin_fr · 2018-11-18 20:01 A fix for the issue has been committed in r59596. I believe it is an issue in Windows itself. Though it is bound to rather complex conditions, which is why it may not be seen in other apps. Except a very similar (but maybe different) issue exists in wordpad, where instead of ghost carets, the last line of text (before scrolling start) is repeated over and over, if the bottom of wordpad is off- screen. To trigger the issue conditions as mentioned below must be present. Since most editors, will simple invalidate the entire line (gutter, text and all), in those apps the issue never manifests. SynEdit attempts to be to clever. Yet that it works, if the caret is "on screen", indicates that it is meant to work.      To reproduce, the editor must have a visible gutter; and must not have "current line" highlight.      * The conditions to cause this:      - Caret must be in part of editor that is outside the screen.      - Caret must be destroyed (maybe only hidden?), or ScrollWindowEx must affect caret      - Caret must be in a part of the editor for which NO call to "invalidate" was made,        but which will be repainted. (repaint uses the minimum rect enclosing the combination of *all* invalidates)        E.g. the gutter, but not the line area received an invalidate, and another line above/below was invalidated        (can happen through ScrollWindowEx). -> In this case the paint message receives a rect, that contains the caret,        even though the part containing the caret was never explicitly invalidated.      If this happens, while the caret is on screen (even if hidden behind another window/taskbar) then all works ok.      But if the caret was off screen, a permanent image of the caret will remain (once scrolled/moved into the screen area).      It seem that in this case windows does not update the information, that the caret became "invisible" when paint did paint      over it. So if the already overpainted caret, is later (by Windows) attempted to be hidden by a final "xor", then it actually      is made permanently visible. ---------------------------------------------------------------------- BrunoK · 2018-11-18 20:53 @Martin_fr In options, caret : (NotXor) + Black  -> Seems to works as the default cursor should. Maybe that might help figure out the problem. Will try your revision tomorrow. Thanks for your efforts. ---------------------------------------------------------------------- BrunoK · 2018-11-19 11:02 @Martin_fr 1° r59596 WORKS, thank you ! 2° Personal >SPECULATION< on potential change of behaviour in Windows 10 Your patch creates a (some_width by one_pixel_height) invalidated region. MAYBE, Windows 10 ignores empty rectangles and don't call WM_PAINT for empty rectangles. Note : I havent found anything browsing the net that would confirm this idea. I have modified .\lcl\interfaces\win32\win32winapi.inc for debugging to Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function TWin32WidgetSet.InvalidateRect(AHandle: HWND; Rect: PRect;  BErase: Boolean): Boolean;var  Flags: UINT;  ORect: TRect;begin  Flags := RDW_INVALIDATE or RDW_ALLCHILDREN;  if BErase then    Flags := Flags or RDW_ERASE;  if Rect <> nil then  begin    with Rect^ do                                    // ~bk dbg      if (Right<=Left) or (Bottom<=Top) then           // ~bk dbg        Right:=Right;                                // ~bk dbg  <- Breakpoint : frequently stops here    GetLCLClientBoundsOffset(aHandle, ORect);    OffsetRect(Rect^, ORect.Left, ORect.Top);  end;  Result := Boolean(Windows.RedrawWindow(aHandle, Rect, 0, Flags));end; // ~bk dbg  <- Breakpoint : frequently stops here does effectively stop quite frequently from SynEdit and co. Just my 2 cents ... ---------------------------------------------------------------------- BrunoK · 2018-11-19 11:16 Oh yes, I forgot to say it is really WINDOWS 10 specific and not due to recent changes because my Lazarus 1.4.4 + FPC 2.6.4 shows the same behaviour as my top post.