AutoHotkey Community

[Moderator's note: Topic moved from Bug Reports.]

New to the forum (not so much autohotkey), sorry if I don't use the best posting "protocols". I am having trouble getting Autohotkeys to recognise that the clipboard is not empty and that it can infact paste a file, when copying a file from a compressed folder (specifically a .zip).

Simple code being used to check: *Edit: Working solution provided by user "jeeswg": *
It always claims the Cliboard is empty when copying a file from a compressed folder, even though it isn't and I can perfectly paste the file (Windows obviously does the extracting for that file in the background/hidden). Is there anyway to see if Windows can paste?

Thanks in advance.

- Here are some ideas: - Note:
if Clipboard =
or:
if (Clipboard = "")
will only check if the clipboard contains text, but there may be other clipboard formats on the clipboard.

The DllCall solution does not seem to notice loading compressed files in the cliboard either but ah, the ClipWait method works great. A bit disappointed that it feels like a workaround, but hey, it works great and it's clean.

Cheers!

- I created a zip via 7-Zip, containing one file, I copied the path of the zip (shift+right-click, Copy as path), and pasted the path into the Explorer address bar. I copied the file inside the zip to the clipboard.
- I got the following information via NirSoft InsideClipboard. Note: another useful Clipboard utility is Free Clipboard Viewer. - Based on this, you could edit my script from earlier, but use something like vFormat := 49296.
- [EDIT:] A more general approach: - I tried a few benchmark tests (I wanted to see how fast ClipWait was):
jeeswg's benchmark tests - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 78#p190278

It's not a file. Until you extract it, it's just data inside a zip file. Clipboard only returns filenames or text.

= not a bug.

jeeswg, thanks again. Nice tip, I will look into clipboard information software, so I'll be able to actually see what I can use to make the code work as expected.

lexikos, ah okay sorry, I had thought Clipboard stored any data (or a string representation of it if needed) as long as windows had something to paste.

- The Clipboard variable is quite unusual in that, if you copy files to the clipboard, it gives you the list of filenames. In many (all?) text editors, if there is no text on the clipboard, it won't paste the file list.
- However, I like this behaviour, and wouldn't necessarily change it. In my Notepad alternative, when it's finished, I might make this the default behaviour. If no text is found on the clipboard, and you press ctrl+v, paste a file list, if available.
- The Clipboard variable is empty when you copy from inside a zip, but shows a file list when you copy from inside a folder, although in both cases you're copying files in an Explorer window. Probably because the Clipboard variable is based on checking for text in certain clipboard formats but not others.

The Clipboard variable technically doesn't store any data - it passes data to or retrieves it from the system.

There is no universal mechanism to get a "string representation" of arbitrary formats stored on the clipboard. The source application can store text in addition to that other data. If it doesn't do that, the data is not text, and you cannot paste into a text editor or text box. AutoHotkey does only one extra step beyond retrieving text; it converts CF_HDROP (a list of filenames) to text.

As jeeswg's post indicated, when you copy a "file" from inside a zip in Explorer, the clipboard gets a list of IDs which the shell can use to figure out the name of the object and the data that comprises it. If you copy from a zip to a zip or another special shell object, there might never be a file.

The string "Shell IDList Array" corresponds to CFSTR_SHELLIDLIST:

CFSTR_SHELLIDLIST
This format identifier is used when transferring the locations of one or more existing namespace objects. It is used in much the same way as CF_HDROP, but it contains PIDLs instead of file system paths. Using PIDLs allows the CFSTR_SHELLIDLIST format to handle virtual objects as well as file system objects.
Source: Shell Clipboard Formats (Windows)

The number may change. To get the current number, you must pass "Shell IDList Array" to RegisterClipboardFormat.

Alternatively, you can probably pass it to the HasFormat() method of WinClip.

Thanks for the further clarification guys.