“Copy image data” loses transparency

[XnTriq]

An unhandled exception has been detected: "Floating point division by zero" ; An unhandled exception has been detected: "List index out of bounds (0)" ; Access violation

I ran into this problem as well, but I assumed that it's a bug in Clipboard Format Spy and switched to InsideClipboard for my tests

And something else. Previous test were made with http://www.xnview.com/wiki/logo.png. Does keeping transparency work for you with http://www.xnview.com/assets/img/app-xnsoft-512.png ?

It doesn't work for indexed PNGs with alpha-channel transparency (like app-xnsoft-512.png), but that's probably due to the known limitaion mentioned in one of my previous posts.

[Mixer]

It doesn't work for indexed PNGs with alpha-channel transparency (like app-xnsoft-512.png), but that's probably due to the known limitaion mentioned in one of my previous posts.

IMO, if XnView does not create custom clipboard formats but uses CF_DIB or CF_DIBV5 (which are basically BMP) for anything put into clipboard, then I think user's perception should prevail over image file attributes and what is transparent should be copied as transparent. What if XnView will convert internally every file containing transparency into 32-bit BMP with alpha channel before putting it into clipboard? If you take http://www.xnview.com/assets/img/app-xnsoft-512.png, open in XnView Viewer, select menu Image -> 32 bits, then Ctrl+C, Ctrl+Shift+V to import clipboard, discard changes made to original file, you get picture with transparency (and another CF_DIB object with NULL handle). Picture containing only 8 colors looks the same when converted to 32-bit, so I don't think such conversion is a problem for eyesight.

[XnTriq]

What if XnView will convert internally every file containing transparency into 32-bit BMP with alpha channel before putting it into clipboard?.

I'm all for it! I just hope it's not too difficult to implement.

[xnview]

Question to Pierre. When ClipboardNewMethod=1, do you call SetClipboardData() with handle set to NULL? Do you call CloseClipboard() after CF_DIB is pushed to clipboard with ClipboardNewMethod=1 ?

I don't understand, ClipboardNewMethod=0 or 1 works in the same way. I call SetClipboardData with the handle of the CF_DIBV5 or CF_DIB. CloseClipboard is called

[Mixer]

Then why if ClipboardNewMethod=1 copying to clipboard may produce CF_DIB with NULL handle?

The system implicitly converts data between certain clipboard formats: if a window requests data in a format that is not on the clipboard, the system converts an available format to the requested format. The system can convert data as indicated in the following table.

And from the table you can see that system must be capable of converting CF_DIB to CF_DIBV5 and vice versa. But with ClipboardNewMethod=1 it can't for some reason.
And it's even more strange that InsideClipboard always shows NULL for CF_DIB made from logo.png only in Windows XP SP3.
You can't paste such clipboard into HeliosPaint because it errors "java.io.IOException: system clipboard data unavailable". GIMP says such clipboard is empty too (even though there is CF_DIBV5). While if it was nontransparent jpeg copied, then pasting works. Looks like some troubles with transparency implementation.
In 2K SP4 InsideClipboard shows Memory and valid size for CF_DIB, but pasting either crashes applications or is pasted black rectangle.

[after more experiments deleted part of my post]

Well, it appears some apps are buggy, some can't handle alpha channel in any other way but replace it with color, some can import CF_DIBV5 if CF_DIB is not available (like XnView and Pixelformer), some report errors (like HeliosPaint and GIMP). But better fix this NULL handle.