Programmatically determine clipboard source information - windows

When a user copies text to the clipboard, is it possible in Windows to programmatically identify the source file (and/or URL) and text position?
I have looked at a bunch of clipboard management applications (Ditto, clipboardFusion, ArsClip, and ClipDiary) and none appears to record the source of a clip.
It is my belief that this functionality in not possible, but I would like another opinion or two before I abandon my attempts.
I currently think the only way to achieve the desired behavior is to create an add-on / extension for every application that will be copied from. The extension would override the applications normal copy to clipboard behavior with a new format that adds the additional information. The key applications for me would be adobe acrobat (or another pdf reader) and a browser.

Windows does not require any source information to be given when setting clipboard data. Additionally, the only information needed to enable calling that function is a window handle. As such, the best windows could give you in a general case is the window handle that set the clipboard data via GetClipboardOwner.
Some applications set some of the formats on the clipboard to the source location of other data on the clipboard, but again in a general sense, there need not even be any source data; an application can just place random arbitrary data on the clipboard.
For your specific use case, you may be able to write a grease-monkey script to add your meta-data, and as firefox/chrome can display PDFs you might even be able to use the same script for PDFs.

Related

How could Windows clipboard remain format informations like color between a browser and the OneNote?

Just out of curiosity. I observed that when I copied some webpage text in Firefox that contained font size and color (set by CSS) and pasted them into OneNote, the font size and color were copied along with it. How is this formatting information transferred between the two applications?
OneNote offers several paste operations: keep the original formatting, merge formatting, and keep only the text. But this formatting information is supposed to be saved to the Windows clipboard when the copy button is pressed? I have no knowledge of Windows application development, but I assume that Firefox is the active window when I press the copy key, so it is Firefox that accepts and handles this keyboard event?
I went searching for Firefox's guidance documentation and didn't find anything related to the system clipboard.
By reading Microsoft technical documentation I learned that there are many kinds of clipboard data formats (yes, because Windows' clipboard can handle many data formats, it needs so many formats). If you want to pass data between two applications, I think this format must be one of the standard formats, but I'm not sure which one.
Or is the truth a completely different mechanism from my guess?
When an application is asked to copy something to the clipboard it can store "that something" in multiple formats simultaneously and when another application is asked to paste, it can pick from all the applicable formats.
OneNote perhaps picks CF_HTML > CF_RTF > CF_UNICODETEXT. On the other hand, when you ask it to paste without formatting it might pick CF_UNICODETEXT first (and if it is not available, manually strip the formatting from the HTML/RTF).
There are various tools that lets you see which formats are on the clipboard...

Get filename/path of the document currently open in another program/window

I'm working on a program that acts as a Windows Accessibility / UI Automation API client, consuming accessibility data from other programs (much like a screen reader does). I'm looking for a way to get the full path of the current "document" (or other file) open in a program. So, for example, Word might give me the path to the current .docx file, Paint the path to the current image file, WMP the path to an audio or video file... you get the idea. Is there a way to do this?
On a Mac, I'd use NSAccessibilityDocumentAttribute, but Windows doesn't seem to have an equivalent accessibility property. A few other questions I looked at:
Getting the path & filename of the open document in any Windows application (last answer in 2009, may have been unaware of accessibility APIs, no answer gives reliably accurate data)
How to get filename and path of file opened in Notepad? - five years old, specific to one program, only answer given is incomplete.
So... is there any equivalent to NSAccessibilityDocumentAttribute, and if not, is there a reasonable way to re-implement it (possibly doing stuff outside of the accessibility tree / API)? It's more important that this return correct information (i.e. never give me a file that isn't open in the relevant program/window) than that it be universally available.
I'm using C# (via System.Windows.Automation for accessibility) but could use other languages if needed, so long as they'll run on Windows 10 (downlevel support nice but not mandatory).

How is "Cut" command in Windows executed globally and why data recovery is not possible?

So, I wondered several times, what's the actual low-level difference when using "Cut" command in Windows, apart from Copy-Paste-Delete one, with focus being on the "Delete" part.
However, until now it wasn't really important, but I had some issues recently when using Cut-Paste in my application, when having an error in the process. The file that was being Cut-Pasted doesn't exist anymore, and can't be recovered by any data recovery software out there.
So I ran some tests, and it seems that it's true.
Anybody knows how the Cut-Paste commant works?
The clipboard
Windows manages an internal object called The Clipboard and provides an interface to put data in the clipboard, get the data from the clipboard, get meta information about the content of the clipboard (check if it is empty or there is any data there, get the type of the data a.s.o.). The operations with the clipboard (get, put) have copy semantics. They do not destroy the source data. The object currently kept in the clipboard can be get from there any time you want, it is not removed after the first "get" operation.
The clipboard can store a single object at any time. When an application puts something in the clipboard the previous content of the clipboard is lost. The clipboard can store the same data in multiple formats; is the application's responsibility to put it there in multiple formats, to query about the available formats and get the data in the format it wants. For example, an HTML-editor can put in the clipboard both the HTML source code of the selected text and the text as it is rendered in the browser (with different colors and fonts etc). Then, the same application or another application either gets the needed format depending on the context or provides a "Paste Special" command where it asks the user what format to use (see Microsoft Office programs or OpenOffice programs for example).
The clipboard is available (through the operations provided by Windows) to all the applications that want to use it and it is a powerful method to transfer data between applications. However, due to different formats used by different applications, it is not always possible to get data from an application and put it into another one. For example, a plain text editor like Notepad cannot Paste an image previously put in the clipboard by Paint, Photoshop or another graphic editor. This happens because Notepad just don't know how to handle anything but plain text.
The Cut, Copy and Paste semantic for applications that handle content (text, images etc)
It's up to each application how they use the clipboard. Implementing the Cut, Copy and Paste operations usually means:
Cut - the application puts (copies) to the clipboard the object selected in the document then remove it from the document;
Copy - the application puts (copies) to the clipboard the object selected in the document (but it does not remove it from the document);
Paste - the application gets (copies) from the clipboard the object stored there and puts into the current document; depending on the application, it is either inserted at the position of the caret, or replaces the current selection or it is simply inserted into the current container (folder or directory, in Windows Explorer); the content of the clipboard is not changed; a subsequent Paste is possible and it will do the same;
The Cut, Copy and Paste semantic for applications that handle files (Windows Explorer, for example)
Windows Explorer and other programs that works with files and not with pieces of text or image use a different semantic. The biggest difference from the model above is that Windows Explorer works with file names (with full paths) and not with the content of those files. It does not reads the file and it does not place the content of the file in the clipboard.
Cut - Windows Explorer copies the full path of the file into the clipboard; it also sets an internal flag that says "the file whose path is in the clipboard is meant to be moved by the next Paste"; it uses this flag to be able to render the cut file dimmed in all its windows until the operation completes or is aborted; it does not move or remove the file at this point;
Copy - Windows Explorer copies the full path of the file into the clipboard; it does not touch the file itself; then it clears the flag that was set on the last Cut operation; the file that was previously cut (if any) is now rendered again using the same style as the other files (no dim, no nothing); in other words, a Copy cancels any previous Cut;
Paste - Windows Explorer gets the file path from the clipboard; it copies the file pointed by that path into the current directory; what it does after that depends on its internal flag for Cut operation; if the flag is set then the file was cut before (see Cut and Copy above) then it will remove the file from their original location and also the flag; otherwise (when the Cut flag is not set because the last operation was a Copy), it does not affect the original file in any way.
Remarks on Windows Explorer's behaviour
It's important to notice that Windows Explorer does not put the file content in the clipboard. If you use the Cut or Copy command in Explorer then you delete the file, it will not be able to Paste it in a different directory because the file does not exist any more and it cannot copy an object that does not exist.
Also, a file that was Cut in Windows Explorer cannot be Pasted multiple times in different directories because Explorer pairs the Cut with the first Paste (if there was no Copy in the meantime) and produces a move operations from them. After the Paste the Cut flag is removed and, even if it is not removed, there is no way to move the file again because it is not on the path stored in clipboard any more.
I'm not on Windows now (I didn't use Windows in the last 3 years) but as far as I remember, you can Copy a file once then Paste it several times; a Copy followed by a Paste produces a copy of the file and as long as the source is still there, subsequent Paste operations can produce more copies.
Sure, an error that happens on the most inconvenient moment can produce data loss. Due to the way Windows Explorer handles the files and the errors that might happen, it is very unlikely that it accidentally removes a file during a Cut-Paste operation without putting it into the destination folder.
I'm absolutely confident that more files are lost due to human error than because of errors that happen during the execution of Windows Explorer.
Other applications
Other applications work in different ways. Most of those that deal with content (text, image, sound, video, etc) work as explained in the section about content. Most of those that deal with files work similar with Windows Explorer.
Another application can get the data that was put in the clipboard but Windows Explorer. It's up to that application to interpret it as plain text and put the file path it gets from clipboard into the current document as is (Notepad works this way) or recognize it is a file path and attempt to copy the file (or do something else with it). Another window or instance of Explorer does it, maybe other file managers do it too.
Multiple-clipboard applications
The programs from the Microsoft Office Suite (Word, Excel a.s.o) and also some other applications implement a multiple-clipboard feature. This functionality is not provided by Windows clipboard. These applications work with the clipboard as usual but the also keep a history of the objects they put into the clipboard in the past and offer the user a list of these objects for re-use. For compatibility and integration with other applications they also get from and put into the clipboard the object that the user selects for re-use. The Windows clipboard, however, still contains a single object, the last one that was put there by any application.

Clipboard copy action - whose file is the content?

I need to track copy-paste actions in Windows and Linux (I'm assuming gnome/unity) towards my app monitoring the clipboard content and the originating file's location (path)
How can I accomplish this?
Clipboard transfers contain data, not metadata. They may not be a "file" at all. If you want a standard GUI metaphor for moving files around, maybe you could consider Drag & Drop.

Show contents of the Windows clipboard

How can I see what the Windows clipboard currently contains without using the paste operation?
I don't want the "pasted-to" application to perform any actions on the clipboard (for example, formatting text and converting).
Is there a tool which shows the clipboard's objects and their format (CF_BITMAP, CF_TEXT, etc.) and content (in simple bytes for example)?
There is a list of clipboard manager tools at Wikipedia:
Clipboard manager
ClipX allows you to view a log of previous clipboard entries by pressing Ctrl + Shift + V.
NirSoft offers a free “Inside Clipboard” utility which allows you to see the raw clipboard contents and different formats. It’s close to what you would see with a programmatic API but with a nice GUI. Its GUI includes hex view. It also allows data to be exported and allows saving a snapshot to a .clp file which it can open and allow you to examine later.
If you need to see things at the level of the programmatic API to quick check things without writing a program yourself, I recommend this tool.
If using .NET you can query the Clipboard object.
How about the regular old Clipbrd.exe clipboard viewer from Windows XP?
That'll still run on Windows Vista and Windows 7, IIRC.
Select run from the start menu.
Enter "clipbrd.exe" in it.
Then you can see the clipboard items in the Windows systems.

Resources