Fixed Cut and paste in TC's file/folder view does not remove file

In the list view, r-click and "Cut" a file. Go to another folder and r-click and "Paste". The copied to the second folder but not deleted from the first (unlike explorer).
But the drop/paste doesn't have anything to do with the cut.

Sorry for my persistence. If I make a right click in LIST VIEW on a folder and then PASTE, it works. If I make a right click in LIST VIEW on a "emtpy/white" area, then an own context menu appears (NOT from windows?! - at least I haven't see a such context menu before somewhere) and it works not.

Context menu from TC ...

This "own" context menu does not react to the "cut".

Context menu from Windows would be ...


If I am right, the solution could be: replace this special context menu through a "right" context menu from windows. I suppose: this context would react to the "cut".

EDIT: Note also: even the original Windows context menu does not react to a cut till the PASTE is maked! So, in this sense, the PASTE has to do with the cut.
Last edited:


Staff member
May 14, 2008
Ok, it's NOT a TC context menu.

Can you replace this WINDOWS context menu with ANOTHER windows context menu - I suggest that of Windows EXPLORER?

Because: the context menu in List view with click on "empty space" is definitive NOT the same as the "normal" windows context menu (at least it looks different). I have NEVER seen a such context menu ANYWHERE before.

Or in other words: why not take the known windows context menu (see last picture) for this purpose?

However: the function "cut and paste" does NOT work with the actual implemented solution for this purpose (and the user probably does not check this).

If there is no possibility (with replacing the context menu) - the "cut and paste" function should be "deactivated" (no menu (entry)) for this purpose IMHO.


Staff member
May 14, 2008
TC is using the documented, publicly available control (& its internal context menus). Windows Explorer is using an undocumented, custom control. If you can convince Microsoft to document & make it available, I can switch to that.

The issue isn't with Paste, which works just fine. It's with the Cut, which isn't passing the necessary info through the clipboard object so that Paste can recognize that it's a cut & not a copy.
No, I do not have such an influence to microsoft, I believe - I wish, I would have.

My intention was (also): to avoid problems - even for users without this knowledge - with a "cut and paste" which is not always a "cut and paste" ...

You say, it's the CUT, ok.

Then, then let me guess: you can't fix the cut, and you can't remove the paste in that List window (unless a directory is "selected"), right?

If you say: WE can't fix it: how other developer have implemented such things (for example in Speed Commander or Total Commander) or even in Freeware. Maybe you could ask somebody or look in the source (if it's not closed source of course) or something like that. I don't know, I'm not a programmer/developer.

It would just great if this bug could be fixed, and it IS a bug, or not?
Last edited:
I had a play with cut and paste prior to updating to build 23. Worked ok here. Paste copied the file to the new directory and then deleted the old copy. Now its disabled as you said.
Cut and paste with DROP a FILE ON a DIRECTORY NAME WAS NOT A PROBLEM, that was not broken (also not within List View) ...

Drop a cutted file within List View NOT on a directory name - instead, drop it elsewhere on a "blank" area ("white space") ... that was the problem ...
Last edited: