Rick Brewster

Ok seriously, I said we need to get back on-topic instead of keeping this as a soapbox about "why I think the latest Paint.NET should be / should not be / should / should not / Rick's wrong / Rick's right / you're wrong / I'm right". It's all extremely repetetive and completely anti-productive. I made many judgement calls during the development of v3.5 but I didn't keep a diary about every single one of them. You just have to trust that I made an appropriate decision that didn't just take your specific needs/opinions/wants in mind. Thread Closed

I'm sure it's possible but we don't provide support for anything but the latest version of Paint.NET. Sorry. Thread Closed

Yes, we know the bug still exists.

Moved to Troubleshooting

You can't just install .NET 3.5 SP1? Paint.NET isn't supported on any of the beta versions of .NET. No testing has been done at all. If it crashes, please don't come knocking on my door (so to speak).

You have to run /createMsi on a system that already has all the prerequisites installed, e.g. .NET 3.5 SP1. In fact, you'll need to deploy .NET 3.5 SP1 before you do any MSI/AD/GPO deployment of Paint.NET 3.5+.

I'm aware of the market share. Now think of the percentage of that market share that is running into this problem, and that there are already three other (better) ways to install it. (normally, unattended, deployed) .NET isn't a virtual machine. So, correct ... you don't understand the problem I'm not saying your situation is _______ (insert whatever). I'm saying I'm not going to fix this.

I appreciate it Leif. Now, let's get back on topic ...

Don't forget that I'm apparently a big fat jerk for not dedicating my life to porting it to Lunix.

That doesn't make any sense at all :? :?:

I don't have any plans to add this to Paint.NET. Like you said, it's a rare format. If you really really need to squeeze images down to that size, you should work with them at 32-bit and then squish them to the 8-bit+A format as a final post-processing / pre-uploading step.

Oh gosh. Run chkdsk! Sounds like some kind of hard drive corruption.

Sure. But if you're doing administration at that level, then it's expected that you're using AD/GPO and can use the deployment instructions over here: http://www.getpaint.net/doc/latest/en/U ... ation.html And, XP support is just not something that will be improved from here on out. Even if I were to consider this a bug worth fixing*, I couldn't justify fixing it from a cost or strategy standpoint. * Not to imply that the opposite judgement has been made.

"Run as" isn't a common scenario in XP. It's not supported; no testing is ever done in that mode.

I'm sure you're the smartest and most experienced person in the whole freakin' world when it comes to software design. Seriously, why must everyone complain about everything, while simultaneously proclaiming themselves as an expert? I'm sick of it. Shut up or leave.

No, it wouldn't... There'd still be 1 too few pixels after the 'e'

I'll ask my contact in DirectWrite what's up here. Seems we need an extra pixel after every lowercase "e".

Last week I was actually looking at the documentation in the Windows SDK for how to do this ... which, if you've ever seen it, is confusing to say the least. Should be easy to integrate this into the next release, although the "application description" will be simple or absent because I won't have anyone to localize it. For later releases it should be relatively easy to add any filetype plugins into that list, although will require an extra dialog box somewhere (which needs to be localized, hence can't do it for 3.5.x).

Oh I agree, it's a hack. System.Drawing and GDI+ are honestly not that great in many ways.

There is no command-line parameter for this. If your security software disallows this, then you simply won't be able to do it.

The way that Paint.NET has to do this internally is to store a small image resource in its DLL which has an EXIF tag in it. Then, any time there is a need to construct a custom PropertyItem, we load the image, yank out a PropertyItem (any PropertyItem), then set the values to what's needed. So, you simply have to do the same thing yourself. (Do NOT use the methods in SystemLayer -- they are not for plugins. They do change, and your plugin will break.) I hadn't looked at this code in a loooooong time (the Metadata class). It's clearly showing its age. // System.Drawing.Imaging.PropertyItem does not have a public constructor // So, as per the documentation, we have to "steal" one. // Quite ridiculous. // This depends on PropertyItem.png being an embedded resource in this assembly. private static Image propertyItemImage; [MethodImpl(MethodImplOptions.Synchronized)] private static PropertyItem GetPropertyItem() { if (propertyItemImage == null) { Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("PaintDotNet.SystemLayer.PropertyItem.png"); propertyItemImage = Image.FromStream(stream); } PropertyItem pi = propertyItemImage.PropertyItems[0]; // this works because the PropertyItems property returns a copy pi.Id = 0; pi.Len = 0; pi.Type = 0; pi.Value = ArrayUtil.Empty(); return pi; }

Then you should probably uninstall it completely. Most "security" software is overly protective, employing methods based on paranoia instead of science.

Bug filed

Well it's working fine on everyone else's system ... the reference is set up fine.

DivX probably has a shell extension for doing thumbnail stuff that kicks in whenever you do an Open or Save dialog. You'll see this in any other program that you do a File->Open in and navigate to a folder that has DivX files. This is not a Paint.NET bug or issue, it is a DivX issue. Please report it to them.