Rick Brewster

Well, in this case there is a real conflict between simplicity and preference. I dont want the tool choice to simply be sticky between sessions. That would end up having PDN open w/ the Clone Stamp (for instance) if you closed it with the Clone Stamp tool active. So that would not solve "I want selection to be the default tool." The toolbar items have reasonable defaults, but if you don't provide a way to preserve their changed settings then for many users it becomes annoying to start up Paint.NET and have to go and change 4-5 things to the values that are always used. This also solves accidentally changing settings to undesirable values and essentially being locked out of functionality. I really am serious that I get e-mails all the time about the magic wand and paint bucket being "broken" because the user went to go click on a shape tool or the color swatch but accidentally nicked the Tolerance bar. Same thing for the antialiasing/alpha blending toggle buttons. (I've even seen this happen in person!) This way, a user cannot 'break' the paint bucket forever. If they nick the tolerance to 0% on accident, it'll be back to 50% the next time they start Paint.NET. The only way to set this to always be 0% is to go into a dialog, set it to 0% and then press Save -- it's much harder to accidentally do that. It's not really a "options dialog" per se, although this could just be me arguing semantics to uphold previous canon. It's not like I've got tabs and spinny buttons for configuring scratch disks and thumbnail update latency and stuff. Nobody really cares about that stuff, although for those who do they can just get the source code. Other parts of the UI will continue to adhere to the "toaster philosophy" of remembering settings in an intuitive fashion. You know, kinda like how a toaster just remembers the positions of its knobs for controlling toast lightness/darkness ("toastiness) but doesn't provide microwave-esque functionality for configuring 85 other things -- it's very simple, but also completely and blatantly obvious what's going on and how to use it even for someone who's never used a toaster before. When's the last time you met someone who couldn't use a toaster ... and, now, when's the last time you were confused by a microwave that you weren't used to?

Nah the only real problem here should be if the settings get corrupt or invalid somehow. And I detect that when loading and just revert to all defaults.

If you don't want to install SP2, then you may not install Paint.NET v2.72. Simple as that.

... why would they go into pdncrash.log ?

