Develop Reference

How to Create a Custom Looking Window [duplicate]

I am looking to create a custom shaped form in c#.
I have a background image (png) that has is transparent in some places.
Is there anyway of making the form shape to be the shape of this image instead of the 'usual' rectangle?
I am only asking this as I wish to design a custom skin for my PC (a bit like rainmeter/rocketdock combined, but in a 'compressed' way).
I have heard of using a 'transparency key', but this would remove a colour from the background (I will be using a colour picker in a later stage, and so if the user chose that specific colour, it would not show).
As always, any help would be much appreciated.

The TransparencyKey approach, discussed here on MSDN is the simplest way to do this. You set your form's BackgroundImage to an image mask. The image mask has the regions to be transparent filled with a certain color—fuchsia is a popular choice, since no one actually uses this horrible color. Then you set your form's TransparencyKey property to this color, and it is essentially masked out, rendering those portions as transparent.
But I guess in a color picker, you want fuchsia to be available as an option, even if no one ever selects it. So you'll have to create custom-shaped forms the other way—by setting a custom region. Basically, you create a Region object (which is basically just a polygon) to describe the desired shape of your form, and then assign that to the form's Region property.
Do note that you are changing the shape of the entire window when you do this, not just the client area, so your design needs to account for that. Also, regions cannot be anti-aliased, so the result tends to be pretty ugly if you're using a shape that does not have straight edges.
And another caveat…I strongly recommend not doing this. It takes quite a bit of work to get it right, and even once you get finished, the result is usually gaudy and user-hostile. Even when everything goes just right, you'll end up with something that looks like this—and no one wants that. Users are quite accustomed to boring old rectangular application windows. Applications shouldn't try to be exact digital replicas of real-world widgets. It seems like that would make them intuitive or easy to use, but it really doesn't. The key to good design is identifying the user's mental model for your application and figuring out a good way of meshing that with the standards set by your target windowing environment.
I noticed this tab still open and had a few spare moments, so I tried to bang out a quick sample. I made the "form" consist of two randomly-sized circles, just to emphasize the custom shape effect and the transparency—don't read anything into the design or get any crazy ideas! Here's what I came up with:
using System;
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Windows.Forms;
public class MyCrazyForm : Form
{
private Size szFormSize = new Size(600, 600);
private Size szCaptionButton = SystemInformation.CaptionButtonSize;
private Rectangle rcMinimizeButton = new Rectangle(new Point(330, 130), szCaptionButton);
private Rectangle rcCloseButton = new Rectangle(new Point(rcMinimizeButton.X + szCaptionButton.Width + 3, rcMinimizeButton.Y), SystemInformation.CaptionButtonSize);
public MyCrazyForm()
{
// Not necessary in this sample: the designer was not used.
//InitializeComponent();
// Force the form's size, and do not let it be changed.
this.Size = szFormSize;
this.MinimumSize = szFormSize;
this.MaximumSize = szFormSize;
// Do not show a standard title bar (since we can't see it anyway)!
this.FormBorderStyle = FormBorderStyle.None;
// Set up the irregular shape of the form.
using (GraphicsPath path = new GraphicsPath())
{
path.AddEllipse(0, 0, 200, 200);
path.AddEllipse(120, 120, 475, 475);
this.Region = new Region(path);
}
}
protected override void OnActivated(EventArgs e)
{
base.OnActivated(e);
// Force a repaint on activation.
this.Invalidate();
}
protected override void OnDeactivate(EventArgs e)
{
base.OnDeactivate(e);
// Force a repaint on deactivation.
this.Invalidate();
}
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
// Draw the custom title bar ornamentation.
if (this.Focused)
{
ControlPaint.DrawCaptionButton(e.Graphics, rcMinimizeButton, CaptionButton.Minimize, ButtonState.Normal);
ControlPaint.DrawCaptionButton(e.Graphics, rcCloseButton, CaptionButton.Close, ButtonState.Normal);
}
else
{
ControlPaint.DrawCaptionButton(e.Graphics, rcMinimizeButton, CaptionButton.Minimize, ButtonState.Inactive);
ControlPaint.DrawCaptionButton(e.Graphics, rcCloseButton, CaptionButton.Close, ButtonState.Inactive);
}
}
private Point GetPointFromLParam(IntPtr lParam)
{
// Handle 64-bit builds, which we detect based on the size of a pointer.
// Otherwise, this is functionally equivalent to the Win32 MAKEPOINTS macro.
uint dw = unchecked(IntPtr.Size == 8 ? (uint)lParam.ToInt64() : (uint)lParam.ToInt32());
return new Point(unchecked((short)dw), unchecked((short)(dw >> 16)));
}
protected override void WndProc(ref Message m)
{
const int WM_SYSCOMMAND = 0x112;
const int WM_NCHITTEST = 0x84;
const int WM_NCLBUTTONDOWN = 0xA1;
const int HTCLIENT = 1;
const int HTCAPTION = 2;
const int HTMINBUTTON = 8;
const int HTCLOSE = 20;
// Provide additional handling for some important messages.
switch (m.Msg)
{
case WM_NCHITTEST:
{
base.WndProc(ref m);
Point ptClient = PointToClient(GetPointFromLParam(m.LParam));
if (rcMinimizeButton.Contains(ptClient))
{
m.Result = new IntPtr(HTMINBUTTON);
}
else if (rcCloseButton.Contains(ptClient))
{
m.Result = new IntPtr(HTCLOSE);
}
else if (m.Result.ToInt32() == HTCLIENT)
{
// Make the rest of the form's entire client area draggable
// by having it report itself as part of the caption region.
m.Result = new IntPtr(HTCAPTION);
}
return;
}
case WM_NCLBUTTONDOWN:
{
base.WndProc(ref m);
if (m.WParam.ToInt32() == HTMINBUTTON)
{
this.WindowState = FormWindowState.Minimized;
m.Result = IntPtr.Zero;
}
else if (m.WParam.ToInt32() == HTCLOSE)
{
this.Close();
m.Result = IntPtr.Zero;
}
return;
}
case WM_SYSCOMMAND:
{
// Setting the form's MaximizeBox property to false does *not* disable maximization
// behavior when the caption area is double-clicked.
// Since this window is fixed-size and does not support a "maximized" mode, and the
// entire client area is treated as part of the caption to enable dragging, we also
// need to ensure that double-click-to-maximize is disabled.
// NOTE: See documentation for WM_SYSCOMMAND for explanation of the magic value 0xFFF0!
const int SC_MAXIMIZE = 0xF030;
if ((m.WParam.ToInt32() & 0xFFF0) == SC_MAXIMIZE)
{
m.Result = IntPtr.Zero;
}
else
{
base.WndProc(ref m);
}
return;
}
}
base.WndProc(ref m);
}
}
Here it is running on Windows XP and 7, side-by-side:
Whew! It does work, but it's a long way from complete. There are lots of little things that still need to be done. For example:
The caption buttons do not "depress" when clicked. There is a built-in state for that that can be used with the DrawCaptionButton method, but you need to either force a redraw when one of the buttons is clicked, or do the repaint directly on the form right then and there.
It doesn't support Visual Styles. This is a limitation of the ControlPaint class; it was written before Visual Styles were invented. Implementing support for this will be a lot more work, but there is a WinForms wrapper. You will have to make sure that you write fallback code to handle the case where Visual Styles are disabled, too.
The caption buttons aren't actually centered—I just eyeballed it. And even if your eyeballs are better than mine, this is still a bad approach, because the caption buttons can be different sizes, depending on system settings and which version of the OS you're running (Vista changed the button shapes).
Other windows invoke the actions when the mouse goes up over the caption bar buttons. But when you try to use WM_NCLBUTTONUP (instead of WM_NCLBUTTONDOWN), you have to double-click the caption buttons to make them work. This is because the non-client area is capturing the mouse. I'm sure there's a solution, but I ran out of patience before I discovered what it was.
You don't get the pretty animation effects when the window is minimized (or restored), nor do you have the glow-on-hover for the caption buttons. There are tons of visual niceties that you get for free with the default styles that are missing-in-action here. Some of them can be easily added by writing more code, but for each line you write, the maintenance burden skyrockets—newer versions of Windows are likely to break things. And worse, some things are far from trivial to implement, so it probably isn't even worth it. And all this effort for what, again?
Repainting the entire form on activation/deactivation just to update the caption buttons is probably a bad idea. If you are painting anything else more complicated on the form, this is likely to slow down the entire system.
Once you start adding controls to the form, you might run into a problem. For example, even with a Label control, you won't be able to drag the form around by clicking and holding on top of that Label control. Label controls don't return HTTRANSPARENT in response to the WM_NCHITTEST message, so the message doesn't get passed on to the parent form. You can subclass Label to do so and use your subclass instead.
The code is completely untested with Windows 8, since I don't have a copy. Custom non-client areas tend to blow up with new OS updates that change the way the non-client area is rendered, so you're on your own to adapt the code accordingly. Even if it works, it certainly won't have the right Windows 8 look-and-feel.
Et cetera, et cetera.
You can also see that, like I cautioned above, the circular border is not anti-aliased, so it looks jagged. Unfortunately, that is unfixable.

