[HeDiBo]

Here is the Folder Test program again: [attachment=8591:acShellBug2.zip]

but with a little twist: the forms contain an extra Add Folder button.

They work OK on the standard and the DevExpress version. But in the AC version, after creating the directory, AC hangs.

[HeDiBo]

To really make it a feasible addition to the ShellListView control, the MakeNewFolder should be augmented as follows:

MakeNewFolder should be parameterized with a parameter const NewName: String (empty if the current behavior is what is wanted). It should return a Boolean, indicating if it succeeded.

AfterNewFolder is an event, that passes the new full path name of the created folder (because its name can be changed with a sequence number, like “New Folder (3)”

This would also work:

Code:

function MakeNewFolder(const NewName: String; out CreationResult: Integer): String;

which would return the full path of the created folder or an empty string if the folder could not be created (in that case CreationResult contains the Windows error code).

That makes the thing complete and workable.

The default name for the new folder should not be “New Folder” but the localized version of that (in Dutch that would be “Nieuwe Map”). It's not easy, because the string ID changes with Windows versions. This is a good starting point for finding the localized string.

[Support]

Thank you for the demo and your suggestion, I will check it soon.

[HeDiBo]

'Support' wrote:

Thank you for the demo and your suggestion, I will check it soon.

I'v sent you a possible replacement for acShellCtrls.pas by private mail.

[Support]

Try this attached file, plz.

You changes were added also.

[HeDiBo]

'Support' wrote:

Try this attached file, plz.

You changes were added also.

Thanks a million.

I'm afraid the exception is back.

Using this test project: [attachment=8607:acShellBug.zip]

click on the “Select Path AC” button, then navigate to a folder and press the “Add Folder” button on the bottom. I got this exception immediately:

[attachment=8608:acShellBugException.jpg]

This was the stack:

[attachment=8609:acShellBugException.txt]

It didn't happen all the time, but if it didn't happen, a new folder was not created. An exisiting folder (not sure which) was offered for renaming (the foldername became in Edit mode).

[Support]

Something wrong with files in the demo, can you check it please?

[HeDiBo]

'Support' wrote:

Something wrong with files in the demo, can you check it please?

Very sorry about that

Here's the correct one: [attachment=8620:acShellBug.zip]

[HeDiBo]

One of the problems with the exception, is the call to CanEdit here:

Code:

if CanEdit(Selected) then
Selected.EditCaption;

The call to CanEdit goes to the parent TCustomListView which is wrong here. What you need is this:

Code:

portected
function CanEdit(Item: TListItem): Boolean; override;
.
.
function TacCustomShellListView.CanEdit(Item: TListItem): Boolean;
begin
Result := True;
if Assigned(FOnEditing) then FOnEditing(Self, Item, Result);
end;

That brings the OnEditing event of sShellListView into play.

The exception occurred because the MakeNewFolderEx was called with the wrong parameter (the full path in stead of the single foldername). That could be checked in the intro to the call by analyzing the passed folder name.

When these things are corrected, the EditCaption call should be analyzed. As it is, it doesn't work (the selected new foldername flashes but entry of a new name is not possible).

[Support]

Hello!

Try this new file plz.

[HeDiBo]

'Support' wrote:

Hello!

Try this new file plz.

The OnEditing event of the TsShellListView is never called, because of the mistake I described in the previous post (OnEditing of the parent is not set, because it is a different event). By implementing my little change, that problem is solved.

This piece of code is wrong:

Code:

Selected := nil;
for i := 0 to Items.Count – 1 do
if Folders.PathName = DispName then begin
Selected := Items;
Break;
end;

The DispName is the simple folder name, where PathName is the full path. I think this is better:

Code:

Selected := nil;
for i := 0 to Items.Count – 1 do
if Folders.PathName = NewDir then begin
Selected := Items;
Break;
end;

When this change is applied, you are able to edit the folder name. But after entering the name, the program enters an endless loop, having to do with threads I think (I'm looping in something called ntdll.LdrInitializeThunk).

So, this is not a very good version, I'm afraid.

[HeDiBo]

After making the necessary changes (the loop I could not fix) there's still a significant problem. The directory just made does not become the current directory in the buddy TreeView. Most of the times, the new directory isn't present in the TreeView. Only closing the whole form and reopening it will show the created folder in the TreeView.

[HeDiBo]

The bug of not calling the OnEditing event is also present in the standard ShellCtrls.pas file

[HeDiBo]

The CanEdit procedure needs a bit more. Apparantly the Item parameter can be nil. This happens on a rename of a folder upon a right click with property AutoContextMenus set to true. This is the augmented function:

Code:

function TacCustomShellListView.CanEdit(Item: TListItem): Boolean;
begin
Result := True;
if Item = nil then Exit;
if Item.Index >= Items.Count then begin
Result := False;
Exit;
end{if};
if Assigned(FOnEditing) then FOnEditing(Self, Item, Result);
end;

But as mentioned above, renaming the folder leads to an endless loop.

[Support]

Hello

Try the new attached file, plz.

[HeDiBo]

'Support' wrote:

Hello

Try the new attached file, plz.

Nice changes

One observation:

If I create a new folder with MakeNewFolderEx the TreeView does not (always) reflect that:

In this situation I click “Add Folder” which results in MakeNewFolderEx('New Folder').

Before click:

[attachment=8626:ShellBeforeCreateFoilder.jpg]

After click:

[attachment=8627:ShellAfterCreateFoilder.jpg]

The TreeView does not reflect the change. AutoRefresh and AutoExpand of the TreeView are both True. I think not only should TreeView show the change, it should also select the newly created folder.

[HeDiBo]

Apparently, in the last version of Windows 10 the localization of the term “New Folder” has changed. This statement:

Code:

new_folder_id := FindResourceStringId(shell_handle, sEngName, $409);

returns 0 now and takes for ever to complete!! I do not know now how to get to the proper localized name (in Dutch it is “Nieuwe map”). I think the best way now is to include it in the resource strings of AC. Unless of course you can come up with a better way of doing it.

[Support]

The FindResourceEx function doesn't work under WIndows 7 sometimes also, seems.I will research it and I hope to find a better solution soon.

[HeDiBo]

'Support' wrote:

The FindResourceEx function doesn't work under WIndows 7 sometimes also, seems.I will research it and I hope to find a better solution soon.

You seem to have fixed it good in AC 13.16

I saw you used this piece of code to get at the localized name for New Folder:

Code:

LoadString(FindResourceHInstance(shell_handle),
16859, Buffer, Length(Buffer)))

Are you sure the value 16859 will stay the same over new Windows versions?

[Support]

I think, resource number should not be changed in the future, but this code may be patched easily if future Windows will use other numbers in the resource table.

And using of fixed number is much faster than searching seems.

[Author]

Posts