2.0.12, trouble with CustomTreeView (OnExpand?)

[d7_2_laz]

After doing a fresh install (preceeded by a system disc restore) i installed  Lazarus 2.0.12 (Windows 10 x64) and noticed that i got a problem with the customtreeview -> exception.
Exception on TreeNode.GetCount. After research i saw that that node was nil at a place where i did not expect that.
After further research i saw that a code had not been executed that populated a node with child nodes at the OnExpand event.

After research i saw that a directive Node.Expand(false) did not trigger the OnExpand event so that the node had no childs.
Tried to test the Node.Expand with a normal treeview -> no problem, OnExpand was called.
Tried to reactivate the 2.0.10  treeview.inc instead of the 2.0.12 version for test -> no different result.
So i'm somehow stuck to find out what's going wrong here.  Before i do a rollback to the 2.0.10 i'd like to ask whether there had been changes in the 2.0.12 that could influence that effect.

[trev]

You can see the changes in Lazarus 2.0.12 in the Wiki Fixes List for 2.0.12.

[wp]

In the attached demo, the OnExpanding/OnExpanded and OnCollapsing/OnCollapsed events are logged in a memo. I see the same (correct) behaviour in Laz-trunk, Laz 2.0.12 and Laz2.0.10 - in all these cases the events are fired no matter if the expand/collapse action has been triggered by user interaction or by code.

There is one difference between 2.0.10 and 2.0.12: The OnCollaps* events are triggered also when the application is closing which can cause crashes when other controls are accessed by the event handlers, like here the memo. This issue is handled in my demo by checking the csDestroying ComponentState. In trunk this has probably been fixed in r64142 of Nov 15, 2020 ("LCL: Do not call TTreeView.OnCollapsing and OnCollapsed during clearing the items. Issue #38084."); it has been merged to v2.0.12.

[d7_2_laz]

Yes, no issue with the regular treeview as mendioned, only within my customtreeview. And here when explicitely coding a node.Expand. Get no Node.Expanding (or node.Expanded) event then.
"CurNode.Expand(False);"  ---> No OnExpainding is fired.

About the "don't fire  onCollapsing .. when clearing items" ... just saw that.
For to exclude that it is related somehow: the change is done within which pas file?

Hm, would be helpful, how can i do an OutPutDebugString within treeview.inc ?

[d7_2_laz]

Attached a simple test case.

You will see a  "Base node".

If the OnExpanding event is called, you will see a "Child node" too created herein.
If you don't sse the "Child node", then the OnExpanding event had not been fired resp. the event callback had not been triggered.

For to be complete, i'll deinstall 2.0.12 / reinstall 2.0.10 later for to see if the child node does really appear here again.

[wp]

About the "don't fire  onCollapsing .. when clearing items" ... just saw that.
For to exclude that it is related somehow: the change is done within which pas file?

lcl/include/treeview.inc

Hm, would be helpful, how can i do an OutPutDebugString within treeview.inc ?

I don't know if the Delphi-style "OutputDebugString" is supported (probably with unit Windows). Similar functionality is provided by LazLoggerBase/LazLogger (https://wiki.freepascal.org/LazLogger).

In most cases it is easier to use the standard debugger for debugging the LCL and other non-project units.  I normally go to "Project" > "Additions and overrides" > Click "Stored in session" > "Add" > "Custom option" and type in the appearing line "-gw2". This activates Dwarf2 debug information for all sources reachable. When you now recompile your project all dependent units are recompiled with debug info (except for fcl/rtl), and you can easily use "F7" to step into the lcl code.

[wp]

Attached a simple test case.

You will see a  "Base node".

If the OnExpanding event is called, you will see a "Child node" too created herein.
If you don't sse the "Child node", then the OnExpanding event had not been fired resp. the event callback had not been triggered.

Is it intentional that you do not assign the OnExpanding event handler (ctvExpanding) to the tree's OnExpanding event? Or do you mean to work with the corresponding method which fires the event? In this case you'd have to override "function CanExpand(ANode: TTreeNode): Boolean"

Code: Pascal  [Select][+][-]

