[SOLVED] Yet another TShellTreeView question

[petevick]

 In previous versions of my project that uses a TShellTreeView, when I've clicked on a selected node, the node text becomes highlighted for editing, just like in Nemo for example. Now, for whatever reason, it's not doing that.
I've tried copying the browser lfm and pas files from a known working version into the current version, but still no joy. So what could possibly be causing this behaviour ??

[Bart]

For me this still works out of the box (Lazarus main).
Maybe you have tvoReadOnly set in Options?

Bart

[petevick]

No Bart, I've looked at all options and tvoReadOnly is False.

I can simulate it by making True the tvoNoDoubleClickExpand option and assigning ShellTreeView1.Selected.EditText to the double click event, but I'd rather not.

[wp]

The same as reported by Bart: A second click on the selected node DOES show the editor. Tested on Windows 11 and Mint 21.2 Cinnamon (Laz/main and Laz/3.0)

BUT: I think this behaviour is not correct. The Lazarus ShellCtrls have no connection to the file system other than getting the file names and the directory structure. But when I rename a shelltreenode the new name does not propagate into the file system, no, I must call RenameFile myself to do this. Or when I delete a node, I must call DeleteFile to really delete the file. I understand the default concept of the ShellCtrls to provide components for selecting files. Therefore, ReadOnly should be ON by default, too. When the user wants to use the ShellCtrls in an explorer-like application, this would not be the default use case; he must write additional code anyway, and unchecking the ReadOnly property would be the smallest exercise then.

Like we did in the other thread: Pete try to extract the shelltreeview into a small test project and demonstrate the issue. Maybe you find the culprit along the way doing so, or you upload the project here so that we can have a look.

[petevick]

The same as reported by Bart: A second click on the selected node DOES show the editor. Tested on Windows 11 and Mint 21.2 Cinnamon (Laz/main and Laz/3.0)

BUT: I think this behaviour is not correct. The Lazarus ShellCtrls have no connection to the file system other than getting the file names and the directory structure. But when I rename a shelltreenode the new name does not propagate into the file system, no, I must call RenameFile myself to do this. Or when I delete a node, I must call DeleteFile to really delete the file. I understand the default concept of the ShellCtrls to provide components for selecting files. Therefore, ReadOnly should be ON by default, too. When the user wants to use the ShellCtrls in an explorer-like application, this would not be the default use case; he must write additional code anyway, and unchecking the ReadOnly property would be the smallest exercise then.

Like we did in the other thread: Pete try to extract the shelltreeview into a small test project and demonstrate the issue. Maybe you find the culprit along the way doing so, or you upload the project here so that we can have a look.

Until this morning the second click was showing the editor. The small project I created also shows the editor after a second click. But from what you've said above, maybe editing a node name is better done by code, like using the double click event.

[Bart]

BUT: I think this behaviour is not correct. The Lazarus ShellCtrls have no connection to the file system other than getting the file names and the directory structure.

Maybe Options by default should include tvoReadOnly?

Bart

[wp]

Yes, that's what I wanted to say.

[Bart]

Is gonna be backwards incompatible of course, so if done, should be documented.
I'm in favour, but (many) others might object.

Bart

[petevick]

I'm an absolute idiot. I'd removed a iine in the code which made the ShellTreeView read only when it should be writable...

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

1. function WhenReadOnly(bol: Boolean): Boolean;
2. begin
3.   Result:= True;
4.   with Browser do begin
5.     DelFolder.Enabled:= bol;
6.     NewFolder.Enabled:= bol;
7.     RenFolder.Enabled:= bol;
8.     MenuDelete.Enabled:=bol;
9.     MenuNewFolder.Enabled:=bol;
10.     MenuRename.Enabled:=bol;
11.     bol:= not bol;
12.     myTreeView.ReadOnly:= bol;
13.   end;
14.  

...the function gets passed the writable state of a folder, when a folder is writable bol = True, so lines 5 to 10 are enabled, but myTreeView.ReadOnly needs the opposite state, hence line 11, but for some reason in my (not) wisdom I'd deleted line 11 

And actually I can delete line 11 and change line 12 to.....

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

1. myTreeView.ReadOnly:= not bol;

All bloody day to find that    I'm also totally embarrassed, I knew it'd be something I'd done, why is it only obvious after you find it 

[wp]

I'm in favour, but (many) others might object.

I doubt that there will be "many". A change in the default setting of ReadOnly to true will only be noticed if an application explicitely needs to edit the treeview/listview. But I am convinced that this is not the main use-case of these controls.

[Bart]

Feel free to implement it then 

Bart

[wp]

Done. See also https://wiki.freepascal.org/Lazarus_4.0_release_notes#TShellTreeView.2C_TShellListView

[Bart]

OK