ral42

Thank you for your helpful post. That's very encouraging news and I'm looking forward to the next version. Regarding your opinion of what constitutes standard GUI behavior, I use Paint.NET instead of Photoshop and GIMP specifically because it's usually closer to what I consider standard GUI behavior than those applications. I'm glad Rick recognizes the difference of opinions when it comes to this subject. Providing an option will satisfy users of both preferences.

I'm looking forward to the option to disable "overscroll". This change was an unwelcome surprise to me when updating Paint.NET. I get that there are certain situations where this could be helpful, but personally I think with scrollbars there's a standardized contract between software developer and end user where essential information is supposed to be conveyed regarding the bounds of the content and the current view. This is a very, very long-standing GUI tradition for good reason. In my opinion, overscroll results in loss of information making it harder to keep track of the size of the image and the current view, and harder to quickly zoom/scroll to the desired view. Please at least give us the option to revert to standard behavior here, even if you don't want to make it the default.

Ok I understand. Thanks for the explanation! I suppose I'll just advise avoiding the clipboard for this sort of thing. Maybe Microsoft will standardize this sufficiently someday, or perhaps more likely, abolish the clipboard altogether.

(I'm making a new thread since I inadvertently broke the rules by continuing one from 8 months ago. My apologies. If anyone wants to see my original more detailed post, go here.) Back in July 2011, the following was written on this forum to someone trying to get an image with transparency out of Paint.NET via the clipboard: However, my own experiments indicate this is not how Paint.NET functions. When copying an image to the clipboard, Paint.NET only puts the real alpha data in its own proprietary clipboard format ("PaintDotNet.MaskedSurface"). All other formats that it provides on the clipboard do not contain real alpha data; only 0xFF (solid / opaque). As a result, it seems to be impossible to copy and paste an image from Paint.NET into any other piece of software while retaining alpha in the image. Is this a bug or the intended behavior?

Has this changed since your post? I just did some analysis of Paint.NET 3.5.10 clipboard behavior and I can't get any real alpha data out of Paint.NET except in its proprietary format. Here's what I tried: 1) Create new 256x256 image in Paint.NET 2) Select all, delete 3) Set foreground color to white with alpha of 186 (0xBA) 4) Flood fill 5) Copy entire image to clipboard 6) Paste into my own .NET app 7) Call IDataObject.GetFormats(), IDataObject.GetData() on each format, and inspect the results: "PaintDotNet.MaskedSurface" (MemoryStream, alpha set to 0xBA - clearly visible in the raw data) "Format17" (MemoryStream, alpha set to 0xFF) "Bitmap" (InteropBitmap, alpha set to 0xFF) "System.Drawing.Bitmap" (System.Drawing.Bitmap, did not inspect) "System.Windows.Media.Imaging.BitmapSource" (System.Windows.Media.Imaging.BitmapSource, alpha set to 0xFF) "DeviceIndependentBitmap" (MemoryStream, alpha set to 0xFF) I've also tested the following: Copy from Word 2010 into my app: alpha is preserved (via "Bitmap" clipboard format) Copy from Word 2010 into Inkscape: alpha is preserved Copy from Paint.NET into Word 2010: alpha is lost (solid white background) Copy from Paint.NET into Inkscape: alpha is lost (solid white background) So, here are some possible theories: Paint.NET is only intended to interoperate with itself when it comes to putting real alpha on the clipboard (suggested by my observations) Paint.NET is supposed to put real alpha data on the clipboard in formats other than its own, but a bug is preventing it from doing so (suggested by your post) My procedure is flawed (always possible) Your clarification would be much appreciated.