XYplorer Beta Club

Awesome! I'll patiently wait for the things to come

I bought XYplorer for my office, where everything is stored on a network drive. I used "CheckSubfoldersExistOnNetwork=1" because I thought it would only affect the start up time of XYplorer. After a lot of trial and error, I found that the check for subfolders was what caused XYplorer to freeze ever...

I took a slightly different approach: icon names instead of if-statements :biggrin: $state = property("#303", <cc_item>); // WIN 1809+ if ($state == "") { $state = property("#304", <cc_item>); } // WIN 1803- return "<xyicons>\OD $state.ico"; In case you encounter a generic file icon, find the sync s...

Oh nice, this helps a lot
It would be nice though, to not obstruct the tree and have the info panel only inside the tab view. Well, I guess I can live with the wide info panel ...

The info panel has a lot of fixed size content that can cause problems on low horizontal resolutions. E.g. on my 1080p screen in landscape mode, I cannot use the search (find files) because the 'find files' button and the search filters don't fit on the screen. However, there is a lot of wasted scre...

Hm, I guess that means "problem solved"

I wasn't aware that ContextMenu64.exe is an AutoHotkey script. I will switch back to the XYplorer internal 32-bit menu and forget about the whole thing.

Thanks for the information!

Thanks for your reply! I am using the 64-bit context menu. The 32-bit menu does not cause any problems. And I found that the "error" occurs as soon as the network drive is expanded in the tree pane, independently of any settings. Apparently, expanding folders on the network drive worsens the problem...

Solution: Use the 32-bit context menu instead of the 64-bit menu. The 64-bit menu is a compiled AutoHotkey script that cannot be fixed because the source code is not available. (I am not talking about the start up time) My PC has a NAS permanently attached to it via SAMBA. For a while now I am stru...

Thanks, the custom context menu works well
I wasn't aware that the shell context menu cannot be forced to use anything else than the shell for file operations, apart from adding an additional copy/move command of course ... which would be confusing, I guess.

The exact names are "Copy here" and "Move here". These commands are available in the context menu after dragging a file/folder some place with the right mouse button pressed (mouse cursor with "plus" icon).

I have only one pane active. I tried copying within a tab, from one tab to another and from a tab into the folder tree. Every time, Windows handled the copy operation.

"Custom copy" is activated for all copy and move operations. When I drag and drop anything with a right-click and chose "copy or move here" in the context menu, Windows is handling the operation. The Custom copy handler only works, when I drag and drop with a left-click or when I use the context men...

Hm, I kind of "fixed" my problem by using "Custom Copy Operations".
Strangely, this was already activated. I had to disable the option and enable it again...

When I try to move a folder by dragging it onto a target, I get a peculiar error message "Can't find the specified file.". It doesn't matter if I drag with the left or right mouse button. With Windows Explorer, I can move any folder in this way. With XYplorer, I can copy and delete folders and I can...

Alright, thanks for the information.