We Keep Coding

Any ideas on making this window?

Hop on a Windows 7 machine and open Notepad for example. Drag the window all the way to the left. You'll notice Windows throws up a glass window on the left half of the screen to indicate docking. However, you'll notice this is not your normal Aero glass window. The glass is a lot clearer and has 45 degree "stripes" running across it. I need to duplicate this window's look EXACTLY (or to an indistinguishable level).
I get its a popup window
I get it takes the height of the screen
I get it takes half the width of the screen
The portion I need to duplicate is the look of the clearer glass and the 45 degree "stripes". The normal glass look is not close enough.
Seems like they are taking a normal aero window, making it semi transparent (not glass) and putting a semi transparent overlay on top of it.
I used reshacker to look at the aero.msstyles dll and found the png that I think they are using for the overlay (image #900), but I can't seem to get it to stretch the same way or look remotely similar.
Any thoughts?

NotifyIcon and High DPI Displays

Following this guide: http://www.hhhh.org/cloister/csharp/icons/ I was able to get my NotifyIcon to look the way it should because Windows decides to use the 32x32 icon and scale it to a 16x16 instead of just using the 16x16 icon.
That being said, I have an .ico file with the following resolutions:
256x256x32
64x64x32
48x48x32
32x32x32
16x16x32
48x48x8
32x32x8
16x16x8
32x32x4
16x16x4
However, when I increase the DPI settings on my display, the icon displayed in the NotifyIcon is a higher resolution version, with more embellishments that end up looking terrible scaled to the size of the NotifyIcon. What size icon is it taking and scaling now? Would I be better off just creating a simple icon of every size specifically for the NotifyIcon?

The icons displayed in the notification area are small icons. That is their size is given by the SM_CXSMICON system metric. Find out that size and supply an icon of the exact dimensions to avoid aliasing. If you have not got one the exact size to hand, probably the best you can do is to draw the closest smaller sized icon onto the middle of an empty transparent canvas, and use that.
You may not be able to do this using the managed NotifyIcon wrapper. I expect that you don't get enough control. The procedure I describe really requires you to be able to call Shell_NotifyIcon, the native API, and pass an HICON.

This page http://msdn.microsoft.com/en-us/library/bb773352(VS.85).aspx gives an example of how to pass the correct icon for the correct DPI. It uses LoadIconMetric, which probably isn't directly available in c#, but it would be simple to marshal one.

Check my answer here: notifyicon image looks terrible once image ends up in system tray
Basically, you need to explicitly declare which size to use at runtime, and to declare your app as DPI-Aware.

After maximizing the form, half of the windows is lost and are out of windows for some screens

So here is my form onstartUp event code:
int height = Screen.PrimaryScreen.Bounds.Height;
int width = Screen.PrimaryScreen.Bounds.Width;
this.StartPosition = FormStartPosition.Manual;
this.Size = new Size(width, height);
this.WindowState = FormWindowState.Maximized;
the code works fine and the form starts up maximized. After distributing the applications to the user. A user complained and sent a screen shot with the form buttons on the RHS not appearing on the screen!!!
I figured what the problem is, but i don't know how to fix it. The problem is with windows fonts, Control Panel\Appearance and Personalization\Display\ font size on the development machine is small, on the customers it's medium.
how to accommodate for this in code?

The problem is with windows fonts
Not exactly. It is not the font size you are changing, it is the video adapter's dots-per-inch (DPI) setting. The legacy setting is 96 dpi, since Vista it got a lot easier to change this setting. Common other choices are 120 dpi (125%) and 144 dpi (150%), they are directly accessible from the Display applet with a radio button.
Monitor resolutions have been stuck for a very long time, ducking Moore's Law for a good 30 years already. That's finally changing, in no small part due to Apple's push for "retina" displays. The latest MacBook Pro has 2560 x 1600 pixels on a 13 inch screen, about 230 dpi.
That does come with a problem, any program that creates a, say, 1024x768 window has its UI turned into a postage stamp on such a display. The UI just becomes unusable without a magnifying glass. What is needed is for such a program to become aware of the video DPI setting and create a larger window, proportionally larger by the increase of the DPI setting compared to the way the window was originally designed.
This is automatic both in WPF and in Winforms. WPF gets it by default since all of its locations and sizes are expressed in inches, with a unit of 1/96". Winforms still works with pixels, but it has automatic scaling built-in through its AutoScaleMode property.
Which is what is happening on that user's machine, he's got the video DPI setting at a larger value than your machine. However, without also having a larger number of pixels available on his screen. Somewhat typically picked by someone that has a vision impairment, a side-effect of increasing the DPI setting is that fonts get larger and thus easier to read. But with the inevitable problem that any controls that you put near the right and bottom edge of your window are going to fall off, the screen just isn't big enough.
You address this kind of problem by making your window layout adjustable. Or in other words, by making your UI design work with any window size. A very common feature of Windows programs. Just try it on Visual Studio. Drag the bottom right window corner around and observe how it deals with having less space available but still staying usable. Lots of Winforms features to help you doing this, like the Control.Anchor and Dock properties, FlowLayoutPanel and TableLayoutPanel controls, the Resize event for tough cases.
The Q&D fix for this is the Form.AutoScroll property. Set it to True to permit the UI to still be usable, the scrollbars allows the user to still get to controls that are off the window.

The code you posted has nothing to do with the problem. You designed the form in a higher screen resolution than the screen resolution of the user and didn't consider docking/anchoring the controls inside the form.

c# how to perform a screen clipping similar to OneNote Windows + S shortcut key

I'd like to implement a similar screen clipping functionality to that of OneNote. Basically it can draw a translucent overlay on top of the whole screen, and also freeze the screen so users can clip a portion of it.
I've done some research around and it seems that the easiest way is to create a translucent TopMost form with the size of the whole screen and then perform clipping on this form. This approach, however, is slow. I see some other suggestions about doing a Direct3D hook for drawing overlay, but this is probably too complicated and I'm not sure how stable it is with respect to different Direct3D version. Any ideas how OneNote does it?

I think instead of creating the transparent layer on top of the screen, just grab a screenshot of the whole screen and make it full screen. So users are drawing on a static image not a translucent layer. Since it is a screenshot already, it is already frozen. I think this is how they do it anyway, I doubt an application can simply freeze a screen, they take a photo of it and cover your screen with it, so its as if its frozen.

Windows form rotation

When you create a form in .Net it appears as a dialog box in a portrait layout.
No one normally likes to read sideways, or upside down, but I have a very valid reason to rotate the form.
Anyone knows how to do it on Windows Vista with C#?

Does it have to be in WinForms? This is very easy to do in WPF, using rotation transforms. Unfortunately, the WindowsFormsHost integration with WPF does not allow rotation transforms.
EDIT
I understand, now, that the form in question is out of the control of the poster. Writing the control in WPF won't fix the problem.

This would be a bit of extra work, but if you mainly just need the contents of the form to be rotated (and not the entire window including title bar, window controls etc., which I've never seen before), you could instead make an entirely owner-drawn usercontrol that was rotated 90 degrees, and drop it on an ordinary form. You wouldn't even have to adjust your drawing of everything, since you could do a RotateTransform on your Graphics object and then draw everything normally.
Or if you need the entire form rotated, you could make the form borderless and then do basically the same thing, drawing the title bar and windows controls yourself also.
Update: here's a link to an MSDN article that shows how to rotate the entire screen in C#:
http://msdn.microsoft.com/en-us/library/ms812499.aspx
This is for regular Windows (not Windows Mobile), so it should work for your porpoises, although it will rotate all of Windows and not just your application's form. Depending on how fast this works and your overall needs, you could rotate the screen 90 degrees when your application gets the focus, and then rotate it back to normal when your app loses focus.
Update 2: I just reread your question and comments. You're talking about rotating the window of a separate application in a separate process, so WPF will definitely not help you here. The MSDN link might be what you need. In your application, you would rotate the screen 90 degrees, then start the other application in a separate process. This would work best if you could force the separate application's window to be maximized, which you can do by P/Invoking the FindWindow and SendMessage APIs (you could also make the window always on top, which would put your computer into a sort of kiosk mode for this application). There's a version of the Process code that basically makes starting another application a blocking call, which means your app will wait for the shelled application to close before resuming. Once the app closes, you can put the screen back to its normal orientation.