View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0037150||Lazarus||IDE||public||2020-05-28 19:49||2020-05-31 21:37|
|Reporter||Markus Müller||Assigned To||Martin Friebe|
|Fixed in Version||2.2|
|Summary||0037150: Cannot select a text with the mouse in source code editor if the FPDoc-Editor is active|
|Description||If the FPDoc-Editor is showing, and I want select a text by mouse, then the selection "hang"|
|Steps To Reproduce||1. Open the FPDoc Editor|
2. go to source code window
3. press and hold the left mouse button
4. select with the mouse some text
5. not the complete mouse-moved text is selected
|Additional Information||I think the FPDoc-Editor looks with a timer into the source code, then the mouse down selection is lost.|
The workaround is close the FPDoc-Editor window.
|Tags||No tags attached.|
|Fixed in Revision||r63249|
||To reproduce, it may be needed to wait some time with the mouse button down.|
Yes, it must be some very rare timing issue. I tested for many minutes using both GTK2 and QT5 bindings and could reproduce only once. When moving mouse back and forth, the FPDoc gets updated correctly even when selecting text.
Almost a non-issue.
Here a screen video how it works with and without activated FPDoc-Editor.
fMain is a pas file with a TForm
EleLa is the lpr projectfile
If a text is selected and the FPDoc Editor is activated, then a click into the selected text make a "Access Violation", see in the video.
This video is make with the SVN63247 from today.
I hope it helt to solve the problem. Thx.
||PS: The "access violation" error comes only sometimes, after OK, sometimes is lazarus closing, sometimes not. A Sometimes Bug.|
The problem occurs when the mouse move over or away from an identifier that has docs.
While the mouse creates the selection, the caret follows the mouse. And fpdoc follows the caret.
And fpdoc calls
Which leads to windows sending LM_CANCELMODE
And that clears the CaptureControl.
SynEdit (like other controls) captures the mouse, while the button is pressed. And it checks for that capture. So this cancels the selection process.
FpDoc may have more such calls, that could lead to loosing capture....
IMHO the best solution may not to update fpdoc, as long as the mouse is down in SynEdit.
Can you get a stacktrace of the Access violation?
Recompile the IDE with -gw -gl
Also eiter add -WC to get a console window (to see the trace),
or start the IDE with --debug-log=c:\file.txt
and get the trace from the log.
I was unable (so far) to get the access violation myself.
Fixed selection in r63249
Waiting for feedback on access violation, before resolving
Checked your fix with SVN r63249.
Now it works good. Thx a lot.
The access violatin have I never seen again. I think your change have fix this seconary problem, too.
|2020-05-28 19:49||Markus Müller||New Issue|
|2020-05-28 22:04||Martin Friebe||Assigned To||=> Martin Friebe|
|2020-05-28 22:04||Martin Friebe||Status||new => acknowledged|
|2020-05-28 22:04||Martin Friebe||LazTarget||=> -|
|2020-05-28 22:04||Martin Friebe||Note Added: 0123113|
|2020-05-28 22:37||Juha Manninen||Note Added: 0123114|
|2020-05-29 11:16||Markus Müller||Note Added: 0123126|
|2020-05-29 11:16||Markus Müller||File Added: BugID_37150.mp4|
|2020-05-29 11:21||Markus Müller||Note Added: 0123127|
|2020-05-29 17:47||Martin Friebe||Note Added: 0123130|
|2020-05-29 17:55||Martin Friebe||Note Added: 0123131|
|2020-05-29 17:55||Martin Friebe||Status||acknowledged => assigned|
|2020-05-29 18:53||Martin Friebe||Note Added: 0123132|
|2020-05-30 11:39||Markus Müller||Note Added: 0123145|
|2020-05-30 14:51||Martin Friebe||Status||assigned => resolved|
|2020-05-30 14:51||Martin Friebe||Resolution||open => fixed|
|2020-05-30 14:51||Martin Friebe||Fixed in Version||=> 2.2|
|2020-05-30 14:51||Martin Friebe||Fixed in Revision||=> r63249|
|2020-05-30 14:51||Martin Friebe||LazTarget||- => 2.2|
|2020-05-30 14:51||Martin Friebe||Widgetset||Win32/Win64 => Win32/Win64|
|2020-05-31 21:37||Markus Müller||Status||resolved => closed|