Debugging TListView under GTK

[Mike.Cornflake]

G'day,

there are two outstanding items in the Bugtracker I'm interested in using as the basis for my learning curve with GTK API's and LCL development. 

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

It's going to be a couple of weeks before I get started unfortunately - work takes all the fun out of life :-)  In the meantime, don't suppose anyone has any quick tips or links they'd like to share?  Finding the GTK documentation should be easy enough - Google will help there.  I'm assuming there's an equivalent to MSDN in the GTK world :-)  Just wondering what the obvious pitfalls, areas of poor documentation etc are.   

Cheers

Mike

[felipemdc]

The Gtk docs are here: http://www.gtk.org/documentation.php

The docs which explain how to implement parts of the LCL are here: http://wiki.lazarus.freepascal.org/LCL_Internals

Good luck!

[Mike.Cornflake]

Looking forward to it :-)   Many thanks for the links.

[Mike.Cornflake]

Well, that was unsatisfactory :-(  Found the problem, and I know what to do to resolve it, but if I do it, I'm undoing someone's fix for a completely different problem. 

I've posted my findings at http://bugs.freepascal.org/view.php?id=19806, and hopefully someone will be able to tell me what the original problem was so I can see if I find the correct solution for my problems (and hopefully the other problem at the same time).

[Dick, from the internet]

Hey Mike - Glad to see you working this issue so aggressively.  I just posted a problem with the TListView this afternoon see it here:  http://mantis.freepascal.org/view.php?id=19816

 You certainly have given me a couple things to think about myself, and I will start looking a little deeper on them in the a.m.

  BTW - check the URLs that you are posting - change the 'bugs' to 'mantis' otherwise a blank page opens up; just a friendly FYI

I'll be watching this thread for further developments - happy hunting!

 geno.

[Mike.Cornflake]

:-)  Thanks for the heads up on the URLs, I'll do that in future...

Heading over to see your issue now.  Unfortunately I'm working at sea at the moment, so I'm only coding during off-hours.  If I don't get to look at your issue now, I'll have a look in two weeks when I'm back home.

[Mike.Cornflake]

Just downloaded your project, I'll have a go - but I'm not promising anything - graphics were always my weakest code - find copy/paste other code most of the time :-)

[Mike.Cornflake]

Oh, also.  I'm not a "developer" as far as Lazarus sourcecode goes, just a "reporter"  If I do find anything useful, we'll need to find someone higher up the foodchain to submit it to :-)

[Dick, from the internet]

Just downloaded your project, I'll have a go - but I'm not promising anything - graphics were always my weakest code - find copy/paste other code most of the time :-)

I appreciate any insights you have here, but I wasn't trying to dump something in your lap, it was more an FYI in case you ran up against this issue in one of your apps, or maybe even could be (very unlikely) linked to the problems you are working on.  But thank you anyway.

Oh, also.  I'm not a "developer" as far as Lazarus sourcecode goes, just a "reporter"  If I do find anything useful, we'll need to find someone higher up the foodchain to submit it to :-)

Yeah, I kinda figured that you were just another 'Joe' like me, just you seem to have a little more experience digging into these issues.  I am not a 'serious' developer, it is more of a hobby, but now that I am retired I like to spend all the time I can doing things I never had time for in the past, such as  spending more time looking at the inner workings of the IDE.

 regards,
    geno.

[Dick, from the internet]

  I just read your post on the bugtracker and thought maybe I should try to clarify what I am attempting.

  If you put this same code into a TTreeView object, the results are exactly as expected; well almost.  TTreeView under Linux correctly changes the .Canvas.Font.Style, however, it does not render the .Canvas.Font.Color

Code: [Select]

procedure TForm1.TreeView1AdvancedCustomDrawItem(Sender: TCustomTreeView;
  Node: TTreeNode; State: TCustomDrawState; Stage: TCustomDrawStage;
  var PaintImages, DefaultDraw: Boolean);