1. function TMyTreeView.CanExpand(Node: TTreeNode): Boolean;
2. begin
3.    ShowMessage('expanding');
4.    Node := Items.GetFirstNode;
5.    Items.AddChild(Node, 'Child node');
6.    Result := inherited;
7. end;  

[d7_2_laz]

No wp (thanks!), it was (differently to the original component) missed by mistake when preparing the little test case. So, that works in fact, and i need to dig further.
Probably some other layer is preventing the Expanding event callback to be triggered in my 2.0.12 env. differently to the 2.0.10 environment.

Thank you too for the valuable informations about the debug steps!

[d7_2_laz]

I think i found the reason why resp. am near by.
As already slightly suspected, the 2.0.12 didn't only prevent "onCollapsing .. when clearing items" , but did something similar for the Expand code too (treeviw.inc):

Code: Pascal  [Select][+][-]

1. //2.0.10
2. function TCustomTreeView.CanExpand(Node: TTreeNode): Boolean;
3. begin
4.   Result := True;
5.   if Assigned(FOnExpanding) then FOnExpanding(Self, Node, Result);
6. end;
7. //2.0.12:
8. function TCustomTreeView.CanExpand(Node: TTreeNode): Boolean;
9. begin
10.   Result := True;
11.   if Assigned(FOnExpanding) and not (tvsUpdating in FStates) then
12.     FOnExpanding(Self, Node, Result);
13. end;

If i reactivate back (just for testing) the 2.0.10 function, then my prog is back again.
Obviously it is assumed (in the context of my app, but not in the simplified test case) that the node is in an Updating state (shy? Due to BeginUpdate?) and prohibits the Expand.
So it's simply the question how to reactiave the old behaviou back, if wanted. What might be the best way recommended?

[wp]

CanExpand is virtual. It is a short method: simply override it and use the old code withoug calling "inherited". But be prepared for issues later: the modification was made for some reason...

[JuhaManninen]

I made the commit r64142. See :
 https://bugs.freepascal.org/view.php?id=38084
Apparently it is not perfect. I remember thinking if I should create a new flag or something.
wp, how would you fix it properly?

[d7_2_laz]

At that place a personal feedback from me: this forum as well as your engaged answers from you are a incredible good help for one (like me) who tries to get familiar with the specifcs of Lazarus.

Whatever you might decide (although the idea behind the CanExpand change is not quite clear to me) would be fine; you might want to flag it as solved afterwards.

Only one wish: the Release Notes should give a chance to get an early awareness/attention in the case one is struggling with an exception (in this case: OnCallapse and CanExpand changed ....).
 

[wp]

No wp (thanks!), it was (differently to the original component) missed by mistake when preparing the little test case. So, that works in fact, and i need to dig further.
Probably some other layer is preventing the Expanding event callback to be triggered in my 2.0.12 env. differently to the 2.0.10 environment.

OK then please prepare an example which really shows the issue. I am very sure that the change in r64142 is causing the different behaviour, but except for your issue expanding/collapsing is working fine. So, before changing anything, you must convince me that this is not an issue in your code.

[JuhaManninen]

Only one wish: the Release Notes should give a chance to get an early awareness/attention in the case one is struggling with an exception (in this case: OnCallapse and CanExpand changed ....).

Release Notes list new features and changed behavior in existing features. A new release also includes tons of bug fixes which are not listed.
If this one broke valid code then it is a regression. The report can be reopened and preferably assigned to wp. I have other duties coming.

[wp]

Here is another, more realistic demo. It reads files and directories in the root folder of the disk. When a directory is expanded the child level of files and folders is read in the OnExpanding event. And when a folder is collapsed the child nodes are destroyed in the OnCollapse event. The program works correctly, and the log in the memo displays that all events occur as expected. The program was tested with Laz trunk, Laz 2.0.12 and 2.0.10 - the latter one has the issue that the OnCollapse* events are fired when the tree is cleared, but this was the issue of report https://bugs.freepascal.org/view.php?id=38084.

Since the flag tvsUpdating which could prevent the OnExpand*/OnCollapse* events to fire is set/reset by the BeginUpdate/EndUpdate methods, I added a checkbox the use the BeginUpdate/EndUpdate pair for the expansion/collapse process or not. It does not make any difference.