Develop Reference

Detect when help button is pressed in title bar of Windows Form?

My c# console application displays a Windows Form for user to login, I've added a Help button to the top of the login Form just in case any users have any questions
What I'm trying to accomplish is have a MessageBox() popup when user presses the Help button. I've done some research and still haven't been able to find any working solutions. Any help would greatly be appreciated!Thank you for your time.

According to MSDN the way to handle this is to process the windows WM_HELP message:
DS_CONTEXTHELP
Includes a question mark in the title bar of the dialog box. When the user clicks the question mark, the cursor changes
to a question mark with a pointer. If the user then clicks a control
in the dialog box, the control receives a WM_HELP message. The control
should pass the message to the dialog box procedure, which should call
the function using the HELP_WM_HELP command. The help application
displays a pop-up window that typically contains help for the control.
Note that DS_CONTEXTHELP is only a placeholder. When the dialog box is
created, the system checks for DS_CONTEXTHELP and, if it is there,
adds WS_EX_CONTEXTHELP to the extended style of the dialog box.
WS_EX_CONTEXTHELP cannot be used with the WS_MAXIMIZEBOX or
WS_MINIMIZEBOX styles.
In brief, you need to implement a WndProc method for the controls in your form (which unfortunately will need to be individually derived from their base classes):
const int WM_HELP = 0x53;
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
case WM_HELP:
// Your handler here
break;
default:
base.WndProc(ref m);
break;
}
}

In a Winforms RichTextBox control, how can I make the space BELOW a last-line link NOT clickable?

In a Windows forms C# application, I have a number of RichTextBox controls that display a link as the last line of the text box, with no line break after.
The issue is that ALL of the white space that is physically below the link will be a clickable link. I understand that empty white space below text generally serves as "part" of that line in windows--for example, put your cursor just below this post, and click and drag--you will select the last line. But generally this does not include clickable links. Try it with the title of this post--you can select the title, but your cursor is not the clickable "hand" until you are actually directly over the title.
I could get around this by changing my data to always include a trailing line break, or modify the point where I'm setting the text of the box to always add one. But both of those seem messy. Is there no way to make a RichTextBox's links act more like links in a web browser?
I can reproduce this behavior by creating a sample WinForms application, dropping in a RichTextBox, and using the designer to set the text to "http://www.google.com" Anywhere BELOW the link will show the hand cursor.
I'm using Windows 7 / VS2010 / C# / .net Framework 4.0
Thanks for the advice.

Anywhere BELOW the link will show the hand cursor.
You need to put a line break to see the text cursor below the link not the hand cursor. Its by design.
I could get around this by changing my data to always include a
trailing line break, or modify the point where I'm setting the text of
the box to always add one. But both of those seem messy. Is there no
way to make a RichTextBox's links act more like links in a web
browser?
No. Put a line break after. Or set the RichTexbox DetectUrls property to false. Or as Hans mentioned use a Web Browser. Or use a 3rd party or open source RichTextBox control.
It would be good if the Cursor change event fired when hovering over a hyperlink but it doesn't :(

