Rick Brewster

It's usually not spam if they don't list a website in their profile. Spambots do that to artificially increase their linked-to count. DennyUA has no website listed, and is therefore most likely not a spambot.

usedHONDA, You're right. It's not related.

If you close down the installer, and then go to Start->Run and type in "%TEMP%\PdnSetup", what do you get? An empty folder? A bunch of junk?

Please remember to post in the correct section of the forum. Moved to Bugs & Troubleshooting

Just don't include the #.

Got this crash log e-mailed to me. Might want to fix it... This text file was created because Paint.NET crashed. Please e-mail this file to paint.net@hotmail.com so we can diagnose and fix the problem. Application version: Paint.NET v3.01 (Final Release build 3.01.2612.31539) Time of crash: 11/03/2007 22:55:28 Application uptime: 00:00:25.8906250 OS Version: 5.1.2600.131072 Service Pack 2 Workstation x86 .NET Framework version: 2.0.50727.42 x86 Processor: 2x "AMD Turion(tm) 64 X2 " @ ~1607MHz Physical memory: 958 MB Tablet PC: no Locale: pdnr.c: en-US, hklm: en-US, hkcu: n/a, cc: en-GB, cuic: en-US Exception details: PaintDotNet.WorkerThreadException: Worker thread threw an exception ---> System.ArgumentOutOfRangeException: Out of bounds: x=-1 Parameter name: x at PaintDotNet.Surface.GetPointAddress(Int32 x, Int32 y) at ZoomBlurDeluxe.ZoomBlurDeluxeEffect.Render(EffectConfigToken parameters, RenderArgs dstArgs, RenderArgs srcArgs, Rectangle[] rois, Int32 startIndex, Int32 length) at PaintDotNet.Effects.BackgroundEffectRenderer.ThreadFunction() --- End of inner exception stack trace --- at PaintDotNet.Effects.BackgroundEffectRenderer.Join() at PaintDotNet.Effects.BackgroundEffectRenderer.Start() at PaintDotNet.Menus.EffectMenuBase.EffectConfigTokenChangedHandler(Object sender, EventArgs e) at PaintDotNet.Effects.EffectConfigDialog.OnEffectTokenChanged() at PaintDotNet.Effects.EffectConfigDialog.FinishTokenUpdate() at ZoomBlurDeluxe.ZoomBlurDeluxeConfigDialog.m_trackBarAmount_ValueChanged(Object sender, EventArgs e) at System.Windows.Forms.TrackBar.OnValueChanged(EventArgs e) at System.Windows.Forms.TrackBar.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Please don't use really generic thread titles. Edited title from "Plugin request" to "Plugin request: flames"

I have no idea where you get that....

The whole point of the effect is that it's black and white. Pencils only draw in black.

1) Just throw a FormatException. THere is no way for a codec to provide a customized error message. 2) You don't need a Guid anymore, we were planning on using them but I don't think we will be anymore. 3) No, you will just have to scroll.

Exactly.

Yeah I don't know why you said that. I never put a schedule on that thing.

Ok I'm going to the bars in about 5 seconds but managed to get this ready just to whet everyone's appetite. I'm planning on releasing a v3.05 update in the next few weeks*. The goals of this release are to clean up some parts of the UI to make them simpler and/or easier to use. And I'm adding a new effect just to make darn sure everyone sees value in updating 1) In Windows Vista, the new style Open/Save dialogs are now used. This makes things much more consistent with the rest of everything. Interestingly this is actually a lot more work than you'd think! (especially for a C# app like Paint.NET) Old New 2) Pencil Sketch effect 3) Better "the pasted image is too big" dialog Old: New: (yes the thumbnail shows what is being pasted) 4) Some other UI refinements. THe Image->Rotate, Image->Flip, and Layer->Flip submenus are gone. Instead, the commands are now in the Image and Layer menus, respsectively. There are now only 3 rotate commands (90 degrees CW, 90 degres CCW, 180 degrees) because the 270 and second 180 degree options were redundant. Oh, and the View->Units submenu has also been "flattened" into the View menu. 5) Removed the "Clear History" button. Does anyone use this? The answer: no, they don't. Its existence implies that the user (you!) should have to care about the application's memory management, and I don't believe they should. 6) When you choose a new language, the dialog that's shown gives you the ability to restart Paint.NET right away instead of saying "Oh neat, but you have to go restart Paint.NET yourself." It's a much smoother experience. 7) I plan on making the dialog box that says, "To save in this format the image must be flattened. Proceed?" dialog a lot better (using the "task dialog" form shown above for the new Paste confirmation dialog) 8 ) Some small bug fixes 9) A performance improvement for quad core systems. Yeah, I know this affects all of 8 people in the whole world The issue is detailed here, http://blogs.msdn.com/rickbrew/archive/ ... lyzed.aspx Ok that's enough for now. Time to get drunk. * The schedule is mostly dependent on how long it takes to get everything translated. Not that our guys are slow, it just takes time

