View Issue Details

IDProjectCategoryView StatusLast Update
0004815JEDI VCL00 JVCL Componentspublic2009-10-25 18:17
ReporterptavasciAssigned ToAHUser 
Status resolvedResolutionfixed 
Product Version3.00 
Target VersionFixed in Version3.39 
Summary0004815: Bug in JvDBTreeView.pas
DescriptionIn procedure DragOver, this line

    Accept := (Source = Self) and Assigned(Selected) and

should look like this

    Accept := Accept and (Source = Self) and Assigned(Selected) and

ir order to be fully funcional when drag and dropping.
TagsNo tags attached.



2009-06-08 18:28

developer   ~0015630

I don't think so.
If you look at the if-statement above this line then you see that "Accept" would be always False ("if ... and not Accept then").


2009-06-08 20:18

reporter   ~0015631

You are absolutely right, but... then I think that it should be false, because if I hadn't added that piece of code, then the DragOver would let drop anywhere on the treeview, no matter what value the "Accept" parameter had.

Base class establishes that if there is no DragOver code implemented then "Accept" equals FALSE, otherwise it's TRUE.

Take a look at me code:

procedure TfrmArbolSectores.tvSectoresDragOver(Sender, Source: TObject; X, Y: Integer; State: TDragState; var Accept: Boolean);
  tnItemDestino: TTreeNode;
  tnItemDestino := (Source as TJvDBTreeView).GetNodeAt(X, Y);
  if Assigned(tnItemDestino) and (tnItemDestino.ImageIndex < 4) and (FNivel > 3) then
    Accept := ModoAgenda and (Source is TJvDBTreeView) and (Sender is TJvDBTreeView) and (tnItemDestino.ImageIndex < 4)
    Accept := False;

Thanks for your support.


2009-06-08 20:23

reporter   ~0015632

What I mean is that if I intentionally set "Accept" parameter to False for some of the treenodes, then the TJvCustomDBTreeView custom implementation could possibly turn that value into TRUE! And that would not be right.

I hope I can make myself understood, it's been a while since I wrote or spoke in English.

Thanks in advance.



2009-06-29 22:34

reporter   ~0015733

I feel lonely and cold without an answer... :(


2009-09-23 17:15

administrator   ~0016171

Well, unless Andreas feels otherwise, this will stay as is for the time being


2009-10-25 18:17

developer   ~0016820

Fixed in SVN.

Issue History

Date Modified Username Field Change
2009-06-08 17:15 ptavasci New Issue
2009-06-08 18:28 AHUser Note Added: 0015630
2009-06-08 18:28 AHUser Status new => feedback
2009-06-08 20:18 ptavasci Note Added: 0015631
2009-06-08 20:23 ptavasci Note Added: 0015632
2009-06-29 22:34 ptavasci Note Added: 0015733
2009-09-23 17:15 obones Note Added: 0016171
2009-10-25 18:17 AHUser Note Added: 0016820
2009-10-25 18:17 AHUser Status feedback => resolved
2009-10-25 18:17 AHUser Fixed in Version => Daily / SVN
2009-10-25 18:17 AHUser Resolution open => fixed
2009-10-25 18:17 AHUser Assigned To => AHUser