It would be good if the Cursor change event fired when hovering over a hyperlink but it doesn't :(
Jeremy's comment gave me an idea: surely the native RichTextBox control does receive some type of notification when the user hovers over a hyperlink, it apparently just is not exposed by the WinForms wrapper class.
A bit of research confirms my supposition. A RichTextBox control that is set to detect hyperlinks sends a EN_LINK notification to its parent through the WM_NOTIFY message. By processing these EN_LINK notifications, then, you can override its behavior when a hyperlink is hovered.
The WinForms wrapper handles all of this in private code and does not allow the client to have any direct control over this behavior. But by overriding the parent window's (i.e., your form) window procedure (WndProc), you can intercept WM_NOTIFY messages manually and watch for EN_LINK notifications.
It takes a bit of code, but it works. For example, if you suppress the WM_SETCURSOR message for all EN_LINK notifications, you won't see the hand cursor at all.
[StructLayout(LayoutKind.Sequential)]
struct CHARRANGE
{
public int cpMin;
public int cpMax;
};
[StructLayout(LayoutKind.Sequential)]
struct NMHDR
{
public IntPtr hwndFrom;
public IntPtr idFrom;
public int code;
};
[StructLayout(LayoutKind.Sequential)]
struct ENLINK
{
public NMHDR nmhdr;
public int msg;
public IntPtr wParam;
public IntPtr lParam;
public CHARRANGE chrg;
};
public class MyForm : Form
{
// ... other code ...
protected override void WndProc(ref Message m)
{
const int WM_NOTIFY = 0x004E;
const int EN_LINK = 0x070B;
const int WM_SETCURSOR = 0x0020;
if (m.Msg == WM_NOTIFY)
{
NMHDR nmhdr = (NMHDR)m.GetLParam(typeof(NMHDR));
if (nmhdr.code == EN_LINK)
{
ENLINK enlink = (ENLINK)m.GetLParam(typeof(ENLINK));
if (enlink.msg == WM_SETCURSOR)
{
// Set the result to indicate this message has been handled,
// and return without calling the default window procedure.
m.Result = (IntPtr)1;
return;
}
}
}
base.WndProc(ref m);
}
}
Unfortunately, that's the easy part. Now comes the ugly hack where we work around the default behavior of the control that you describe, where it treats the remainder of the control's height as part of the last line if the last line is a hyperlink.
To do this, we need to get the current position of the mouse pointer and compare it against the position of the hyperlink text that the control has detected. If the mouse pointer is within the hyperlinked line, we allow the default behavior and show the hand cursor. Otherwise, we suppress the hand cursor. See the commented code below for a potentially better explanation of the process (obviously, rtb is your RichTextBox control):
protected override void WndProc(ref Message m)
{
const int WM_NOTIFY = 0x004E;
const int EN_LINK = 0x070B;
const int WM_SETCURSOR = 0x0020;
if (m.Msg == WM_NOTIFY)
{
NMHDR nmhdr = (NMHDR)m.GetLParam(typeof(NMHDR));
if (nmhdr.code == EN_LINK)
{
ENLINK enlink = (ENLINK)m.GetLParam(typeof(ENLINK));
if (enlink.msg == WM_SETCURSOR)
{
// Get the position of the last line of text in the RichTextBox.
Point ptLastLine = rtb.GetPositionFromCharIndex(rtb.TextLength);
// That point was in client coordinates, so convert it to
// screen coordinates so that we can match it against the
// position of the mouse pointer.
ptLastLine = rtb.PointToScreen(ptLastLine);
// Determine the height of a line of text in the RichTextBox.
//
// For this simple demo, it doesn't matter which line we use for
// this since they all use the same size and style. However, you
// cannot generally rely on this being the case.
Size szTextLine = TextRenderer.MeasureText(rtb.Lines[0], rtb.Font);
// Then add that text height to the vertical position of the
// last line of text in the RichTextBox.
ptLastLine.Y += szTextLine.Height;
// Now that we know the maximum height of all lines of text in the
// RichTextBox, we can compare that to the pointer position.
if (Cursor.Position.Y > ptLastLine.Y)
{
// If the mouse pointer is beyond the last line of text,
// do not treat it as a hyperlink.
m.Result = (IntPtr)1;
return;
}
}
}
}
base.WndProc(ref m);
}
Tested and working… But did I mention that this is an ugly hack? Treat it more like a proof of concept. I certainly don't recommend using it in production code. I'm in fairly strong agreement with Hans and Jeremy that you should either take the simpler approach of adding a line break, or use a more appropriate control designed to display hyperlinks.

Detect system theme change in WPF

I need, for my WPF app, to detect when the DWM is turned on/off or when the system theme changes.
There is such an event in WinForms, but I can't see any in WPF.

