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

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#4
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).
 
#8
But the drop/paste doesn't have anything to do with the cut.
Okay.

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 ...

tc.jpg

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:

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#10
#11
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.
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#12
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.
 
#13
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:
#17
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: