Paint.NET v3.5.6 Beta

Every so often an update is necessary to fix 1 bug. This is one of those. Before I describe it, you should head over to the forum and download the beta. I am not making it available via the built-in updater.

The bug in question was reported only recently over on the forum, although I’m pretty sure it’s been in the product since the v3.0 release in early 2007!

It’s classified as a data loss bug, although thankfully it’s a relatively minor one. When Paint.NET starts up, it creates an initial/default image (blank and 800×600) if it wasn’t told to open a specific file. Then, when you eventually/probably open another image it will close that initial/default image as long as it wasn’t modified. The idea is that if you didn’t modify that initial image then you probably don’t care about it, and closing it doesn’t result in any data loss (it’s pretty easy to recreate a blank 800×600 image).

Well, I messed up a little on the implementation of determining whether the image was one that could be automatically discarded. I was only checking the “dirty” bit, which powers the little yellow asterisk you see in the thumbnail list when an image has been modified but not saved. The problem comes with when you modify that initial image, then save it, and then open another image. Paint.NET will incorrectly close that initial image (because the “dirty” bit is set to false) even though you still have items in the history list.

This is especially problematic when you work with a bunch of layers, then save in a format that does not support them (e.g. anything but .PDN). You may want to go back and undo the flatten operation that was performed while saving that image, then make further changes, etc. Inadvertent data loss is the unfortunate result.

And before everyone asks: nothing else is being changed in this release! No new features or tweaks or anything. Those are all being saved for the v4.0 release.

Now, go have a happy Halloween. Please don’t drink too much. I’m personally going out in an astronaut costume, which is pretty awesome.

Not to mention how some bugs have incredibly long life spans. There are some bugs which I’ve passed on fixing because 1) the risk was high to implement a fix (maybe the fix was tricky and required a lot of testing, and/or it was likely to introduce other [potentially subtle] side-effects and therefore more bugs), 2) there was a workaround, 3) because of 2 the impact was minimized, and 4) if the bug had been around for that long, and I hadn’t received many reports/complaints, then it probably wasn’t affecting many people. For this bug, however, it’s data loss which immediately brings it to the top of the list. Also, the risk of the fix is low — the logic was very easy to implement, requiring minimal changes (only a single ‘if’ block!).