Move form on right click while resizing

I'm trying to move the form instead of resizing it while I'm resizing if the right button is down.
Resize event:
if (rightMouseDown)
{
this.SetDesktopLocation(MousePosition.X - this.Width, MousePosition.Y - this.Height);
this.MaximumSize = new System.Drawing.Size(this.Width, this.Height);
this.MinimumSize = new System.Drawing.Size(this.Width, this.Height);
}
Global mouse event:
bool rightMouseDown;
private void HoldMouse(object sender, MouseEventArgs e)
{
if (e.Button == MouseButtons.Right && e.Clicks != 1)
{
rightMouseDown = true;
}
else if (e.Button == MouseButtons.Right)
{
rightMouseDown = false;
this.MaximumSize = new System.Drawing.Size(0, 0);
this.MinimumSize = new System.Drawing.Size(100, 100);
}
}
At the moment when I click the right button it freezes because the MaximumSize is constant, therefore I can't resize the form.
e.cancel would be awesome if it would work but I can't use that.
I'm able to capture the mouse events with a global one, the form events doesn't work weirdly.
I Got it working but only when the window's width is minimum and it goes to it's original width after the right mouse button goes up.
This is due to setting it to the default size. How can I keep the window in the changed size without setting it to MaximumSize 0,0?

First of all, I would suggest that you do not move the form while the right button is down, because this is highly non-standard and therefore likely to be perceived as highly peculiar by anyone trying to use your app. To be more specific, nobody is ever going to try either moving or resizing your form with the right mouse button, so:
if that's the only way you offer for moving your form, then nobody will ever be able to move your form.
if you also offer other ways of moving your form, then why bother with offering this way too?
Secondly, I would like to propose that this is most probably an X-Y problem meaning that you probably have some other issue, which you have told us nothing about, you think that you might address it by moving-by-right-click, then you discover that moving-by-right-click does not work for you, and you come here asking how to get moving-by-right-click to work. Why don't you begin by describing the real issue?
Thirdly, if you really want to proceed with moving your form by right-click, that's not how to do it.
First, you need to detect when the right mouse button is pressed. There are events for this. They work. If they don't work for you, that's not a reason to be doing other weird things instead. The statement "I'm not able to capture the mouse click with the Mouse events" is utterly bizarre, because a) it is a wrong use of the term "capture"; mouse capture is a very specific thing, (more about it later,) so please refrain from using it in other contexts, and b) if you cannot accomplish something, then that should be the subject of a stackoverflow question on its own. You cannot be trying utterly bizarre things because your attempts to do the right things failed.
So, once you have gotten detection of the right mouse click to work, then you need to set up mouse capture. (Look it up, search for "SetCapture".) That's what guarantees that you can keep receiving mouse move events, and finally a mouse-up event, even though the mouse has moved outside of your form while you were dragging it.

