Well, I could make a caret but I still have a few more questions before change the topic to solved.
I'd like to know why if i use showCaret(handle) on SetFocus doesn't work and it works on WndProc instead.
Well in the end this is a Windows function. So who knows what the team at MS thought...
However
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showcaretShowCaret shows the caret only if the specified window owns the caret, the caret has a shape, and the caret has not been hidden two or more times in a row. If one or more of these conditions is not met, ShowCaret does nothing and returns FALSE.
Now first of all, when you get the Focus, has the call to CreateCaret already been made? And with the correct handle?
And are you sure no other control on your form has taken the caret (there can be only one)?
For all else, its reading MS docs, and try and error.
In SynEdit I did put the following line at the start of WM_SetFocus
DestroyCaret; // Ensure recreation. On Windows only one caret exists, and it must be moved to the focused editor
I do not remember the exact reason. Could be that indeed, this is only because another component (that had focus before) may own it at that time....
Something else... At some point in the past there was a bug in Windows itself (it affected several editors not related to Lazarus).
I have no idea if that still is an issue.
Using ScrollWindowEx, could under very specific circumstances leave artefacts of the caret on the screen.
If it is still an issue....
Back then I added the following note. (you can git blame SynEdit.pas, find the commit, and see what changes where done).
Most of the conditions are such, that in SynEdit the line-text does not need to be repainted, but can be just scrolled. If the area is repainted, then the ghosts are overpainted too.
In current SynEdit it can NOT be reproduced, since the workaround is applied.
(* * On Windows 10 there is an issue, where under certain conditions a "ghost" of the text caret remains visible.
That is one or a series of vertical black lines remain on the screen.
* This can be reproduced, by moving part (eg bottom) of editor off screen (not just behind the taskbar, but
off screen). Then press caret down to scroll. Ghost carets will scroll in with the new text.
Similar move caret to a place off-screen, unfocus editor, and refocus by clicking into the editor (move caret
while setting focus).
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.
- Carte 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.
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.
As a solution, in the above conditions, the full line (actually the text part with the caret) must be invalidated too.
Since this is hard to track, the workaround will invalidate the full line, in any case that potentially could meet the
conditions
*)