I haven't heard of a WinForms event that fires when a WinForms window receives messages from the system, however it has its own WndProc() method that you can override. You're probably confusing window messages for form events. Ah, so it's the StyleChanged event that gets invoked in WinForms windows. The rest of my answer still stands though.
WPF isn't closely tied to the Windows API either as it's a high-level technology that invests a lot of abstraction away from the internals. For one, it draws everything in a window by itself, and doesn't ask the system to do the drawing for it (EDIT: which is why WPF lacks such a StyleChanged event). That said, Windows sends messages to all windows when the DWM is toggled and when the theme changes, and you can still drill down into the low level from the WPF layer to access these messages and manipulate your WPF controls accordingly.
Attach a window procedure to your WPF window's HWND (window handle) as part of your window's SourceInitialized event. In your window procedure, handle the WM_DWMCOMPOSITIONCHANGED and WM_THEMECHANGED window messages respectively.
Here's a quick example (with boilerplate code adapted from this question of mine):
private IntPtr hwnd;
private HwndSource hsource;
private const int WM_DWMCOMPOSITIONCHANGED= 0x31E;
private const int WM_THEMECHANGED = 0x31A;
private void Window_SourceInitialized(object sender, EventArgs e)
{
if ((hwnd = new WindowInteropHelper(this).Handle) == IntPtr.Zero)
{
throw new InvalidOperationException("Could not get window handle.");
}
hsource = HwndSource.FromHwnd(hwnd);
hsource.AddHook(WndProc);
}
private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
{
switch (msg)
{
case WM_DWMCOMPOSITIONCHANGED:
case WM_THEMECHANGED:
// Respond to DWM being enabled/disabled or system theme being changed
return IntPtr.Zero;
default:
return IntPtr.Zero;
}
}