Handle Double Click Anywhere in the Form?

In my WinForm application I have drawn a rectangle (System.Drawing.Rectangle) on a form.
I need to handle double click anywhere on the form
I could attach MouseDoubleClick event handler to the form. It works only when double click was made outside the rectangular shape.
How do I achieve this?
EDIT:
I have drawn a rectangle which is center aligned and covers only 40% of the whole winform area. When user double clicks on the rectangle I need to expand rectangle size to occupy full screen. That's all!
EDIT 2:
My friends who have down voted, write a comment please so that I could improve, please!

The best way I know to do what you are looking for is to use the "WndProc" method. This allows you to collect "messages" (events) from the message queue before they are sent to the form. You then have the option of either responding to those events or allowing them to continue through the normal message process. For more information, take a look at the MSDN page here.
A brief example of how you might use this:
protected override void WndProc(ref Message m)
{
// http://msdn.microsoft.com/en-us/library/windows/desktop/hh454920(v=vs.85).aspx
// 0x210 is WM_PARENTNOTIFY
// 513 is WM_LBUTTONCLICK
if (m.Msg == 0x210 && m.WParam.ToInt32() == 513)
{
var x = (int)(m.LParam.ToInt32() & 0xFFFF);
var y = (int)(m.LParam.ToInt32() >> 16);
var childControl = this.GetChildAtPoint(new Point(x, y));
if (childControl == cancelButton)
{
// ...
}
}
base.WndProc(ref m);
}
Credit for this example goes to: this stack question.
Remember too, that "double click" is just two single clicks, so you are going to have to monitor and find the time between clicks yourself to decide what actually represents a double click.

