Community
Participate
Working Groups
M5 1. select a file in a windows explorer 2. cut it (cntrl-x) 3. select an eclipse project 4. select "Paste" from popup (or cntrl-v) The file will be added to the project but the file in the windows explorer remains, and unfortunately is still in "cut" mode (ie. 'grayed'). It wasn't clear to me if we supported cut from windows. If we don't, then maybe paste should be disabled but instead copy should work?
Knut, can you comment on this?
I don't think we have a way of knowing if clipboard data was copied or cut to the clipboard. We only know that there is data on the clipboard. CC'ing Veronika to confirm. We do distinguish between copy and move when you drag a file from the Explorer to Eclipse Resource Navigator. MS Word does the same we do. A paste inserts the data and leaves the file in the Explorer.
Currently there is no "cut" support on the clipboard in either direction (being a cut data source or a cut data destination). New API would be required. This would be a good enhancement for 2.2.
Reopening to reassign
To be considered for 2.2 stream then
Note that with the current behaviour, the user is left with an item in the windows explorer that is 'permanently' in cut (grayed) mode. Its not terrible, but its likely somewhat disconcerting and looks funny.
If you press ESC in the Windows Explorer the funny item state will go away. Agree that this is not good.
The problem of having Windows in a "suspened" state is addressed by bug 38952. Leaving this bug report open to track the requirement for a bi- directional "cut" API.
In one of my applications (a tool for file search) I'd like to add the possibility of cutting files so that they can be pastet in the windows explorer. Is it such a problem to implement the cut-feature for SWT? Or is nobody elso out there who needs it?
It would be nice, but frankly impossible. In Win Explorer, when a file is cut it is internally marked as having been cut. Technically, the file still exists just as before until the file is pasted *in explorer.* When the file is pasted, the file marked for cut is moved to the present location. This isn't possible to implement in SWT, and seriously doubtful that it could be implemented in Eclipse without some flaky hack because it *is* internal to Windows Explorer.
But why does it work in other windows applications, for example the image viewer ACDSee? I have searched in MSDN and found the following article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_programming/transferring/datascenarios.asp Please take a look at the sections "Handling Optimized Move Operations" and "Handling Delete-on-Paste Operations". I think this describes the way how to implement it.
Created attachment 39258 [details] An implementation for the Preferred Drop Effect The Windows Explorer stored the information whether to copy or paste the files in a transfer type named "Preferred DropEffect". (All documented in http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_programming/transferring/clipboard.asp?frame=true#CFSTR_PREFERREDDROPEFFECT). I have implemented a PreferredDropEffectTransfer type which can read this information. It works well with files copied by the explorer. But I have problems with the "Preferred DropEffect" stored in the clipboard each time SWT puts something to the clipboard. Both data structures seem not to be compatible. My knowledge about the whole DND/Clipboard internals is very limited and many of the SWT core methods are not commented. So I hope you will use the attached source code the fix the problem and integrate the clipboard drop effect support.
Created attachment 39900 [details] Clipboard class supporting delete-on-paste I've solved the problem. Two simple extensions to the Clipboard class enable the support for delete-on-paste. All changes are compatible to the existing implementation of the clipboard. 1. Setting the clipboard contents The private method GetData(int, int) sets in its original version the preferred drop effect to COM.DROPEFFECT_COPY. I have changed this fixed value to a variable set by new setContents() methods. If COM.DROPEFFECT_MOVE is provided the Explorer automatically moves the files instead of copying them. 2. Getting the clipboard contents After (or before) calling Clipboard.getContents() you can call Clipboard.getPreferredDropEffect(). If the method returns DND.DROP_MOVE you know that you have to move and not to copy the files. I'm reading the Preferred DropEffect using a separate Transfer class because it was easier for me to implement. I think you will implement this as a clipboard internal method.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