What about something like ... (and yes it's rough draft, it says "PdnBaseForm" at the top, just bear with me) This solves a few things: * People always ask me to change the default tool to the selection tool. This lets them set it to whatever they want. * Even more often, people ask me why the paint bucket or magic wand won't work. The reason is they accidentally set the tolerance to 0 or 100%. In 2.xx the tolerance setting is 'sticky'. With this dialog the setting is not automatically sticky and you must set the default manually. * Same for alpha blending and antialiasing settings: in 2.xx they are sticky but people constantly disable them by accident and I get e-mails and questions about why the drawing quality is so horrid.

Weird, this was happening to me on 2458 but not on 2460 ... I couldn't figure out why. Tell me if 2460 gives you trouble on the next update.

I'm hoping to address this in a similar way to how I've done the color palettes feature (or maybe it won't be similar). I've got that Tool drop down in the toolbar that I plan on using for something interesting. In the interim, as a workaround, just press S to jump to the rectangle selection tool.

What? Ragged me off? No I just explained that you hadn't.

Please remember that the Tutorials section of the forum is for tutorial publishing only (as is clearly stated at the top of the forum). Moved to General Discussion

Oh wow, you are right. And yes, there are such things as memory leaks in managed code. They are extra nefarious to find. And they are especially easy to make when you are allocating non-managed heap memory, like we do a lot.

First off, let's jump back and set the expection of attitude straight: Your comments, feedback, suggestions, and bugs help the project. Even if you dislike or disagree with stuff. Your feedback is critical to ensuring that Paint.NET v3.0 is a high quality release that will continue to leave a favorable impression. So please don't start off on the defense by saying things like "sorry rick but ..." or "I know I have probably been pretty annoying lately." Just say what you need to say, although of course be objective, polite, and intelligent. In return I'll be objective and intelligent, hopefully polite (if I just woke up then you're out of luck, sorry! :twisted:) Also, please do remember to tell me what you like about v3.0's changes and features And why. Now, to respond: Oops! I've filed a bug. This is one of those relatively minor fit & finish details that are hard to catch the first time through. This is not "by design" Worth investigating so I've filed a bug. I'm not sure if it's possible to limit the height of the menu so that it can only go as far as the bottom of the monitor, but I'll look into it. This is another fit & finish issue. Not sure I agree, but I can at least look into making it more obvious that it is not part of the image. I disagree -- a scrollbar would take up too much space, be rather ugly, and I don't believe it would really give you much more navigational cues. Ok that last part isn't necessarily correct: however, I don't believe a scrollbar is the best solution to providing those navigational cues. I still have some aces up my sleeve. This just isn't there yet Not sure yet what any right-click menus will contain, but the interface is getting to the point where I also believe this would be of utility.

Ahh yes, the blissful naievety of someone who is not a developer on the project (I don't mean that as an insult) First, yes disk space would be a concern especially for large images and wanting to send them over the Internet. "What, this file is 1024x768 and 500mb?!" Ack. Second, it's much much more complicated than you'd think to save the history with the image. The History was always meant to be part of the application's state, not the image. As such it was never designed to be saved to disk and then loaded back and reconstructed. The data structures are currently set up to be able to persist portions to disk (to save memory, esp. on 32-bit systems), but not all. But, let's pretend for a moment that the history was designed to work in this way. Now we have all this revision data that is saved by Paint.NET v2.xx that must be successfully loaded in to memory by Paint.NET v3.0. And then those files must be loadable by 3.x and beyond, etc. Backwards file format compatibility is paramount for an application like Paint.NET. That means my hands are possibly tied if I want to change, improve, or fix bugs in certain areas of the history's data structures. If I make a change that could even remotely cause a problem, I need to have a stack of .PDN sample files to test with to make sure that when I load them not only does the history load correctly, but that it works to undo and redo in all sorts of intense combinations. For example, what if I wanted to add the ability to do shearing or arbitrary, complex transformation with the Move Selected Pixels tool? That would change how its history data is stored and organized. Adding this feature would be complicated by having to ensure that old .PDN files could still be loaded and safely migrated to the new format. One alternative to this tying-my-hands is to provide history saving "with no warranty." If the file format changes in a breaking way between versions, then too bad: it gets thrown away but you still have the image. At which point the history is essentially worthless. Also, the stuff takes up lots of disk space. So I'd need to provide a tool for stripping the history away to cut down file size. This is another tool or feature that must be designed, implemented, tested, and maintained over the entire lifetime of the Paint.NET project. It's just not worth it, honestly. It's just too much. I've done the investigation to see what this would cost and it is not even remotely simple or cheap, unfortunately.

Woops, two simple bugs there. The first is not Vista related: I was calling Enum.IsDefined(Type, object) and providing a byte value (OSVERIONINFOEX.wProductType) instead of first casting to an int or OSType value (OSType is an enumeration whos underlying type is int, aka System.Int32). ThreadBackgroundMode shouldn't crash like that. I'll look into that as well. As a side note, I find it interesting that OSVERSIONINFOEX.wProductType is a byte and not a word -- I double checked the docs and that is indeed what it is. Weird.

OS Version: 5.1.2600.131072 Service Pack 2 --- Exception while populating osType: System.ArgumentException: Enum underlying type and the object must be same type or object must be a String. Type passed in was 'System.Byte'; the enum underlying type was 'System.Int32'. at System.Enum.IsDefined(Type enumType, Object value) at PaintDotNet.SystemLayer.OS.get_Type() at PaintDotNet.Startup.UnhandledException(Exception ex) x86 The fact that some of my data in managed (C#) land got corrupted gives me clues as to the parts of code that could have caused this. The reason is that verifiable managed code could not possibly do this. So it must either be native (C/C++ -- in other words Windows or other components that are loaded as a consequence) code, or some of the unsafe/unverifiable C# code (the code that uses pointers). What were you doing before this crash? Effects? Tools?

I get crash reports like this every once inawhile through paint.net@hotmail.com ... and I can never tell what's at fault. Is it my code? Is it Windows' code? Is the system just overheating or overclocked or has bad memory and freaking out? So if you ever find a solid, consistent set of repro steps ... I'd love to have them.

I'll need some better repro steps than just "I was messing around" ...

If you don't like the dialog translucency, turn it off. Window -> Translucent

Well let's try it with transperancy then.

Do you think this functionality would be beneficial? You can always move the window out of the way. I'm actually moving away from having transparent dialogs for anything except the docking windows and effect configuration dialogs.

Edit -> Paste in to New Image Have to have a submenu for the scanning option because it's expensive, performance-wise, to determine whether to have the menu option enabled or disabled.

To test the updater

Right, I just haven't handled the overflow case yet.

Excellent, glad to hear.

Your welcome

Thanks, I filed a bug.