i agree, usually the user should have complete control over the placement, size, and position of a window. Don't impede on the users control over software or they'll find it constraining most of the time.
BUT
If you want it, yeah you can do it. There are properties of a window that you can set to move a window around screen, size it to the screen, maximize, minimize, etc. Just check out the System.Windows.Forms.Form class:
Form Class (System.Windows.Forms)
Be sure to check the "Form Members" link towards the bottom, that lists all the methods, properties, events, etc of the classes interface.
(I'm assuming you are doing a Windows Forms project, if you're using WPF then this link is useless and there is a completely different interface to your forms you need to learn).
Now all you'd have to do is update the position/size/other settings on whatever events you decide.
The "easiest" would probably just be to update on some interval using a timer (make sure it's a System.Windows.Forms.Timer, it remains thread safe with windows forms). Every once in a while you basically just set the window back to whatever "state" you want it in. (At the same time this is kind of costly as you're habitually updating the position/size/etc even when they don't change... but it's probably not that much overhead, hence my comment of "easiest").
Or you could get more technical reacting to user input events and the sort. But you could easily not react to some event and leave some loop hole open that can put the window into a faulty state that the user couldn't get out of.
For the latter just make sure you react only to the necessary events, and don't leave any out.
For instance if all you wanted to do was make sure the user didn't "Move off screen", then you just listen to the "Form.Move" event, and every time the user has moved the window, you move it back into view if it slid out. No more or less is necessary.
But if it's more complex then that and you start getting into events that are inter-dependent (especially focusing loops and the sort)... well then you got to get really tricky and the sort. And personally I'd advise against it... if your code is battling with events, then you probably are using the wrong events.
One last thing I want to bring up that may annoy some users!
I work on a multi-monitor display (3 monitors of varying sizes). And I've used several pieces of software (some designed by MS themselves) that restrict the placement of the window or the mouse with respect to the window and as a result can get me stuck on one of my three monitors until I close that software! Sometimes worse I can get stuck with my mouse on one screen and the software on another, requiring the user to resort to the task manager or keyboard shortcuts. Neither of which is good... most users don't know to use keyboard shortcuts. How many windows users do you know (that aren't techy) that know what "Alt+Tab" does or "Ctrl+F5"?
Give you an example, Windows Media Center by Microsoft themselves. One of my monitors is a 50 inch 1080p HDTV, I use it for watching movies and playing videogames (it's got its own dedicated video card). Most of my software will let me play over on my other two monitors while things are fullscreened on the 50 inch. For instance VLC lets me remain on the other screens when it's fullscreened, so my girlfriend can watch movies on the 50inch while I'm coding on the 30inch, and I have MSDN open in firefox on the 20 inch for reference. BUT Windows Media Center doesn't. My mouse gets locked on that screen, AND that window randomly gets locked on that screen when I take it out of fullscreen back into window mode (not sure why either).