View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0028019||Lazarus||Packages||public||2015-05-03 18:56||2015-05-20 16:51|
|Reporter||BBaz||Assigned To||Martin Friebe|
|Target Version||1.4.2||Fixed in Version||1.4.1 (SVN)|
|Summary||0028019: [Synedit] caret partially drawn - need workaround in 1.4.1|
|Description||In lazarus 1.4, the Synedit caret is sometimes only partially drawn due to a clipping issue.|
If the refactored code related to the caret is not merged from trunk to 1.4.1, we need at least a temporar fix in the upcoming release 1.4.1.
ping for Martin_fr, cf forum discussion:
|Tags||No tags attached.|
|Fixed in Revision||49089|
||Please test with rev 49089 and close if ok.|
No, i'm really sorry but it's not fixed.
- Scroll back + zoom, the caret is still sometimes partially drawn.
- bad news: additonal symptom: after the scroll + zoom, i click to put the caret on another line and the previous caret persists like this: http://i.imgur.com/Wd0sirF.png (line 2891 is caret after scroll + zoom, line 2889 is caret after clicking).
I temporarily reverted the change made before.I was able to get a caret that had its upper and lower half blinking out of sync. I.E. when the upper half was visible, the lower was not. And vice versa.
This happens by mouse wheel scrolling / no zooming.
This half/half caret is probably a separate bug, that got revealed by fixing the wrong clipping.
When the clipping is reset, the OS (Windows) should delete the undersized caret. It seems it does not.
This issue may also still be present (not yet tested) in trunk, if you use SynEdit outside the IDE. (In the IDE it does not use the system caret).
As for your image.
The remaining caret is the same as the the half/half.
Windows draws the caret by inverting pixels. So the background never gets repainted.
At some point it seems it looses track, and thinks the caret is hidden, while it is not. Then when it moves, it inverts to visible.
Please test with 49114
Both are fixed now. Thx very much.
I have not tested the trunk so far. But if i see it again, eg during the next public 1.x beta stage, i'll won't esitate to report this time (yes, because i've noticed the bug during 1.4 RC2 but i wrongly thought it wasn't worth reporting because the problem seemed so obvious), anyway it's ok now.
||Trunk appears not to be affected after all.|
|2015-05-03 18:56||BBaz||New Issue|
|2015-05-03 20:25||Zeljan Rikalo||Assigned To||=> Martin Friebe|
|2015-05-03 20:25||Zeljan Rikalo||Status||new => assigned|
|2015-05-18 22:27||Martin Friebe||Fixed in Revision||=> 49089|
|2015-05-18 22:27||Martin Friebe||LazTarget||=> 1.4.2|
|2015-05-18 22:27||Martin Friebe||Note Added: 0083760|
|2015-05-18 22:27||Martin Friebe||Status||assigned => resolved|
|2015-05-18 22:27||Martin Friebe||Fixed in Version||=> 1.4.1 (SVN)|
|2015-05-18 22:27||Martin Friebe||Resolution||open => fixed|
|2015-05-18 22:27||Martin Friebe||Target Version||=> 1.4.2|
|2015-05-19 17:47||BBaz||Note Added: 0083798|
|2015-05-19 17:47||BBaz||File Added: prevpersists.png|
|2015-05-19 17:49||BBaz||Note Edited: 0083798||View Revisions|
|2015-05-19 17:51||BBaz||Status||resolved => assigned|
|2015-05-19 17:51||BBaz||Resolution||fixed => reopened|
|2015-05-19 23:44||Martin Friebe||Note Added: 0083811|
|2015-05-20 01:49||Martin Friebe||Note Added: 0083813|
|2015-05-20 01:49||Martin Friebe||Status||assigned => feedback|
|2015-05-20 09:02||BBaz||Note Added: 0083817|
|2015-05-20 09:02||BBaz||Status||feedback => assigned|
|2015-05-20 11:01||BBaz||Note Edited: 0083817||View Revisions|
|2015-05-20 15:16||Martin Friebe||Note Added: 0083826|
|2015-05-20 15:16||Martin Friebe||Status||assigned => resolved|
|2015-05-20 15:16||Martin Friebe||Resolution||reopened => fixed|
|2015-05-20 16:51||BBaz||Status||resolved => closed|