Unfortunately the accepted solution does not work with Aero color theme changes, and the WM message hex numbers are mixed up - but I agree that it is very useful if you want to catch WM messages in WPF. I've been trying to find a solution to this problem for a while, and I think I've got it solved for all possible cases (for aero and classic themes).
The Aero color change triggers the WM_DWMCOLORIZATIONCOLORCHANGED message.
To detect when the color theme changes you have to use multiple methods. The Form.StyleChanged event is going to detect all theme change, except for Aero color changes. Here is an alternative solution to StyleChanged. (Ok, I know this is WinForms, but you've got the idea. The WPF equivalent is in the accepted answer anyway.)
private const int WM_DWMCOLORIZATIONCOLORCHANGED = 0x320;
private const int WM_DWMCOMPOSITIONCHANGED = 0x31E;
private const int WM_THEMECHANGED = 0x031A;
protected override void WndProc(ref Message m)
{
switch(m.Msg)
{
case WM_DWMCOLORIZATIONCOLORCHANGED:
case WM_DWMCOMPOSITIONCHANGED:
case WM_THEMECHANGED:
// you code here
break;
default:
break;
}
base.WndProc(ref m);
}
For Aero color themes, the SystemEvents.UserPreferenceChanged event works too (thanks sees!):
Microsoft.Win32.SystemEvents.UserPreferenceChanged += SystemEvents_UserPreferenceChanged;
private void SystemEvents_UserPreferenceChanged(object sender, Microsoft.Win32.UserPreferenceChangedEventArgs e)
{
if (e.Category == Microsoft.Win32.UserPreferenceCategory.General)
{
// your code here, compare saved theme color with current one
}
}
As you can see above, it is far from intuitive. Aero color change triggers a 'General' preference change event, even though there are many more suitable ones for this, like 'VisualStyle', etc...
If you want to be thorough, you should compare the saved DWM color to the current DWM color, to make sure it was indeed an Aero color theme that triggered this event (using the DwmGetColorizationParameters API call), and not something else. See these answers on how Aero colors can be retrieved:
Get the active color of Windows 8 automatic color theme

The event SystemEvents.UserPreferenceChanged also does the trick.
UserPreferenceChanged(in Japaense)

Blocking the ability of being able to highlight text in a textbox in a C# windows form

I want to create a Windows form in C# with textbox whose text cannot be altered or selected by the user.
I managed to make it unalterable (ReadOnly = true), but I am still able to select and highlight the text.
How can I change this?
Thanks!
-R

This is the expected behavior and is by design. You can see this for yourself if you right-click on an item in Windows Explorer and open its Properties window. All of the dynamic text fields on the "General" tab are selectable, though not modifiable. If this is not the behavior you desire, you should strongly consider using a Label control instead. This is the exact situation for which it was intended—static text that is not selectable by the user.
In case, for whatever reason, you're not sold on why you should use a Label control instead, I'll proceed onward in answering the question you asked. The major problem with trying to override this behavior (like overriding the default behavior of any control) is that there are a lot of ways for the user to accomplish it: clicking and dragging with the mouse, double-clicking the mouse button, using the arrow keys on the keyboard in combination with the Shift key, tabbing into the textbox,right-clicking and choosing "Select All" from the context menu, etc...
Your first instinct might be to override the potentially relevant events exposed by the .NET Framework (such as OnMouseDown, OnKeyDown, etc.) and reset the selected length to 0 so that the text is immediately unselected after it is automatically selected. However, this causes a little bit of a flicker effect in the process, which may or may not be acceptable to you.
Alternatively, you could do the same thing by overriding the control's WndProc method, watching for the relevant window messages, and preventing the messages from being passed on to the control's base class altogether. This will prevent the flicker effect because the base TextBox control never actually receives a message causing it to automatically select its text, but it does have the obvious side effect of preventing the control from taking any action as a result of these common events. It seems like that probably doesn't matter to you in this case, but realize that this is still a pretty drastic hack. I definitely cannot recommend it as being good practice.
That being said, if you're still interested, you could use the following custom UnselectableTextBox class. It prevents the processing of every window message that I could think of which would possibly allow the user to select text. It does indeed work, but fair warning: there may be yet others I haven't thought of.
public class UnselectableTextBox : TextBox
{
public UnselectableTextBox() : base()
{
//Set it to read only by default
this.ReadOnly = true;
}
protected override void OnGotFocus(System.EventArgs e)
{
base.OnGotFocus(e);
//Prevent contents from being selected initally on focus
this.DeselectAll();
}
protected override void WndProc(ref System.Windows.Forms.Message m)
{
const int WM_KEYDOWN = 0x100;
const int WM_LBUTTONDOWN = 0x201;
const int WM_LBUTTONDBLCLK = 0x203;
const int WM_RBUTTONDOWN = 0x204;
if ((m.Msg == WM_KEYDOWN) || (m.Msg == WM_LBUTTONDOWN) ||
(m.Msg == WM_LBUTTONDBLCLK) || (m.Msg == WM_RBUTTONDOWN))
{
this.DeselectAll();
return;
}
base.WndProc(ref m);
}
}

Use label inplace of textbox. I think you only want to show information but not to select, not to copy, using label will be better option...

Is disabling it an option? (Enabled = false)

Show a custom calendar dropdown with a derived DateTimePicker class

My goal is to create a custom DateTimePicker class in .NET 2.0, which shows a custom calendar dropdown instead of the Windows default calendar popup.
By observing Windows messages (see attached code), I am able to find and hide/close the calendar window after creation.
However, a problem remains: After the calendar window is closed, something is still blocking the mouse input. For example, if you try to maximise the owner form of the customised DateTimePicker control after the calendar dropdown has been closed programmatically (attached code), the maximise button does not respond. Only the next click works. Interestingly, the "non-functional click" fires the DTN_CLOSEUP notification, so it appears that the WM_CLOSE did not properly close the calendar.
Any hints on how to accomplish my task are highly appreciated :)
protected override void WndProc(ref System.Windows.Forms.Message m)
{
if (m.Msg == (int)SYSMSG.WM_REFLECT + (int)SYSMSG.WM_NOTIFY)
{
NMHDR nmhdr = (NMHDR)m.GetLParam(typeof(NMHDR));
switch (nmhdr.code)
{
case DTN_DROPDOWN:
// Hide window
IntPtr calHandle = FindWindow("SysMonthCal32", null);
SendMessage(calHandle, (int)SYSMSG.WM_SIZE, 0, SP.Convert.MakeLong(0, 0));
this.BeginInvoke((MethodInvoker)delegate()
{
SendMessage(calHandle, (int)SYSMSG.WM_CLOSE, 0, 0);
});
break;
}
}
base.WndProc(ref m);
}

Instead of sending a WM_CLOSE have you tried sending a DTM_CLOSEMONTHCAL message instead? You would send this to the HWND of the DateTimePicker itself and not the child window. According to the documentation, the DateTime_CloseMonthCal macro sends this message and it seems like what you want to do.
I also don't think you'll need to use BeginInvoke to send it unless there's some problem with closing it in the same dispatch as a drop down notification.
#define DTM_FIRST 0x1000
#define DTM_CLOSEMONTHCAL (DTM_FIRST + 13)
#define DateTime_CloseMonthCal(hdp) SNDMSG(hdp, DTM_CLOSEMONTHCAL, 0, 0)

I finally found this fully customisable datePicker (monthCalendar rendering is override-able) : Culture Aware Month Calendar and Datepicker on CodeProject