Hi,

A while back (weeks), the Edit ComboBox in the "Find in Files" dialog doesn't show text selection anymore. You can highlight the text with the mouse, but you don't actually see it highlighted.

Does anybody know if this has been reported already or fixed already? I tried to search the commit logs but did not find anything revealing. I'm using Lazarus IDE v0.9.27 r20903 with GTK2 widgetest.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Does anybody know if this has been reported already or fixed already?

I couldn't find any commit log regarding this, but I just updated to the latest r21094 and did a clean all & build, and the problem is fixed.

Sorry for all the noise. ;-)

Regards,
- Graeme -

Graeme Geldenhuys wrote

I couldn't find any commit log regarding this, but I just updated to the latest r21094 and did a clean all & build, and the problem is fixed.

Correction, it worked the first time, but now it's back to the same old problem. :-(
Text selection is not shown in any of the EditCombo components in the "Find in Files" dialog.

Regards,
- Graeme -

It has been mentioned before by at least two person on IRC. I asked to create bug reports, but I don't know if they actually did.

Vincent

Vincent Snijders wrote

It has been mentioned before by at least two person on IRC. I asked to create bug reports, but I don't know if they actually did.

Ok thanks. Now at least I know it is not just my PCs (work & home laptop).

Strange thing is, it is *only* in the "Find in Files" dialog. All other dialogs with TEdit and EditCombo boxes work fine.

I'll double check in Mantis to see if there is a bug report, otherwise I will created one. I'll also see if I have the time today at work, to do a regression test to see in which revision it broke.

Regards,
- Graeme -

It is the auto completion. It undoes all selections. As workaround you can disable it with the button to the right.

Mattias

That's what I thought, but a small test project with the exact same TComboBox setup as in the "Find in Files" .lfm file - my test project worked. I noticed the issue is in the standard "Find..." dialog as well.

Thanks to 'git bisect' and 11 recompiles of Lazarus IDE, I found the revision causing the issue.

So from the bisect results, it is r19936 that causes the issue. I'll file a bug report with this information.

Looking at the r19936 I can't see anything obvious that could cause the error, but I double checked. r19935 works and r19936 doesn't, so it is definitely that commit.

=========[ bisect result ]===================
0ac4dda5116fa60fec59470dd3743ee922b8fb59 is first bad commit commit 0ac4dda5116fa60fec59470dd3743ee922b8fb59
Author: paul
Date: Tue May 12 05:23:55 2009 +0000

lcl: request Font and Color update after DestroyWnd call to properly restore them after new Handle creation (fixes issue #0011935)

git-svn-id: http://svn2.freepascal.org/svn/lazarus/trunk at 19936 4005530d-fff6-0310-9dd1-cebe43e6787f

:040000 040000 c157ba1f5901e9cc781d7476c79df85f62ac577d f5e8810f6477d02bb579d4b6f80cb3870dda121f M lcl
==============================

Regards,
- Graeme -

Mattias Gaertner wrote

It is the auto completion. It undoes all selections. As workaround you can disable it with the button to the right.

I can also confirm (a second time) that it is *not* the auto completion. Disabling it in the "Find..." dialog does not make a difference. Not to mention that the "Find in Files.." dialog doesn't have a disable auto-completion button.

Regards,
- Graeme -

Graeme Geldenhuys wrote

tried to search the commit logs but did not find anything revealing. I'm using Lazarus IDE v0.9.27 r20903 with GTK2 widgetest.

Reported the bug in Mantis.

http://bugs.freepascal.org/view.php?id=14270

Regards,
- Graeme -

You need to put a combobox on a form, show that form modally twice.

I committed a fix in r21102. Paul hinted he fixed a similar thing for TEdit, I found that in r20127. Now I wonder how for many other components the SetColor needs to be adjusted too.

IMHO r19936 exposed a bug in the SetColor methods in the interface. But I do wonder if it is correct that we call SetColor in the interface if the color is the default color. So maybe the wcfColorChanged flag should only be set, if the color is not the default color.

Vincent

Vincent Snijders wrote

I committed a fix in r21102. Paul hinted he fixed a similar thing for

Thanks, I'll update and test later today.

TEdit, I found that in r20127. Now I wonder how for many other components the SetColor needs to be adjusted too.

Good question.

interface if the color is the default color. So maybe the wcfColorChanged flag should only be set, if the color is not the default color.

This sounds logical to me too.

Regards,
- Graeme -