Unfortunately Rectangle does not contain any fire any events (at all) as System.Drawing merely provides "grahpics" for a form.
There are options (such as provided by #drew_w) however such workarounds that require interaction with COM objects is usually indicate it's time to re-evaluate the requirements.

Force NOT to paint during duration of a function

I wrote a program that draws a specific situation of a board game(I think it's called "Ludo" in English). Now I can draw all the fields and the pawns etc., but if a pawn is moved I have to redraw that pawn. The problem is that the screen flashes for a very short time when I do this. This is probably because I first clear all fields and pawns, and then redraw them(I'm going to improve this, but the problem will, in smaller form, still occur I think), the screen is then flashing between the time I cleared everything until I redrawed everything. Is there a way to tell C# not to redraw even when I specifically call something like this.Controls.Clear() until I tell it to?
I already tried it with this.SuspendLayout(), because the name suggests it should do exactly this, but that doesn't work.

Flickering is always going to be somewhat of a problem in Winforms custom graphics.
Try this: Instead of drawing the pawn's positions on the Form somewhere, draw them onto a Bitmap. When it's all done, simply change the Image of a PictureBox on your form to be the Bitmap. The form will be redrawn using the new Image. You can use two Bitmap objects (which are admittedly quite large) and clean them each time to avoid the program being a memory hog. Voila, you now have "page-flipping" graphics, which can be drawn and displayed independently of other requests to redraw the form.

When you tell it to clear everything and then redraw it, it will flash like that. But how come when you move a pawn you don't draw it in the new space and draw a blank over top of where it used to be. This will move the pawn without refreshing the whole screen or clearing everything.
Also I think the game you are talking about is Chess. Thats the only game I know with Pawns, and I've never heard of Ludo. :P

Best solution is the one of KeithS, but a faster option could be: have two images for each part, one on the white and one on the black, plus both empty square. In the move place the proper empty square in the leaving square, and the proper part on gthe destination square. This is a zero flicker, old ages ( so fast ) approach :)