begin
  if (pos('Van', Node.Text) > 0) then
     begin
       TreeView1.Canvas.Font.Style := [fsBold,fsItalic];
       TreeView1.Canvas.Font.Color := clRed;
     end
  else
    begin
      TreeView1.Canvas.Font.Style := [];
      TreeView1.Canvas.Font.Color := clBlue;
    end;
end;

  If I use this code in Lazarus under WinXP; still using GTK2, it will render correctly in both TTreeView and TListView.

  The next issue is when attempting to place a graphic on the control.  I use this code to embed a .jpeg image at the bottom portion of the TTreeView and TListView.

Code: [Select]

procedure TForm1.TreeView1AdvancedCustomDraw(Sender: TCustomTreeView;
  const ARect: TRect; Stage: TCustomDrawStage; var DefaultDraw: Boolean);
begin
  TreeView1.Canvas.Draw(50,175,tstIcon);
end;

procedure TForm1.ListView1AdvancedCustomDraw(Sender: TCustomListView;
  const ARect: TRect; Stage: TCustomDrawStage; var DefaultDraw: Boolean);
begin
  TreeView1.Canvas.Draw(50,175,tstIcon);
end;


  As you can see in the image, this almost works as expected (the .Font.Color issue) in TTreeView (the control on the right; TListView is on the left) however not in TListView.  Of course, both Lazarus and Turbo Delphi under WinXP produce the expected results.

  In some of the trial runs, such as the code posted on bugtracker, I noticed that the text or images were drawn with the X,Y coordinates relative to the TListView, however, it seemed that it was placed on the TForm canvas - probably mistaken, but that is what is acted like.

  It is because of the difference in behaviour between the Linux and WinXP environments that I feel it may be a bug issue.  Of course, as I stated before, I am merely a hobby programmer and not so well versed in the inner workings of all the controls; maybe it is an 'undocumented feature' and is meant to work that way <grin>

  I hope this clears the issue a little better.  Again, thanks for the feedback.

  geno.

[Mike.Cornflake]

G'day Fleshmang,

In the example you posted on the BugTracker, you put some drawing code inside a Button.OnClick, not in the Control.OnAdvancedDraw, that's why it's appearing on the Form.  From outside of a control's paint event (in this case OnAdvancedDrawXXX) the Control Canvas is not supposed to be accessed.   (Yup, I know you can in Windows, but you have no control over the persistence of what you've painted)

I suspected this functionality is what you were after, and spent the day hunting down another bug (already open in the bugtracker so no need to raise a new one).  For GTK2 and Carbon widgetsets TListView.OnAdvancedDraw is never called, only the OnAdvancedDrawitem.   I suspect this is why you moved your code into a button click.  OnAdvancedDrawItem will not achieve what you want to achieve - having only a limited render area supplied.  (OnAdvancedDraw is simply not implemented, so before you try currently there is nothing you can do using the control - there is a //TODO comment in the OwnerDraw property)

Haven't looked at the TTreeView side of things, only the TListView side...  Within GTK they're actually the same control though, so I suspect the same issue will occur on both.   You've given me an idea though - if OnAdvancedDraw is already implemented in TTreeView, then all I need to do is have a look in there and see how its implemented there...   That'd be nice if that's the case :-)

Just letting you know, having a look around the code for GTK2 TListView there's more than a few //TODO items in there.    Most of them are for the whistles and bells side of things (Implementing Hover for instance - never my favourite feature so this doesn't upset me :-) ).  Getting the OnSelect officially fixed, implementing the OnAdvancedOwnerDraw and implementing Icon Drawing in the header are the ones I care about most :-)

Unfortunately, after three days of little work, we're about to start a busy period, so my output here will drop...

[Dick, from the internet]

Howdy Mike:

In the example you posted on the BugTracker, you put some drawing code inside a Button.OnClick, not in the Control.OnAdvancedDraw, that's why it's appearing on the Form.  From outside of a control's paint event (in this case OnAdvancedDrawXXX) the Control Canvas is not supposed to be accessed.