Please remember to post in the correct section of the forum. Moved to Bugs & Troubleshooting

In her defense though, the article was focused more on photo software. Paint.NET and GIMP are more general purpose, and neither does anything for photo organizing.

Right but what you would not be able to do is write a plugin that simply didn't show up on an AMD system.* * Ok ok I guess that's not entirely true. You could always throw an exception in the constructor for the effect in which case Paint.NET would silently throw it away.

And I think I've articulated several times that what I'm really driving towards are the more general concept and implementation of layer masks Then once you have that it becomes trivial to do about 500 new scenarios.

1) Because Effects can't work in this way*. An effect cannot 'hide' itself based on its own, dynamic criteria. File types can because they are based on a factory pattern. Instead of looking at a DLL and finding all its file types, I look for its file type factories which then can dynamically provide me with a list of concrete file types based on whatever criteria the plugin author cares about. This criteria is usually just a static list of file type instances. However, this enables scenarios like plugin adaptation whereby maybe you have a "Irfanview plugin adapter" that can take any number of non-Paint.NET plugins and dynamically adapt them all to work with Paint.NET. But it's not like the plugin author wrote 50 adapters: they wrote 1 and then the factory creates 50 instances of the adapter where each on points to a different Irfanview plugin. Make sense? 2) But that's really just a long-winded technical reason. Nothing stops me from putting code in the next 0.01 update to enable this. The real reason we haven't done this for any codecs is ... because we've never published a file type plugin * ... yet

sarreq, There's already the ability for a file type plugin to have a UI for configuring saving. What we don't have yet is the ability to provide a UI to configure loading*, or generally for the loader to be able to ask the user questions ("Do you care that I'm down-converting your 64-bpp image to 32-bpp? Yes/No/Die"). This is something that Evan Olds really wanted for some of his plugins ("which frame of this animated cursor do you want to load?"). Since there was no built-in file type that needed this functionality, I wasn't comfortable adding the capability (it's a very bad idea to add something when you can't verify that it works!). * Yes you can show UI by calling straight in to the .NET UI stuff, but Paint.NET won't be expecting it and so things might get weird for the plugin author down the road when we do add support. Right now Paint.NET is assuming and asserting that it is in control of the UI for the entire loading and saving processes.

Actually for something like the HD Photo support, I was thinking I would release a plugin that simply expired if the version of Paint.NET that was hosting it was, say, 3.10 or higher. That way we would have the plugin available for use and kicking around, and the promise that once 3.10 came around either (1) you'd get a new version of the plugin, or (2) it would just be built-in to Paint.NET.

Err ... who knows

Well it isn't really a shippable prototype* -- it doesn't have a UI, and there are parts of Paint.NET that need revision in order to make provide first-class HD Photo codec support. I'm not really a fan of shipping something that's, well, half-assed. I think it does more harm than good for something like this. * By definition you don't ship a prototype -- at least in software, no matter what Webster's says

There's this amazing new technology, they call it a "search engine." 8)

Yes but that definition does not contain anything about the "product" actually shipping. (Hey if you can be pedantic, so can I!)

Example please?