Separate names with a comma.
Discussion in 'Support' started by djspits, Jun 24, 2015.
TCC 17.00.77 x64 Windows 8.1 [Version 6.3.9600]
Confirmed in TCMD 18.00.19 x64 (Win 7) via Folder/List View too. Drop in FOLDER works - only a drop direct in LIST has this behaviour (here) ...
Not sure what you're trying to do -- a cut will not delete a file. There is a separate "Delete" entry in the context menu for that. (This is Windows' context menu.)
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).
It's a Windows control, and Windows is handling the cut & paste.
But the context menu is not the same for this special purpose - I mean the DROP in the LIST VIEW - see my picture above. If I drop in the FOLDER VIEW, then it's the normal context menu from windows - and then it works.
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.
If I "Cut" something on the desktop, its icon is greyed. If I choose "Paste" from the three-item folder background context menu in "List View", it's pasted but the source is not deleted (and remains greyed). I agree with Alpengreis, TCMD doesn't seem to be using the right folder background context menu.
TCMD isn't using ANY context menu -- as I said before, it's a Windows control & Windows context menu.
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.
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?
I can't fix the cut, so I've disabled it in the context menu.
That's good! Thank you, Rex!
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 ...
Yes I noted that, when pasting onto a directory name no problem but seized up when trying on the file listing. I didn't quite understand the problem but was confirmed when I see the cut option now greyed out.