Super Columbine Massacre RPG

Columbine was a tragedy. No arguments here; death is bad mmmmk.

Danny Ledonne made a SNES-style RPG of the Columbine massacre. It's somewhat controversial.

Wired takes a good look at the content of the game. Turns out to be deeper than most people give it credit for.

I was a kid like them (Harris and Klebold) when I was in high school. I was picked on by jocks and preps. I played lots of video games. I wore all black. But...I didn't kill anyone.

Video games don't kill people. Psychos without regard for right and wrong kill people.

For those of you with pre-installed OEM (e.g. Dell) crap

I found this neat app through a post on slashdot. It was originally the Dell De-Crapifier, but has since been expanded to work on just about any OEM machine as the PC De-Crapifier.

I think I'll run this on my mom's laptop.

EDIT: PC De-crapifier is now here.

Preserving Windows Forms' Size and Position

I've noticed while developing a Windows Forms application with .NET 2.0 and Visual Studio 2005 that there's a lot of effort involved in making a Windows program act and feel like a Windows program. One small caveat that I've found is storing the current size and position of a Form so that you can load it during the next run of your application.

For instance, did you notice that your web browser remembers if it was maximized when you closed it, and it opens up maximized?

So, at first you think, this is cake. All I need to do is write the Location and Size Properties of a Form to a file, and load those values the next time your app starts. You even realize that the Closing and Load event handlers are the perfect place to store and load the important values.

There are still plenty of things that can screw you up, though. Check out the following msdn blogs for more info.

Cool Client Stuff - Saving out a Form's Size and Location using the Application Settings feature

The Old New Thing - A subtlety in restoring previous window position

In a nutshell, rprabhu indicates that data binding will not solve this problem. It is then suggested to use the Application Settings class to store the data to disk. Another neat trick I saw there was the use of the Form.RestoreBounds Property to access the size and location if the WindowState is not FormWindowState.Normal; Location and Size are dirtied whenever the WindowState is Maximized or Minimized.

The comments added some interesting points.

1) You should only restore the WindowState if it is Maximized, otherwise you should assume Normal.

2) You should set the Form's StartPosition to Manual, otherwise setting Location will either not matter (StartPosition will be evaluated after you loaded your settings, and the Location will be lost) or it will allow the user to see the form move from the FormStartPosition to whatever last Location it had. That last one, while not terrible, looks awful.

A link in the comments points to an article at The Old New Thing, with more interesting info.

3) If your app allows multiple instances, you don't want them loading directly overtop of each other. You should probably offset the location by some amount on both the x and y, so that it appears to be "cascaded" on top of the old one.

4) Your screen setup could change. This could be a result of using multiple monitors, or the user changed resolutions between runs, etc. Your form may open off-screen as a result. Your app ought to make sure that either some or all of it will actually be shown on the screen.


If doing multi-monitor work, things get awkward very quickly. So check out System.Windows.Forms.Screen for what little information is available.