Lazarus

Announcements => Third party => Topic started by: LuizAmérico on February 19, 2011, 01:21:11 am

Title: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on February 19, 2011, 01:21:11 am
I'm glad to announce the update of the VirtualTreeView package.

It's compatible with Lazarus 0.9.30 and later. Users of Lazarus 0.9.28 must use version 4.8.6

What's new:

  * Synchronized with Delphi version (http://code.google.com/p/virtual-treeview/) up to revision 263 of 4.8 branch
  * DefaultText can be set to ''
  * Fix GetNodeAt when using client coordinates with the header visible
  * Avoid warning when inline edit control is hidden
  * Minimize dependency on LCLExtensions
  * Add changes to make compatible with recent LCL versions

Known issues:

    * It does not work on 64bit
    * Not tested with Carbon/MacOSX, WinCE

It depends of LCLExtensions package (http://code.google.com/p/luipack/).

Download the package at Lazarus-CCR (VirtualTreeView (NewPort) (https://sourceforge.net/projects/lazarus-ccr/files/VirtualTreeView%20%28New%20Port%29/)).
Title: Re: VirtualTreeView 4.8.7 released
Post by: cpalx on February 19, 2011, 03:27:54 am
Thanks a lot,

i can test it on mac ... i will tell you how it goes
Title: Re: VirtualTreeView 4.8.7 released
Post by: IPguy on February 19, 2011, 03:53:36 am
Luiz,
what is considered 0.9.30?  Is the Lazarus fix snapshot (0.9.29-295xx) considered 0.9.30 or should this only be used with the 0.9.31 stream?
John
Update: at first compile and brief testing, it works with 0.9.29-29572-win32.
Title: Re: VirtualTreeView 4.8.7 released
Post by: eny on February 19, 2011, 12:16:57 pm
Thx for the update; first smooth install with no errors  8-)
And the background property again honours the clDefault value.
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on February 19, 2011, 12:45:54 pm
Quote
what is considered 0.9.30?  Is the Lazarus fix snapshot (0.9.29-295xx) considered 0.9.30 or should this only be used with the 0.9.31 stream?

In fact it should work with a recent 0.9.29 but as i cannot determine exactly the required revision i think better to set 0.9.30 as the minimum requirement. With this i hope to minimize the compatibility problems (see the 4.8.6 thread).
Title: Re: VirtualTreeView 4.8.7 released
Post by: Dibo on February 19, 2011, 03:15:32 pm
Are plans for 64 bit?
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on February 19, 2011, 04:01:10 pm
Quote
Are plans for 64 bit?

The trunk should work with 64bit (not tested by me)
Title: Re: VirtualTreeView 4.8.7 released
Post by: Dibo on March 19, 2011, 04:20:53 pm
Active svn link is still https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/virtualtreeview-new/trunk/ ?
Because this source need lclextensions but I read somewhere (on mantis?) that this pachage was included into LCL.
Package from trunk show that this is still 4.8.6 version.
Title: Re: VirtualTreeView 4.8.7 released
Post by: DirkS on March 19, 2011, 06:46:59 pm
Active svn link is still https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/virtualtreeview-new/trunk/ ?
It's https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/virtualtreeview-new/branches/4.8

Gr.
Dirk.
Title: Re: VirtualTreeView 4.8.7 released
Post by: Marc on March 21, 2011, 11:08:20 am
Because this source need lclextensions but I read somewhere (on mantis?) that this pachage was included into LCL.

I've integrated a part of it. The other part of lcl extensions were winapi functions implemented only for windows. Adding them to the LCL would mean that I had to implement the missing parts for wince/gtk/qt/carbon. So I postponed that attempt.
Title: Re: VirtualTreeView 4.8.7 released
Post by: Shebuka on June 30, 2011, 10:33:02 am
Hi, i'm now using VirtualTree as my main component for tree visualization (before i'v only used it as advanced list box XD ) and i'm discovering on Mac OS same bug as on all other components with multiselection due to fact that Mac OS X uses ssCtrl with Mouse Click as Right Mouse Click (so it call PopUp), for multiselection Mac OS X uses ssMeta and this means that in VirtualTree.pas i'v need to ifdef darwin all lines with ssCtrl, but i think that there is more cool way to do this, ifdef declare a constant like ssCtrlOS in witch put ssMeta if it's Mac and ssCtrl in other cases, and then in code use always ssCtrlOS :D what you think?
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on June 30, 2011, 11:51:11 am
Better.

Make a patch (please with only that modification) and send me.
Title: Re: VirtualTreeView 4.8.7 released
Post by: Shebuka on June 30, 2011, 03:43:09 pm
Better.

Make a patch (please with only that modification) and send me.
Here it is, i'v replaced all ssCtrl with ssCtrlOS so it must be tested to see if there is no conflicts with other functions
Title: Re: VirtualTreeView 4.8.7 released
Post by: Shebuka on July 05, 2011, 07:10:23 pm
Quote
Hi, i'm having very strange behaviour with enabled right click selection, multiselection and associated pop up.
If i right click on an item in the tree my pop up come out, then click on pop up item and when pop up disappears the mouse is in state as i'm still holding left mouse button... (so the mouse pointer is binded in that moment to make a selection with rect) as i still holding left mouse button, but i don't. Sometimes it after pop up disappears it is in drag drop state... As i click somewhere it resets to normal state.

btw. i'v tested that ssCtrlOS has nothing to do with this.

edit: Resolved, if you need to use toRightClickSelect then you MUST assign popup on runtime in OnGetPopupMenu and not at design time via PopupMenu property.
Title: Re: VirtualTreeView 4.8.7 released
Post by: Shebuka on July 06, 2011, 06:42:25 pm
Quote
Hi again, i'v found one tricky problem and don't really know how to fix it...
As i can see on Mac scrolling with Magic Mouse or with Trackpad call's WMVScroll and then WMHScroll, and sometimes (i think like every NodeHeight) it calls also CMMouseWheel.
When you use the Mouse Wheel of an external usb mouse it calls only CMMouseWheel.
First of all in WMXScroll, ScrollCode is allways SB_THUMBTRACK in which block tsThumbTracking is set, but SB_ENDSCROLL, in wich tsThumbTracking must be unset, is never called. This cause that when you Scroll by mouse wheel Scrollbars are never updated. To fix this i'v write at the end of DoSetOffsetXY DoStateChange([], [tsThumbTracking]);
But there is another problem... CMMouseWheel never invalidates VirtualStringTree's Rect, so when you scroll it's not updated until you click inside the Rect... So i'v putted an Invalidate at the end of CMMouseWheel XD and this works with CMMouseWheel as charm, but now when i scroll by Touchpad sometimes (look above, every NodeHeight) it calls Invalidate and whole scroll jumps for a sec to the top and then back...

Edit: Found the way to fix both of this, put it in CMMouseWheel:
Code: Pascal  [Select][+][-]
  1. procedure TBaseVirtualTree.CMMouseWheel(var Message: TLMMouseEvent);
  2. ...
  3.     with Message do
  4.     begin
  5. ...
  6. ...
  7. ...
  8.  
  9.       if (tsThumbTracking in FStates) then
  10.         DoStateChange([], [tsThumbTracking])
  11.       else
  12.         Invalidate;
  13.     end;
Title: Re: VirtualTreeView 4.8.7 released
Post by: Shebuka on July 06, 2011, 06:57:15 pm
Another problem related to CMMouseWheel and the latest Lazarus from Trunk (31572)

In new version of Lazarus 31572, SystemParametersInfo (in winapi.inc it's WidgetSet.SystemParametersInfo) points to carbonwinapi.inc in wich there is no case selector for SPI_GETWHEELSCROLLLINES so ScrollLines is always returned as 0 and you got no scrolling...

In Lazarus 30406, SystemParametersInfo was pointing to intfbasewinapi.inc which actually has selector for SPI_GETWHEELSCROLLLINES...

dunna know who must fix this, but for now this is my fix:
Code: Pascal  [Select][+][-]
  1. procedure TBaseVirtualTree.CMMouseWheel(var Message: TLMMouseEvent);
  2. ...
  3.           SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, @ScrollLines, 0);
  4.           if ScrollLines = WHEEL_PAGESCROLL then
  5.             ScrollAmount := Trunc(WheelFactor * ClientHeight)
  6.           else if ScrollLines = 0 then
  7.             ScrollAmount := round(WheelFactor * Mouse.WheelScrollLines * FDefaultNodeHeight)
  8.           else
  9.             ScrollAmount := Trunc(WheelFactor * ScrollLines * FDefaultNodeHeight);  
Title: Re: VirtualTreeView 4.8.7 released
Post by: Shebuka on November 22, 2011, 05:21:30 pm
Hi, i make new developments on Mac OS X (found some bug, see bugtracker) and would like to ask, why in DragType dtVCL there is not generated a DragImage? Is there a way to make it work? (have see is source that DoDragging (wich has calls to generate the drag image) is only called if there is a OLE drag)
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on November 22, 2011, 11:21:27 pm
In dtVcl its up to the widgetset draw the dragimage
Title: Re: VirtualTreeView 4.8.7 released
Post by: Shebuka on November 23, 2011, 09:26:41 am
In dtVcl its up to the widgetset draw the dragimage
Is this automatic or i must call some function or init something? Because with default options Carbon is not drawing anything...
Title: Re: VirtualTreeView 4.8.7 released
Post by: Gustavo 'Gus' Carreno on April 01, 2012, 07:05:20 pm
Quote
Are plans for 64 bit?

The trunk should work with 64bit (not tested by me)

I've just installed VTV from Trunk and it compiles. I've had to use lclextensions from trunk also.

Will report any issues under amd64.

Cheers,
Gus
Title: Re: VirtualTreeView 4.8.7 released
Post by: esvignolo on January 28, 2014, 03:11:24 pm
Hi, i make new developments on Mac OS X (found some bug, see bugtracker) and would like to ask, why in DragType dtVCL there is not generated a DragImage? Is there a way to make it work? (have see is source that DoDragging (wich has calls to generate the drag image) is only called if there is a OLE drag)

Hi Shebuka, i have some troubles using VTV in macos, have you a new source for mac?
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on July 17, 2015, 04:09:58 pm
There's still a scrolbar problem on Carbon where the treeview does not update (at least on horizontal scrolling)

I am looking into it right now, if anyone has some ideas they want me to test and report back, let me know!
Title: Re: VirtualTreeView 4.8.7 released
Post by: eny on July 17, 2015, 06:10:26 pm
There's still a scrolbar problem on Carbon where the treeview does not update (at least on horizontal scrolling)

I am looking into it right now, if anyone has some ideas they want me to test and report back, let me know!
Useful update on a 1.5y old thread
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on July 17, 2015, 09:35:23 pm
It is better than creating a new thread on the same topic. Infact this thread is linked in the Lazarus documentation for virtual treeview. Seeing as tthis is a major component and scrolling is rather important - I think it useful to use tthis thread as reference point.
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on July 20, 2015, 10:56:56 pm
If someone with a Mac could run the test app and put the output screenshot in the bug report it would help a lot:

http://bugs.freepascal.org/view.php?id=25564
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on August 25, 2015, 10:59:49 pm
Did not see this before now. I will first have my Mac back in a week, but I will do it then.

(I can confirm I am otherwise seeing the same as the youtube video, but I have not tested the test app yet)
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on September 16, 2015, 11:54:27 am
Here - uploaded to tracker as well

It would be great if this issue could be solved in virtual string tree - hopefully this helps, else let me know if you need me to test anything else!
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on September 16, 2015, 05:48:28 pm
Code: Pascal  [Select][+][-]
  1. procedure TBaseVirtualTree.CMMouseWheel(var Message: TLMMouseEvent);
  2. ...
  3.           SystemParametersInfo(SPI_GETWHEELSCROLLLINES, 0, @ScrollLines, 0);
  4.           if ScrollLines = WHEEL_PAGESCROLL then
  5.             ScrollAmount := Trunc(WheelFactor * ClientHeight)
  6.           else if ScrollLines = 0 then
  7.             ScrollAmount := round(WheelFactor * Mouse.WheelScrollLines * FDefaultNodeHeight)
  8.           else
  9.             ScrollAmount := Trunc(WheelFactor * ScrollLines * FDefaultNodeHeight);  
[/quote]

Checking the trunk your fix does not seem to be part of it
https://svn.code.sf.net/p/lazarus-ccr/svn/components/virtualtreeview-new/trunk/VirtualTrees.pas

Does anyone know what the state is? Are there fixes in this thread not implemented yet for virtual treeview? (It is a pretty major problem hat horizontal scrolling does not work in virtual treeview - interestingly there are under some conditions where it does work)
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on September 17, 2015, 03:44:02 pm
The bug is caused by http://bugs.freepascal.org/view.php?id=28689
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on September 18, 2015, 02:09:43 am
Let me know if you need me to test code on OSX - provide screenshots or similar.
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on September 19, 2015, 02:04:09 pm
Can anyone think of a possible workaround for virtual treeview until a fix is available?

I have tried to repond to onscroll by calling repaint and various similar things (invalidate, update etc.) but that does not work ... even if it redraws it does not redraw the content of the columns
Title: Re: VirtualTreeView 4.8.7 released
Post by: balazsszekely on September 19, 2015, 04:21:03 pm
Quote
@MISV
Can anyone think of a possible workaround for virtual treeview until a fix is available?
Try the following:
  1. Open VirtualTrees.pas
  2. Locate the following function: procedure SetCanvasOrigin(Canvas: TCanvas; X, Y: Integer);
  3. Just above SetCanvasOrigin paste this:
 
Code: [Select]
  {$IFDEF LCLCarbon}
  function SetWindowOrgEx(DC: HDC; NewX, NewY: Integer; OldPoint: PPoint): Boolean;
  begin
    Result := Boolean(SetViewPortOrgEx(DC, -NewX, -NewY, LPPoint(OldPoint)));
  end;
  {$ENDIF}

  //procedure SetCanvasOrigin(Canvas: TCanvas; X, Y: Integer);
  //...
 
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on September 21, 2015, 02:43:45 pm
"SetCanvasOrigin" is not available in:
https://svn.code.sf.net/p/lazarus-ccr/svn/components/virtualtreeview-new/branches/4.8/VirtualTrees.pas

However, I can see it in:
https://svn.code.sf.net/p/lazarus-ccr/svn/components/virtualtreeview-new/trunk/
?

From inspecting the source the latter contains the call you are taking about, but no usage of e.g. LCLCarbon meaning I suspect it is a copy of the Delphi compatible virtual trees?
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on September 22, 2015, 03:28:30 am
I don't have mac, but AFAIK, Window Origin is ignored at all in Carbon
Title: Re: VirtualTreeView 4.8.7 released
Post by: balazsszekely on September 22, 2015, 04:00:03 pm
@MISV, @LuizAmérico
Yes, instead of the branch I used the trunk, but it's irrelevant in this particular case.  According to the bug report(http://bugs.freepascal.org/view.php?id=28689)
 "SetWindowOrgEx" is not working  under OSX, so I was trying to replace with "SetViewPortOrgEx". Unfortunately both end up calling procedure "TCarbonDeviceContext.UpdateContextOfs" from carboncanvas.pp which fails. I need more time to find out the reason.
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on September 23, 2015, 03:30:57 am
Look at TGtk2WidgetSet.StretchCopyArea method specifically what is done at:

Code: [Select]
if SrcDevContext.HasTransf then
  begin
    // TK: later with shear and rotation error here?
    SrcDevContext.TransfPoint(XSrc, YSrc);
    SrcDevContext.TransfExtent(SrcWidth, SrcHeight);
  end;
  SrcDCOrigin := SrcDevContext.Offset;
  Inc(XSrc, SrcDCOrigin.X);
  Inc(YSrc, SrcDCOrigin.Y);

  if DstDevContext.HasTransf then
  begin
    // TK: later with shear and rotation error here?
    DstDevContext.TransfPoint(X, Y);
    DstDevContext.TransfExtent(Width, Height);
  end;
  DstDCOrigin := DstDevContext.Offset;
  Inc(X, DstDCOrigin.X);
  Inc(Y, DstDCOrigin.Y);

Try to replicate at

Code: [Select]
TCarbonDeviceContext.StretchDraw
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on September 25, 2015, 01:22:05 pm
Am I correct in that this bug/issue has to be fixed at deeper levels in carbon? (If so, should I crosss posrt this to Carbon group?) If there is anything I should try modifying in virtual treeview source and test it, let me know. I can make the changes and take a screenshot on OSX / Lazarus 1.4.2
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on September 25, 2015, 02:01:01 pm
Should be modified in carbon widgetset
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on September 26, 2015, 11:21:12 am
I have made a post in Carbon group then since this is really a discussion for Carbon:

http://forum.lazarus.freepascal.org/index.php/board,27.0.html (http://forum.lazarus.freepascal.org/index.php/board,27.0.html)
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on October 01, 2015, 04:10:58 pm
I will try see if I can investigate Carbon changes, but don't yet fully understand how Lazarus organizes its libraries. How would I easiest go around changing in a widget?

Should I simply make the code changes and then remove the relevant earlier compiled files in appropriate /lib directories and recompile an app? Would this be sufficient in testing a solution?
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on October 02, 2015, 02:06:14 am
Look at TGtk2WidgetSet.StretchCopyArea in gtk2widgetset.inc file for the manipulations (the changes that are done in XSrc and YSrc) that are done inside it through a call to SrcDevContext.TransfPoint

Try to replicate the behavior of TCarbonDeviceContext.StretchDraw in CarbonCanvas file.
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on October 03, 2015, 12:34:29 am
Quote
Look at TGtk2WidgetSet.StretchCopyArea method specifically what is done at:

Code: Pascal  [Select][+][-]
  1. if SrcDevContext.HasTransf then
  2.   begin
  3.     // TK: later with shear and rotation error here?
  4.     SrcDevContext.TransfPoint(XSrc, YSrc);
  5.     SrcDevContext.TransfExtent(SrcWidth, SrcHeight);
  6.   end;
  7.   SrcDCOrigin := SrcDevContext.Offset;
  8.   Inc(XSrc, SrcDCOrigin.X);
  9.   Inc(YSrc, SrcDCOrigin.Y);
  10.  
  11.   if DstDevContext.HasTransf then
  12.   begin
  13.     // TK: later with shear and rotation error here?
  14.     DstDevContext.TransfPoint(X, Y);
  15.     DstDevContext.TransfExtent(Width, Height);
  16.   end;
  17.   DstDCOrigin := DstDevContext.Offset;
  18.   Inc(X, DstDCOrigin.X);
  19.   Inc(Y, DstDCOrigin.Y);
  20.  


Quote
Look at TGtk2WidgetSet.StretchCopyArea in gtk2widgetset.inc file for the manipulations (the changes that are done in XSrc and YSrc) that are done inside it through a call to SrcDevContext.TransfPoint

Try to replicate the behavior of TCarbonDeviceContext.StretchDraw in CarbonCanvas file.



Thanks!

To solve this issue I will first try locate all the relevant code sections and include them here.

If anyone has specific code changes they want me to test - let me know.



/Developer/lazarus/lcl/intefaces/gtk2/gtk2widgetset.inc

Code: [Select]
{------------------------------------------------------------------------------
  Function: TGtk2WidgetSet.StretchCopyArea
  Params:  DestDC:                The destination devicecontext
           X, Y:                  The left/top corner of the destination rectangle
           Width, Height:         The size of the destination rectangle
           SrcDC:                 The source devicecontext
           XSrc, YSrc:            The left/top corner of the source rectangle
           SrcWidth, SrcHeight:   The size of the source rectangle
           Mask:                  An optional mask
           XMask, YMask:          Only used if Mask<>nil
           Rop:                   The raster operation to be performed
  Returns: True if succesful

  The StretchBlt function copies a bitmap from a source rectangle into a
  destination rectangle using the specified raster operation. If needed, it
  resizes the bitmap to fit the dimensions of the destination rectangle.
  Sizing is done according to the stretching mode currently set in the
  destination device context.
  If SrcDC contains a mask the pixmap will be copied with this transparency.

  ToDo:
    Mirroring
    Extended NonDrawable support (Image, Bitmap, etc)
    Scale mask
 ------------------------------------------------------------------------------}
function TGtk2WidgetSet.StretchCopyArea(DestDC: HDC; X, Y, Width, Height: Integer;
  SrcDC: HDC; XSrc, YSrc, SrcWidth, SrcHeight: Integer;
  Mask: HBITMAP; XMask, YMask: Integer;
  Rop: Cardinal): Boolean;
var
  SrcDevContext: TGtkDeviceContext absolute SrcDC;
  DstDevContext: TGtkDeviceContext absolute DestDC;
  TempPixmap: PGdkPixmap;
  TempMaskBitmap: PGdkBitmap;
  SizeChange, ROpIsSpecial: Boolean;
  FlipHorz, FlipVert: Boolean;

//--
// NOTE: lots of sub functions removed here
//--

var
  NewSrcWidth: Integer;
  NewSrcHeight: Integer;
  NewWidth: Integer;
  NewHeight: Integer;
  SrcDCOrigin: TPoint;
  DstDCOrigin: TPoint;
  SrcWholeWidth, SrcWholeHeight: integer;
  DstWholeWidth, DstWholeHeight: integer;
begin
  Result := IsValidDC(DestDC) and IsValidDC(SrcDC);
  {$IFDEF VerboseStretchCopyArea}
  DebugLn('StretchCopyArea Start '+dbgs(Result));
  {$ENDIF}
  if not Result then Exit;

  if SrcDevContext.HasTransf then
  begin
    // TK: later with shear and rotation error here?
    SrcDevContext.TransfPoint(XSrc, YSrc);
    SrcDevContext.TransfExtent(SrcWidth, SrcHeight);
  end;
  SrcDCOrigin := SrcDevContext.Offset;
  Inc(XSrc, SrcDCOrigin.X);
  Inc(YSrc, SrcDCOrigin.Y);

  if DstDevContext.HasTransf then
  begin
    // TK: later with shear and rotation error here?
    DstDevContext.TransfPoint(X, Y);
    DstDevContext.TransfExtent(Width, Height);
  end;
  DstDCOrigin := DstDevContext.Offset;
  Inc(X, DstDCOrigin.X);
  Inc(Y, DstDCOrigin.Y);

  FlipHorz := Width < 0;
  if FlipHorz then
  begin
    Width := -Width;
    X := X - Width;
  end;

  FlipVert := Height < 0;
  if FlipVert then
  begin
    Height := -Height;
    Y := Y - Height;
  end;

  if (Width = 0) or (Height = 0) then exit;
  if (SrcWidth = 0) or (SrcHeight = 0) then exit;

  SizeChange := (Width <> SrcWidth) or (Height <> SrcHeight) or FlipVert or FlipHorz;
  ROpIsSpecial := (Rop <> SRCCOPY);

  if SrcDevContext.Drawable = nil then RaiseSrcDrawableNil;
  gdk_window_get_size(PGdkWindow(SrcDevContext.Drawable), @SrcWholeWidth, @SrcWholeHeight);


  if DstDevContext.Drawable = nil then RaiseDestDrawableNil;
  gdk_window_get_size(PGdkWindow(DstDevContext.Drawable), @DstWholeWidth, @DstWholeHeight);

  {$IFDEF VerboseStretchCopyArea}
  DebugLn('TGtk2WidgetSet.StretchCopyArea BEFORE CLIPPING X='+dbgs(X),' Y='+dbgs(Y),' Width='+dbgs(Width),' Height='+dbgs(Height),
    ' XSrc='+dbgs(XSrc)+' YSrc='+dbgs(YSrc)+' SrcWidth='+dbgs(SrcWidth)+' SrcHeight='+dbgs(SrcHeight),
    ' SrcDrawable=',DbgS(TGtkDeviceContext(SrcDC).Drawable),
    ' SrcOrigin='+dbgs(SrcDCOrigin),
    ' DestDrawable='+DbgS(TGtkDeviceContext(DestDC).Drawable),
    ' DestOrigin='+dbgs(DstDCOrigin),
    ' Mask='+DbgS(Mask)+' XMask='+dbgs(XMask)+' YMask='+dbgs(YMask),
    ' SizeChange='+dbgs(SizeChange)+' ROpIsSpecial='+dbgs(ROpIsSpecial),
    ' DestWhole='+dbgs(DstWholeWidth)+','+dbgs(DstWholeHeight),
    ' SrcWhole='+dbgs(SrcWholeWidth)+','+dbgs(SrcWholeHeight),
    '');
  {$ENDIF}
  {$IFDEF VerboseGtkToDos}{$note use intersectrect here}{$ENDIF}
  if X >= DstWholeWidth then Exit;
  if Y >= DstWholeHeight then exit;
  if X + Width <= 0 then exit;
  if Y + Height <=0 then exit;
  if XSrc >= SrcWholeWidth then Exit;
  if YSrc >= SrcWholeHeight then exit;
  if XSrc + SrcWidth <= 0 then exit;
  if YSrc + SrcHeight <=0 then exit;

  // gdk does not allow copying areas, party laying out of bounds
  // -> clip

  // clip src to the left
  if (XSrc<0) then begin
    NewSrcWidth:=SrcWidth+XSrc;
    NewWidth:=((Width*NewSrcWidth) div SrcWidth);
    {$IFDEF VerboseStretchCopyArea}
    DebugLn('StretchCopyArea Cliping Src to left NewSrcWidth='+dbgs(NewSrcWidth),' NewWidth='+dbgs(NewWidth));
    {$ENDIF}
    if NewWidth = 0 then exit;
    inc(X, Width-NewWidth);
    if X >= DstWholeWidth then exit;
    XSrc:=0;
    SrcWidth := NewSrcWidth;
  end;

  // clip src to the top
  if (YSrc<0) then begin
    NewSrcHeight:=SrcHeight+YSrc;
    NewHeight:=((Height*NewSrcHeight) div SrcHeight);
    {$IFDEF VerboseStretchCopyArea}
    DebugLn('StretchCopyArea Cliping Src to top NewSrcHeight='+dbgs(NewSrcHeight),' NewHeight='+dbgs(NewHeight));
    {$ENDIF}
    if NewHeight = 0 then exit;
    inc(Y, Height - NewHeight);
    if Y >= DstWholeHeight then exit;
    YSrc:=0;
    SrcHeight := NewSrcHeight;
  end;

  // clip src to the right
  if (XSrc+SrcWidth>SrcWholeWidth) then begin
    NewSrcWidth:=SrcWholeWidth-XSrc;
    Width:=((Width*NewSrcWidth) div SrcWidth);
    {$IFDEF VerboseStretchCopyArea}
    DebugLn('StretchCopyArea Cliping Src to right NewSrcWidth='+dbgs(NewSrcWidth),' NewWidth='+dbgs(Width));
    {$ENDIF}
    if (Width=0) then exit;
    if (X+Width<=0) then exit;
    SrcWidth:=NewSrcWidth;
  end;

  // clip src to the bottom
  if (YSrc+SrcHeight>SrcWholeHeight) then begin
    NewSrcHeight:=SrcWholeHeight-YSrc;
    Height:=((Height*NewSrcHeight) div SrcHeight);
    {$IFDEF VerboseStretchCopyArea}
    DebugLn('StretchCopyArea Cliping Src to bottom NewSrcHeight='+dbgs(NewSrcHeight),' NewHeight='+dbgs(Height));
    {$ENDIF}
    if (Height=0) then exit;
    if (Y+Height<=0) then exit;
    SrcHeight:=NewSrcHeight;
  end;

  if Mask = 0
  then begin
    XMask := XSrc;
    YMask := YSrc;
  end;

  // mark temporary scaling/rop buffers as uninitialized
  TempPixmap := nil;
  TempMaskBitmap := nil;

  {$IFDEF VerboseStretchCopyArea}
  write('TGtk2WidgetSet.StretchCopyArea AFTER CLIPPING X='+dbgs(X)+' Y='+dbgs(Y)+' Width='+dbgs(Width)+' Height='+dbgs(Height),
    ' XSrc='+dbgs(XSrc),' YSrc='+dbgs(YSrc)+' SrcWidth='+dbgs(SrcWidth)+' SrcHeight='+dbgs(SrcHeight),
    ' SrcDrawable='+DbgS(SrcDevContext.Drawable),
    ' DestDrawable='+DbgS(DstDevContext.Drawable),
    ' Mask='+DbgS(Mask)+' XMask='+dbgs(XMask)+' YMask='+dbgs(YMask),
    ' SizeChange='+dbgs(SizeChange)+' ROpIsSpecial='+dbgs(ROpIsSpecial));
  write(' ROp=');
  case ROp of
    SRCCOPY     : DebugLn('SRCCOPY');
    SRCPAINT    : DebugLn('SRCPAINT');
    SRCAND      : DebugLn('SRCAND');
    SRCINVERT   : DebugLn('SRCINVERT');
    SRCERASE    : DebugLn('SRCERASE');
    NOTSRCCOPY  : DebugLn('NOTSRCCOPY');
    NOTSRCERASE : DebugLn('NOTSRCERASE');
    MERGECOPY   : DebugLn('MERGECOPY');
    MERGEPAINT  : DebugLn('MERGEPAINT');
    PATCOPY     : DebugLn('PATCOPY');
    PATPAINT    : DebugLn('PATPAINT');
    PATINVERT   : DebugLn('PATINVERT');
    DSTINVERT   : DebugLn('DSTINVERT');
    BLACKNESS   : DebugLn('BLACKNESS');
    WHITENESS   : DebugLn('WHITENESS');
  else
    DebugLn('???');
  end;
  {$ENDIF}

  {$IFDEF VerboseGtkToDos}{$note tode remove, earlier checks require drawable <> nil}{$ENDIF}
  if SrcDevContext.Drawable = nil
  then begin
    if DstDevContext.Drawable = nil
    then
      Result := NoDrawableToNoDrawable
    else
      Result := NoDrawableToDrawable;
  end
  else begin
    if DstDevContext.Drawable = nil
    then
      Result := DrawableToNoDrawable
    else
      Result := DrawableToDrawable;
  end;

  if TempPixmap <> nil
  then gdk_pixmap_unref(TempPixmap);
  if TempMaskBitmap <> nil
  then gdk_pixmap_unref(TempMaskBitmap);
end;



/Developer/lazarus/lcl/intefaces/gtk2/gtk2devicecontext.inc

Code: [Select]
procedure TGtkDeviceContext.TransfPoint(var X1, Y1: Integer);
begin
  // to do: put affine transformation here (for all Transf.. methods)
  X1 := MulDiv(X1, FViewPortExt.x, FWindowExt.x) + FViewPortOrg.x - FWindowOrg.x;
  Y1 := MulDiv(Y1, FViewPortExt.y, FWindowExt.y) + FViewPortOrg.y - FWindowOrg.y;
end;



/Developer/lazarus/lcl/intefaces/carbon/CarbonCanvas.pp

Code: [Select]
{------------------------------------------------------------------------------
  Method:  StretchMaskBlt
  Params:  X, Y                  - Left/top corner of the destination rectangle
           Width, Height         - Size of the destination rectangle
           SrcDC                 - Carbon device context
           XSrc, YSrc            - Left/top corner of the source rectangle
           SrcWidth, SrcHeight   - Size of the source rectangle
           Mask                  - mask bitmap
           XMask, YMask          - Left/top corner of the mask rectangle
           Rop                   - Raster operation to be performed (TODO)
  Returns: If the function succeeds

  Copies a bitmap from a source rectangle into a destination rectangle using
  the specified raster operations. If needed it resizes the bitmap to
  fit the dimensions of the destination rectangle. Sizing is done according to
  the stretching mode currently set in the destination device context.
  TODO: copy from any canvas
        ROP
        stretch mode (should be set by winapi call in DC (MWE))
 ------------------------------------------------------------------------------}
function TCarbonDeviceContext.StretchDraw(X, Y, Width, Height: Integer;
  SrcDC: TCarbonBitmapContext; XSrc, YSrc, SrcWidth, SrcHeight: Integer;
  Msk: TCarbonBitmap; XMsk, YMsk: Integer; Rop: DWORD): Boolean;
var
  Image, MskImage: CGImageRef;
  SubImage, SubMask: Boolean;
  Bitmap: TCarbonBitmap;
  LayRect, DstRect: CGRect;
  ImgRect: CGRect;
  LayerContext: CGContextRef;
  Layer: CGLayerRef;
  UseLayer: Boolean;
begin
  Result := False;
 
  Image := nil;
  Bitmap := SrcDC.GetBitmap;
  if Bitmap <> nil then Image := Bitmap.CGImage;

  if Image = nil then Exit;

  DstRect := CGRectMake(X, Y, Abs(Width), Abs(Height));

  SubMask := (Msk <> nil)
         and (Msk.CGImage <> nil)
         and (  (XMsk <> 0)
             or (YMsk <> 0)
             or (Msk.Width <> SrcWidth)
             or (Msk.Height <> SrcHeight));

  SubImage := ((Msk <> nil) and (Msk.CGImage <> nil))
           or (XSrc <> 0)
           or (YSrc <> 0)
           or (SrcWidth <> Bitmap.Width)
           or (SrcHeight <> Bitmap.Height);


  if SubMask then
    MskImage := Msk.CreateSubImage(Bounds(XMsk, YMsk, SrcWidth, SrcHeight))
  else
    if Msk <> nil then MskImage := Msk.CGImage
    else MskImage := nil;

  if SubImage then
    Image := Bitmap.CreateSubImage(Bounds(XSrc, YSrc, SrcWidth, SrcHeight));


  UseLayer:=Assigned(MskImage)
            or (CGImageGetWidth(Image){%H-}<>SrcWidth)
            or (CGImageGetHeight(Image){%H-}<>SrcHeight);

  try
    if not UseLayer then
    begin
      // Normal drawing
      Result := DrawCGImage(X, Y, Width, Height, Image);
    end
    else
    begin
      // use temp layer to mask source image
      // todo find a way to mask "hard" when stretching, now some soft remains are visible
      LayRect := CGRectMake(0, 0, SrcWidth, SrcHeight);
      Layer := CGLayerCreateWithContext(SrcDC.CGContext, LayRect.size, nil);

      // the sub-image is out of edges
      if (CGImageGetWidth(Image){%H-}<>SrcWidth) or (CGImageGetHeight(Image){%H-}<>SrcHeight) then
      begin
        with ImgRect do
          if XSrc<0 then origin.x:=SrcWidth-CGImageGetWidth(Image) else origin.x:=0;
        with ImgRect do
          if YSrc<0 then origin.y:=0 else origin.y:=SrcHeight-CGImageGetHeight(Image);

        ImgRect.size.width:=CGImageGetWidth(Image);
        ImgRect.size.height:=CGImageGetHeight(Image);
      end
      else
        ImgRect:=LayRect;

      try
        LayerContext := CGLayerGetContext(Layer);
        CGContextScaleCTM(LayerContext, 1, -1);
        CGContextTranslateCTM(LayerContext, 0, -SrcHeight);

        SetCGFillping(LayerContext, Width, Height);
        if Assigned(MskImage) then CGContextClipToMask(LayerContext, ImgRect, MskImage);
        CGContextDrawImage(LayerContext, ImgRect, Image);

        CGContextDrawLayerInRect(CGContext, DstRect, Layer);
       
        Result := True;
      finally
        CGLayerRelease(Layer);
      end;
    end;

  finally
    if SubImage then CGImageRelease(Image);
    if SubMask then CGImageRelease(MskImage);
  end;
 
  //DebugLn('StretchMaskBlt succeeds: ', Format('Dest %d Src %d X %d Y %d',
  //  [Integer(CGContext),
  //  Integer(Image),
  //  X, Y]));
end;



/Developer/lazarus/lcl/intefaces/carbon/CarbonCanvas.pp

Code: [Select]
procedure TCarbonDeviceContext.SetWindowOfs(const AWindowOfs: TPoint);
begin
  UpdateContextOfs(AWindowOfs, ViewPortOfs);
end;



/Developer/lazarus/lcl/intefaces/carbon/CarbonCanvas.pp

Code: [Select]
procedure TCarbonDeviceContext.UpdateContextOfs(const AWindowOfs, AViewOfs: TPoint);
var
  dx, dy: Integer;
begin
  if isSamePoint(AWindowOfs, fWindowOfs) and isSamePoint(AViewOfs, fViewPortOfs) then Exit;
  GetWindowViewTranslate(FWindowOfs, FViewPortOfs, dx{%H-}, dy{%H-});
  CGContextTranslateCTM(CGContext, -dx, -dy);

  FWindowOfs := AWindowOfs;
  FViewPortOfs := AViewOfs;
  GetWindowViewTranslate(FWindowOfs, FViewPortOfs, dx, dy);
  CGContextTranslateCTM(CGContext, dx, dy);
end;



For reference, here is the bug report by Luiz:
http://bugs.freepascal.org/view.php?id=28689 (http://bugs.freepascal.org/view.php?id=28689)
Title: Re: VirtualTreeView 4.8.7 released
Post by: freeman35 on October 12, 2015, 12:20:04 pm
JAM software share Virtual-TreeView in github
https://github.com/Virtual-TreeView/Virtual-TreeView

I copied from there:

Feature Requests
We currently focus on reducing the number of reported bugs and getting Virtual Treeview stable. Feature Requests will most likely not processed at the moment. We are only going to process enhancement requests if the new feature is of general interest and a source code patch based on the latest SVN revision is attached to the report. Please mark feature requests with the flag "Enhancement".

Is that mean(underlined) can we use this codes under lazarus ?
Title: Re: VirtualTreeView 4.8.7 released
Post by: JuhaManninen on October 12, 2015, 02:22:08 pm
Is that mean(underlined) can we use this codes under lazarus ?

No, there is no mention about Lazarus.

I did not know about Virtual Treeview moving to JAM Software maintenance. LuizAmérico, how realistic would it be to maintain a Lazarus fork as a branch of this GitHub repo? Finally JAM Software could be persuaded to merge the codebases.
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on October 12, 2015, 04:57:59 pm
I already have done the preparation to fork from the official GitHub repository (in fact i was already merging code from Google Code but manually).

Don't hold your breath for the newest features. After version 6, VTV removed old delphi compatible adding code that does not compile with fpc.
Title: Re: VirtualTreeView 4.8.7 released
Post by: freeman35 on October 13, 2015, 10:51:28 am
@LuizAmérico
I'm using "/lazarus-ccr/svn/components/virtualtreeview-new/trunk" I think this is last version, isn't it? I need master-detail grid view, will VTV for lazarus support it?
I'm using VTV in my project and very pleased it, thank you very much
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on October 13, 2015, 01:23:27 pm
Personally I find lazarus VT 4.8.7 fully compatible with the version I used in Delphi, so I would rather have bugs fixed in Lazarus/VT4.8.7/Carbon (it is my understanding the Carbon issue also causes problems in other controls in Carbon and since Cocoa is not ready then...)

Anyhow, maintaining compatiblity with properties (even if not fully implemented) should probably also have some priority, so it is as easy as possible moving a project from Delphi to Lazarus. (Since I have ported this part is no longer relevant for me, but I mention this to increase Delphi to Lazarus adaption / cross-compiler userbase)

Best would of course be if JAM would maintain Lazarus compatiblity, but if they have removed code then...
Title: Re: VirtualTreeView 4.8.7 released
Post by: freeman35 on October 18, 2015, 12:27:59 pm
in my opinion, JAM not think support lazarus or old version delphi. Theme product use VTV, and been owner VTV. Why support all delphi version and lazarus or others? This mean huge source code, big application size, and increase problem count. etc. ( I hope I'm wrong )
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on October 21, 2015, 03:39:37 am
Would there be any interest in a small bounty for solving this Carbon issue affecting virtual treeview? (feel free to PM me as well) 

I think this Carbon issue affects more controls than just VTV (e.g. stringgrid?) and it is the only big issue I have found sofar in Carbon support (I will probably encounter more, but my impression is that everything otherwise very well supported)

Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on October 21, 2015, 04:28:43 am
No need to bounty by my side.
The only problem for me is the lack of a mac to test.
Thursday i will try to translate the Gtk2 behavior to Carbon blindly. Let's see what we'll get.
Title: Re: VirtualTreeView 4.8.7 released
Post by: manhu on October 21, 2015, 09:33:51 am
Did just read your post:
Quote
The only problem for me is the lack of a mac to test.
Found this solution:
http://kecodoc.com/install-mac-os-x-yosemite-in-vmware-inside-window-pc/ (http://kecodoc.com/install-mac-os-x-yosemite-in-vmware-inside-window-pc/)
Hope it is ok to post this link.. :-[

Shalom
Manfred
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on October 22, 2015, 06:24:35 pm
Try to add the following code in TCarbonDeviceContext.StretchDraw carboncanvas.pp:1475

  if Image = nil then Exit;

  //add this two lines
  XSrc := XSrc - SrcDC.WindowOfs.X;
  YSrc := YSrc - SrcDC.WindowOfs.Y;

  DstRect := CGRectMake(X, Y, Abs(Width), Abs(Height));

See what happens. Post a screen shot of the test app
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on October 23, 2015, 12:17:55 pm
Will report back later today today :)
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on October 26, 2015, 07:22:34 pm
The fix works for me! (sorry for the delay)
Title: Re: VirtualTreeView 4.8.7 released
Post by: LuizAmérico on October 27, 2015, 04:34:57 am
Can you post a screenshot of the test app in http://bugs.freepascal.org/view.php?id=28689 together with a comment that works?
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on October 28, 2015, 03:19:18 am
Hereby done :)
Title: Re: VirtualTreeView 4.8.7 released
Post by: MISV on March 30, 2016, 07:42:23 pm
This fix was not included in 1.4.4 and still listed as open (child issues) in bugtracker - do you know if that means it has not yet been included in new Lazarus versions?
TinyPortal © 2005-2018