Thanks for that info.  I know it looks strange with the code inside the OnClick event, however the Controls paint  method should still be called to update the canvas.  Yes, there is no persistence, as clicking on the form  or even moving another window across it erases any text or image.  However, I once again compare it to the TTreeView where it performs as expected, and as you stated, they (TTreeView and TListView) are essentially the same control.

I suspected this functionality is what you were after,

This is actually not the functionality I am after, I just see it as another symptom of the overall problem.  I am able to place persistent images on the TTreeView and change them as I scroll through the nodes exactly as I want, however, I do not want or need TTreeView, I need the TListView, thus my persistence <grin>

ust letting you know, having a look around the code for GTK2 TListView there's more than a few //TODO items in there.

Where exactly are you finding this information; is it the LCL source or the GTK2 docs?  I have been spending some time just following the declarations and headers from the Graphics unit, and the listview* .inc files etc and then trying to correlate to the TTreeView side to see how the properties are defined or implemented to find a difference between the two; thinking maybe it was something just left out for one reason or other.  e.g. the problem you posted yesterday

Well, that was unsatisfactory :-(  Found the problem, and I know what to do to resolve it, but if I do it, I'm undoing someone's fix for a completely different problem.

Getting the OnSelect officially fixed, implementing the OnAdvancedOwnerDraw and implementing Icon Drawing in the header are the ones I care about most :-)

Well, that will certainly benefit many of us, so I applaud your efforts, Sir!!

regards,
  geno.

[Mike.Cornflake]

The sourcecode for the GTK2 list view is inside GTK2CustomListView.inc (On my notebook /usr/lib64/lazarus/lcl/interfaces/gtk2/gtk2customlistview.inc).  In order to step inside it, I needed to rebuild my LCL (Lazarus - err Tools I think - Configure Build Lazarus).  Just select LCL Clean and Build, turn the others off.  Untick restart IDE after rebuild.  In the options edit box type "-gl" (without the quotes) then hit Rebuild.  If all went well, you should now be able to step inside the LCL.  Hopefully I didn't miss anything, that was all off the top of my head so some items may be named slightly differently.  Took me a little playing to get that far - the wiki drops down to the command prompt and has you firing off make commands, and I keep forgetting to make a copy of that page :-)  (Internet on this boat and my notebook are not connected).  Have fun in there :-)   The links that Felipe posted earlier proved invaluable in discovering the GTK world.  In particular there's a tutorial on that site that's well written (and which I'm still going through).

With regards to drawing on a canvas outside of a controls paint - the issue is what you draw should only remain on the screen UNTIL the Paint (or AdvancedDrawXXX) event is fired, then the Paint code will overwrite your efforts.  The windows manager in your OS is responsible for telling controls when to repaint (and which bits to repaint) - the paint won't - or shouldn't - remember what was already on the control, it'll only draw what it's code tells it to.  The entire reason we have a TPaintBox (or we do in Delphi - you know I've never looked for this in Lazarus) is so we have a control with an easily accessible OnPaint event.    This should be very easily confirmed by a simple form with a button.  In the button onclick draw on the Forms canvas directly.  Now position another window over half your drawing.  Now move that window away.  Half your drawing has vanished, because when the OS told your form to repaint the section of your form that was covered, the forms Paint code know nothing about what you've put on the canvas.   If we do have a TPaintBox, then now drop that on that form, move your painting code so it's in the TPaintBox OnPaint (and change it so it's drawing on the PaintBox canvas), and repeat the previous exercise.  This time your drawing will remain no matter what you do to the form.  This is why we need the OnAdvancedDraw event implemented in TListView, so we have a place to put code that draws stuff we always want to be there.

You know, I really envy people who can make succinct points :-(  Sorry for waffling on, and thanks for bearing with me :-)

With regards to the fix I posted for the OnSelect issue, I've confirmed that commenting out those two lines re-introduces the SSGIV (or whatever the letters are :-) ) error on a double click in a multi select list view.  Rats :-)   When I get time I'll try to work on a resolution to that original error.

Well, that will certainly benefit many of us, so I applaud your efforts, Sir!!

I haven't achieved anything yet, but many thanks :-)