Attached patch solves some issues with the find in files search results dialog. - Some…
Show quoted text 8 lines
Applied. Thanks.
Mattias

Mailing lists / lazarus / 2003-11
19 messages · 5 people ·
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Attached patch solves some issues with the find in files search results dialog. - Some…
Applied. Thanks.
Mattias
Hi,
Attached patch solves some issues with the find in files search results dialog.
- Some memory leaks.
- Clarified comment a bit.
- Access Violation when clicking on a search result.
Regards,
Vincent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gz00046.gz
Type: application/octet-stream
Size: 1340 bytes
Desc: "findinfiles.patch.gz"
Url : http://localhost/pipermail/lazarus/attachments/20031120/54c2de9e/gz00046.obj
I've had this problem for a bit and suffered through it. Someone (was it Andrew?) mentioned it was a broken GTK theme, but I can't find any way of fixing it. All statictext and my own custom controls that use clBtnFace are showing as black rather than my theme's color (a nice light grey.)
If I close KDE and open Gnome, it's fine.
I've tried telling Mandrake to "apply colors to non-KDE applications" for my KDE theme which is supposed to affect the GTK theme. I've tried making a .gtkrc file that points to a theme I know works. I've also tried multiple KDE themes with the checkbox mentioned checked.
But, I think it's interesting to note that I _DO_ have Gnome installed, and I can log out of KDE and into Gnome and it's fine. I also have no other GTK apps with this problem.
The other thing I noticed was that it's not consistant. It's about 95% of the time that it's showing black, but sometimes, even without a rebuild, it shows up fine.
Attached is an image showing the designer view of a tstatictext, with the running application on top of it. Notice the designer view does fine.
I'll download CVS to get your fix to clWhite, but it'd be nice to know why this is happening.
-Tony Maro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jpg00003.jpg
Type: application/octet-stream
Size: 11168 bytes
Desc: ""
Url : http://localhost/pipermail/lazarus/attachments/20031122/82827724/jpg00003.obj
Attached patch solves some issues with the find in files search results dialog. - Some…
Mattias, I looked at the TODO list for the searchresults on the Lazarus web page. What would you like the find identifier function to do?
Example:
User points source editor caret on an identifier. The function "Find Identifier" (or maybe we should call it "Find References"?) will search the definition and then all places, where this identifier is used.
The search result window will show all the results.
After this the next step is "Rename identifier":
The user gives a new name. The IDE automatically checks every found reference for conflicts with the new name. This will result in a list of conflicts. (Also shown in the search result window: a flag). If there are no conflicts, or the user forces the renaming, all found identifiers will be renamed.
The first step is to extend the find in files dialog. We need to search in:
- all project files. Including files in a search path (e.g. unit path).
- all files of a package
- all files of all depending packages
- a combination of the above
The next step is to extend the file selection of the "Find In Files", so that it can be reused by "Find Identifier" function.
Mattias
Attached patch solves some issues with the find in files search results dialog. - Some…
Remember I'm a GTK noob, but maybe this will help. I pulled some GTK theme info from within my app and did some testing.
Inside GetSysGCValues (from GTKProc.inc,) the color is set to the CORRECT value using:
Result.foreground := Style^.bg[GTK_STATE_NORMAL];However, it reaches the following code at the end of that routine and zero's the value:
if (style nil) then
if (style^.colormap nil) then
gdk_colormap_query_color(style^.colormap,result.foreground.pixel,@result.foreground)
else
gdk_colormap_query_color(gdk_colormap_get_system(),result.foreground.pixel,
@result.foreground);I looked up the gdk_colormap_query_color function and found this on Gnome's site:
"This function is rarely useful; it's used for example to implement the eyedropper feature in GtkColorSelection
<http://developer.gnome.org/doc/API/2.0/gtk/GtkColorSelection.html>."
So I have no idea what the goal is with it...
If I add an exit after the Result.foreground line, everything works great. But, I dunno what else this might break...
-Tony
Attached patch solves some issues with the find in files search results dialog. - Some…
Mattias,
I looked at the TODO list for the searchresults on the Lazarus web page. What would you like the find identifier function to do?
Bob
Attached patch solves some issues with the find in files search results dialog. - Some…
Mattias, I found a small problem after I sent you the patch. Replace the LazLBMousemove routine in SearchViewResult.pp with this to correct it.
Applied.
Thanks.
Mattias
Attached patch solves some issues with the find in files search results dialog. - Some…
I am running Mandrake 9.2 and have not seen the problem yet and I have tried several themes. I have not downloaded any additional themes so I am just using the stock KDE themes installed with Mandrake. I spend most of my time in Gnome rather than KDE. I will run KDE for a few days and see if I can re-create the problem.
Attached patch solves some issues with the find in files search results dialog. - Some…
Mattias,
Pretty big patch here, for me anyway :)
1. Cleaned up the find in files routines in Uniteditor.pp
2. Implement Search Again button on SearchResultsView form.
3. Added Highlighting of the search phrase in the Results List box.
4. Added a tool tip to the list box to show the search result if the result is wider than the list box width.
I have a couple of questions.
It looks like the list box is not taking the vertical scroll bar width into account when deciding whether or not to show the horizontal scroll bar. Some times text is in the list that is just wider than the width of the client area in the list box but the scroll bar is not displayed. If you resize the list box smaller then the scroll bar will be visible. I looked through the code but could not determine where this is taking place, any help?
I would get the list box to stop drawing twice when it's style is set to ownerdrawn, again not sure where to start.
Vincent,
Thanks for your help.
I was not able to duplicate the Black on Black text that you saw in KDE yesterday. Look at it now, I explicitly set the canvas.color to clWhite. I think I remember seeing somewhere in the code that, but I cannot find it now, that some of the colors are loaded from user preference. Maybe if Gnome is not running this is where the problem happens. Mattias?
Regards,
Bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00046.zip
Type: application/octet-stream
Size: 10791 bytes
Desc: "findinfiles.diff.zip"
Url : http://localhost/pipermail/lazarus/attachments/20031121/28eecf67/zip00046.obj
Attached patch solves some issues with the find in files search results dialog. - Some…
Mattias,
I found a small problem after I sent you the patch. Replace the LazLBMousemove routine in SearchViewResult.pp with this to correct it.
Bob
{Keeps track of the Index of the Item the mouse is over, Sets ShowHint
to true
if the Item length is longer than the Listbox client width.}
procedure TSearchResultsView.LazLBMousemove(Sender: TObject; Shift:
TShiftState;
X, Y: Integer);
begin
if Sender is TLazSearchResultLB then
begin
with Sender as TLazSearchResultLB do
begin
fMouseOverIndex:= GetIndexAtY(Y);
if (fMouseOverIndex > -1) and (fMouseOverIndex < Items.Count) then
begin
if (Canvas.TextWidth(Items[fMouseOverIndex]) > Width) then
ShowHint:= True
else
ShowHint:= False;
end;//if
end;//with
end;//
end;//LazLBMousemoveAttached patch solves some issues with the find in files search results dialog. - Some…
Well, this causes bug #153, #94 and another one or two other reports I've see on the list.
The style^.colormap is not nil and the foreground.pixel value returned by these is zero, when it's btnface or anything - and it works flawlessly on my system making me wonder if that's being fact, this isn't used until the theme is actually used to draw the data on the screen, correct? And since on mine, the pixel is always zero, I'm guessing it's not being you want me to look for?
-Tony
Maybe I said it backwards, but whatever color I pick results in a pixel equal to zero, so…
I think you are correct and I am a moron. I am mixing up functions in my head, which is probably what happened when I added that code.
At this function if invalid it should be _allocating_ a color not querying for one.
so it should be, if invalid pixel, allocate, else, query.
so it should look something like -
if (result.foreground.pixel = 0) and ((result.foreground.red 0) or (result.foreground.blue 0) or (result.foreground.green 0)) then begin
if (style nil) and (style^.colormap nil) then
gdk_colormap_alloc_colors(style^.colormap, @result.foreground, 1,false, true, nil);
else
gdk_colormap_alloc_colors(gdk_colormap_get_system(), @result.foreground, 1, false, true, nil);
end else
if (style nil) and (style^.colormap nil) then
gdk_colormap_query_color(style^.colormap,result.foreground.pixel,@result.foreground)
else
gdk_colormap_query_color(gdk_colormap_get_system(), result.foreground.pixel, @result.foreground);
so please test this out. later today I will look ad test myself, and if it works for everything I will commit a fix.
Andrew
Attached patch solves some issues with the find in files search results dialog. - Some…
Coul you try adding a test? This will not work for gtk2 because gtk2 is different but if you add a test that does something like this -
if (result.foreground.pixel = 0) and ((result.foreground.red 0) or (result.foreground.blue 0) or (result.foreground.green 0)) then if (style nil)
.....
it _might_ fix it for when the color already has a valid pixel.
which sounds like in this case it is.
Andrew
Maybe I said it backwards, but whatever color I pick results in a pixel equal to zero, so your conditional would always run. Also, I thought the code you're asking to wrap this in would take a pixel and turn it into RGB, not the other way around... Since my pixel is invalid (0) it wipes the RGB value. Am I reading this backwards?
-Tony
Attached patch solves some issues with the find in files search results dialog. - Some…
this shouldn't be a problem. theoretically the bg will always have a valid rgb value, but it will not always have a valid pixel.
gc's must have a color with a valid pixel, so we query just in case. I have no idea why the gc would not be initialized or might be being queried wrong, but it certainly sound a bit odd.
I am guessing sometimes in kde the colormap passed is not the right one or some such wierdness so querying fails.... but I don't know for sure. cause it works for me fine when I tried to go into kde so...
Andrew
Maybe I said it backwards, but whatever color I pick results in a pixel equal to zero, so…
Close. You can't pass nil as the success variable to gdk_colormap_alloc_colors. After fixing that it works great, fixes the build Lazarus dialog, static text, clBtnFace, etc...
Try this. Add:
Var
success: Boolean;...snip...
if (result.foreground.pixel = 0) and ((result.foreground.red 0) or
(result.foreground.blue 0) or (result.foreground.green 0)) then
begin
if (style nil) and (style^.colormap nil) then
gdk_colormap_alloc_colors(style^.colormap, @result.foreground, 1,
false, true, nil)
else
gdk_colormap_alloc_colors(gdk_colormap_get_system(),
@result.foreground, 1, false, true, @success);
end else
if (style nil) and (style^.colormap nil) then
gdk_colormap_query_color(style^.colormap,result.foreground.pixel,
@result.foreground)
else
gdk_colormap_query_color(gdk_colormap_get_system(),
result.foreground.pixel, @result.foreground);Maybe I said it backwards, but whatever color I pick results in a pixel equal to zero, so…
Here's a diff to fix the rest of the GTK color problems. In addition to the fixes Mattias put in for some specific controls, this will fix the rest of the black colors like clHighlight...
Maybe I said it backwards, but whatever color I pick results in a pixel equal to zero, so…
Here's a diff to fix the rest of the GTK color problems. In addition to the fixes Mattias put in for some specific controls, this will fix the rest of the black colors like clHighlight...
Applied. Thanks.
But it does not fix all the rest of the black colors (e.g. clBtnHighlight, clBtnShadow). So, keep fixing. :)
Mattias
Attached patch solves some issues with the find in files search results dialog. - Some…
I will start looking into this some time this week, I have been covered up at work but will have some time over the next few days as we have a holiday coming up in the US.
Bob
_________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives