Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2003-11

Patch for searchresults dialog

19 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Tony Maro
to Vincent Snijders
Bob Wingard wrote 8 lines
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?

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

Reply by email

Mattias Gaertner
to Vincent Snijders: 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

Reply by email

Tony Maro
to Vincent Snijders: Attached patch solves some issues with the find in files search results dialog. - Some…
Bob Wingard wrote 7 lines
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.

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

Reply by email

Bob Wingard
to Vincent Snijders: 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

Mattias Gaertner wrote 104 lines
On Sat, 22 Nov 2003 08:54:29 -0600 Bob Wingard wrote: > 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 > > 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;//LazLBMousemove > > On Fri, 2003-11-21 at 21:33, Bob Wingard wrote: > > 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 > > > > On Thu, 2003-11-20 at 19:27, Mattias Gaertner wrote: > > > On Thu, 20 Nov 2003 22:49:42 +0100 Vincent Snijders > > > wrote: > > > > > > > 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. > > > > > > Applied. Thanks. > > > > > > Mattias > > > > > > _________________________________________________________________ > > > To unsubscribe: mail with > > > "unsubscribe" as the Subject > > > archives at http://www.lazarus.freepascal.org/mailarchives > > _________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Mattias Gaertner
to Vincent Snijders: 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

Show quoted text 89 lines
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;//LazLBMousemove On Fri, 2003-11-21 at 21:33, Bob Wingard wrote: > 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 > > On Thu, 2003-11-20 at 19:27, Mattias Gaertner wrote: > > On Thu, 20 Nov 2003 22:49:42 +0100 Vincent Snijders > > wrote: > > > > > 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. > > > > Applied. Thanks. > > > > Mattias > > > > _________________________________________________________________ > > To unsubscribe: mail with > > "unsubscribe" as the Subject > > archives at http://www.lazarus.freepascal.org/mailarchives _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Bob Wingard
to Vincent Snijders: Attached patch solves some issues with the find in files search results dialog. - Some…
Tony Maro wrote 23 lines
Bob Wingard wrote: > 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? > > 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.

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.

Show quoted text 15 lines
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

Reply by email

Bob Wingard
to Vincent Snijders: 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

Mattias Gaertner wrote 20 lines
On Thu, 20 Nov 2003 22:49:42 +0100 Vincent Snijders wrote: > 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. Applied. Thanks. Mattias _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

-------------- 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

Reply by email

Bob Wingard
to Vincent Snijders: 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;//LazLBMousemove
Bob Wingard wrote 57 lines
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 On Thu, 2003-11-20 at 19:27, Mattias Gaertner wrote: > On Thu, 20 Nov 2003 22:49:42 +0100 Vincent Snijders > wrote: > > > 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. > > Applied. Thanks. > > Mattias > > _________________________________________________________________ > To unsubscribe: mail with > "unsubscribe" as the Subject > archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Tony Maro
to Vincent Snijders: Attached patch solves some issues with the find in files search results dialog. - Some…
Andrew Johnson wrote 14 lines
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

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

Reply by email

Andrew Johnson
to Tony Maro: 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

Tony Maro wrote 30 lines
> -----Original Message----- > From: Andrew Johnson > > 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. > 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 _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Andrew Johnson
to Vincent Snijders: 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

Tony Maro wrote 34 lines
Andrew Johnson wrote: >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 > > 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 used at all. In 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 used at all. Anything you want me to look for? -Tony _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Tony Maro
to Andrew Johnson
Show quoted text 17 lines
-----Original Message----- From: Andrew Johnson 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.

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

Reply by email

Andrew Johnson
to Vincent Snijders: 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

Tony Maro wrote 45 lines
Bob Wingard wrote: > 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. > > 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 _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Tony Maro
to Tony Maro: Maybe I said it backwards, but whatever color I pick results in a pixel equal to zero, so…
Andrew Johnson wrote 35 lines
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

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);

Reply by email

Tony Maro
to Tony Maro: 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...

Tony Maro Systems Consultant The Maro Group (256) 337-5759 http://www.maro.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: bin00084.bin Type: application/octet-stream Size: 2295 bytes Desc: "lazarus.diff.gz" Url : http://localhost/pipermail/lazarus/attachments/20031123/545804b3/bin00084.bin

Reply by email

Bob Wingard
to Vincent Snijders: Attached patch solves some issues with the find in files search results dialog. - Some…
Mattias Gaertner wrote 33 lines
On Sat, 22 Nov 2003 10:22:21 -0600 Bob Wingard wrote: > 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

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

Reply by email