Although #KeightS's solution is nice, I'd much rather solve it by being able to suspend/resume drawing all together:
public partial class Form1 : Form
{
private bool suspendDraw;
public Form1()
{
this.InitializeComponent();
}
public void SuspendDraw()
{
this.suspendDraw = true;
}
public void ResumeDraw()
{
this.suspendDraw = false;
}
private const int WM_PAINT = 0x000F;
protected override void WndProc(ref Message m)
{
if ((m.Msg != WM_PAINT) || (!this.suspendDraw && m.Msg == WM_PAINT))
{
base.WndProc(ref m);
}
}
}
You just need to call the SuspendDraw/ResumeDraw() methods to control allowing painting.

Why isn't my app getting mouse wheel tilt messages?

In this question How to detect mouse wheel tilt an answer is posted and accepted that shows the code needed.
I've implemented that code in my application's existing WndProc method (which is working for other messages I need to trap) but it's not working. I've checked and WndProc doesn't appear to be getting any messages at all let alone ones with a value of 0x020E when I tilt the mouse wheel.
I'm using a Microsoft Wireless Laser 5000 on Windows XP SP3 (fully patched) with .NET 3.5 SP1 installed.
I've updated my Intellipoint drivers to version 7.0.258.0 dated 08/05/2009.
Other applications (e.g. Visual Studio, Word, paint.NET) are getting and acting upon the mouse wheel being tilted so it must be my application, but I can't see what I'm doing wrong.
Just for completeness here's my code:
protected override void WndProc(ref Message m)
{
Trace.WriteLine(string.Format("0x{0:X4}", m.Msg));
switch(m.Msg)
{
case WM_EXITSIZEMOVE:
Opacity = 1.0;
break;
case WM_SYSCOMMAND:
int command = m.WParam.ToInt32() & 0xfff0;
if (command == SC_MINIMIZE && this.minimizeToTray)
{
MinimizeToTray();
}
break;
case WM_MOUSEHWHEEL:
// Handle tilting here
break;
}
base.WndProc(ref m);
}
The Trace.WriteLine call is an attempt to check if the tilt messages are getting through. The other messages WM_EXITSIZEMOVE and WM_SYSCOMMAND are being received. The messages are defined as:
private const int WM_EXITSIZEMOVE = 0x0232;
private const int WM_SYSCOMMAND = 0x0112;
private const int SC_MINIMIZE = 0xF020;
private const int WM_MOUSEHWHEEL = 0x020E;
NOTE I removed the [hardware] tag, as I'm 99% sure it's not the hardware that's at fault as other applications are receiving the messages.
UPDATE
I've added a multi-line textbox with scrollbars to my application and that receives and acts upon the mouse wheel tilt messages. So all I need to do is find the code for that ;)
UPDATE
This question on SuperUser may have some bearing on this - I'll keep an eye on answers there.

Use Spy++ to check what messages you are receiving.
EDIT: You can also call m.ToString() in you WndProc method to get the name (!) of the message you've received. (This is done by a giant switch statement in Syetm.Windows.Forms.MessageDecoder.MsgToString)
Note that the messages might be sent only to whatever control has focus and not to the form itself; if that is the case, you might want to use a message filter.
Also, note that different mice send different mousewheel messages. I have a Logitech mouse that sends 0x20E with a WParam that is negative for left scroll and positive for right scroll.
EDIT (in reponse to comments)
Remember that horizontal scrolling was added long after vertical scrolling and is not supported by older programs. Therefore, the mouse driver could well be looking for horizontal scrollbars and scrolling them explicitly. Try adding a horizontal scrollbar to your form, positioned negatively so the user won't see it, and see if that changes anything.