Re: Center Text on Custom Button - C# Discussion Boards

22-May-07 7:17

I have a custom button that I have created which inherits from windows.forms.button. I simply override the mouseenter, mouseover, and mousedown events to paint a custom gradient over the button. In doing so, I must redraw the available image and text. I have been able to align the image with the base. However, I am unable to do the same with the text. Specifically, centering. It is close, just not perfect.

SizeF wSize = graphics.MeasureString(this.Text, this.Font);
float wCenterX = (Width - wSize.Width) / 2;

mTextPt.X = wCenterX;//this does not work properly
mTextPt.Y = Height - 19;// this works fine

e.Graphics.DrawString(this.Text, this.Font, new SolidBrush(this.ForeColor), mTextpt);

For most of the buttons, the text shifts slightly to the left when I use any of the custom events.

Any suggestions would be greatly appreciated. Thanks.

PHD

Manoj Kumar Rai22-May-07 8:02

Manoj Kumar Rai

22-May-07 8:02

The only issue I can see with this code is of rounding off of the wCenterX. Even you have calculated it in float while setting it to the "mTextPt.X" the decimal part will be truncated. But this will have only 1 point difference.

Manoj
Never Gives up

PHDENG8122-May-07 8:29

22-May-07 8:29

Thanks Manoj. I checked the precision and it seems to be fine. Any other suggestions?

Ian Shlasko22-May-07 10:34

22-May-07 10:34

I would suggest looking into the StringFormat parameter.

Use this overload of Graphics.DrawString instead:

public void DrawString (
	string s,
	Font font,
	Brush brush,
	RectangleF layoutRectangle,
	StringFormat format
)

layoutRectangle would be the entire client area of the button (0,0,Width,Height)

For the last parameter, create a new StringFormat, and set the horizontal and vertical alignments to center.

Basically, let the framework do the dirty work.

PHDENG8123-May-07 0:45

23-May-07 0:45

Thanks for the suggestion Ian. I should have mentioned that I tried using the StringFormat parameter. There doesn't seem to be any way to "pad" the text when using the StringFormat. Therefore, when you place the text at the bottom of the control, it simply places the text about a pixel or so above the bottom. Therefore, it doesn't align with the base text.

Any other suggestions? Thanks.

Ian Shlasko24-May-07 3:40

24-May-07 3:40

Sorry for the delayed response, but in case you haven't found an answer yet...

If you're centering text, it doesn't really make a difference, but if you're aligning to a side, you might want to shrink the bounding box.

Instead of (0,0,Width,Height), use, say, (2,2,Width-4,Height-4). That'll add a 2-pixel margin on all sides. You could try just tweaking this until it matches up.

PHDENG8124-May-07 4:38

Disabling controls without changing appearance

24-May-07 4:38

Hey Ian,

Once again, thanks for the response. I don't seem to have an issue aligning to the sides. I just can't calculate the proper "X" value while centering the desired text. This is completely beyond me. I really appreciate your help. If you have any other suggestions, I would like to hear them.

Thanks again

PHD

Ian Shlasko22-May-07 6:13

22-May-07 6:13

I'm writing a rather large data access application (CLR 2.0, rich-client), and I've started adding some security routines. Simple flags to prevent certain users from editing certain items.

Basically, I have a number of record editing dialogs (Well, I have one so far, but there will be many), and I'm trying to find a way to make them double as read-only viewers for users who aren't allowed to make changes.

The idea is to prevent the user from interacting with any controls that are "locked" without damaging the appearance.

* I don't want to subclass the windows forms controls (I'm using aspects to add custom behavior via event hooking when needed) as the program uses a LOT of them, and I don't want to slow down GUI updates and layout logic with extra layers of inheritance, especially when only a fraction of the controls will use this particular feature.

* I don't want to just set the Enabled property, as this grays out the control, making it difficult to read and therefore useless as a viewer. Textboxes have their ReadOnly property, but this doesn't help for dropdowns, checkboxes, etc.

* Data integrity is not an issue here, as the changes are all funneled through a secure update routine. This is exclusively a display issue. I don't want the user to be able to change control values if those changes can't be saved anyway.

I can hook the keydown events to kill any keyboard actions on them, and set a dummy context menu to prevent right-click copy/pasting, so textboxes are easily handled. It's the other controls (Comboboxes, checkboxes, radiobuttons) that are the real issue.

Since I can restrict any keyboard entry, an ideal solution would be a way to just intercept any mouse activity before it reaches the controls. On a simpler scale, I could hover a transparent form to actually shield them, but that would be horribly inefficient in this case.

I've tried hooking the GotFocus and automatically moving the focus to another control, but this isn't sufficient, since the initial mouse click goes through before the focus is moved, and that's enough to click a button or hit the dropdown button on a combobox. Looks amateurish if the dropdown triggers, then kicks you out.

Worst case, I'll just make separate editors and viewers, but I'm trying to avoid this if possible. This app will see a lot of maintenance, by me and any future teammates, and I want that to be as painless as possible.

Any ideas?

Dave Herren22-May-07 6:33

Dave Herren

22-May-07 6:33

First let me say excellent post. And Second, I thought of a simple solution to the combobox problem. When you are in display mode why not use textboxes instead? The lack of the dropdown graphic would make it clear that it is read only and you have already figured out how to handle textboxes. I realize this won't be nearly as satisfying as the high-end solutions you're coding, but I believe it would be effective. Also if you get all of this figured out it would make a killer article on the site, if you get a chance. Best of luck.

topcoderjax - Remember, Google is your friend.

Ian Shlasko22-May-07 7:42

Re: Disabling controls without changing appearance (Solved!)

22-May-07 7:42

Hot-swapping the control would require some redesigning, but might be an option if I can't figure this out. Right now, I have the locking routine in a utility library (Separate assembly):

public static void LockEditing(Form frm, params Control[] exceptions)

So the editor form, after running a security check, calls it using:

<CompanyName>.Util.ControlOperations.LockEditing(this, btnCancel);
btnCancel.Text = "Close";

Nice and clean, but limits me to public interfaces, so the form itself would have to do the swapping, instead of the centralized code.

Ian Shlasko22-May-07 10:05

Re: Disabling controls without changing appearance (Solved!)

22-May-07 10:05

Bingo. Switching controls would have been too intrusive to the design, but you gave me the winning idea. It's a little odd, but it works like a charm...

First, the lock routine goes through the control tree of the form, and finds the highest-level controls possible without including the exceptions, and locks those only. Fun little algorithm, but not the point, so onward...

I knew I couldn't override the WndProc, and totally eat mouse messages, without subclassing, right? Well, that doesn't stop me from adding an extra container.

Form
|
|-Panel1
   \-Something
\-Panel2
   |-Something
   \-CancelButton

Becomes...

Form
|
|-LockPanel
|  \-Panel1
|     \-Something
\-Panel2
   |-LockPanel
   |  \-Something
   \-CancelButton

The LockPanel instances are empty panels that basically swallow the member control. They set their location/size/dock to the control, set their backcolor to the parent, insert themselves in place of the control, and Dock.Fill the control into themselves. Basically, it adds a controllable layer without affecting the form's logic.

Why, though?

protected override void WndProc(ref Message m)
{
    /*
     * When we receive a mouse activation, deny it.
     * This prevents any child controls from being clicked.
     */
    // WM_MOUSEACTIVATE
    if (m.Msg == 0x0021)
        m.Result = new IntPtr(4); // MA_NOACTIVATEANDEAT
    else
        base.WndProc(ref m);
}

This, along with a KeyDown hook that sets Handled and SuppressKeyPress to true, makes the controls react to hover-type events (They light up, highlight borders, etc), but not to clicks of any sort. As for the keyboard, you can <tab> into them, but can't actually affect the contents.

Martin#22-May-07 21:43

Martin#

22-May-07 21:43

Hello,

Very Nice idea (got my "5")

Just couse I'm currious (and had the same problem once).
Do you have TextBoxes in your panel aswell?
If yes, do they get focused and show the carret?

All the best,

Martin

Re: Disabling controls without changing appearance (Solved!)

Ian Shlasko23-May-07 6:13

Re: Disabling controls without changing appearance (Solved!)

23-May-07 6:13

They do get focused, but not by mouse clicks. You can <TAB> to them, but can't actually modify them.

Martin#23-May-07 7:04

Martin#

23-May-07 7:04

O.K.

I had the same problem (and I didn't whanted to se the carret inside the textbox), so as a workaround I handled (overrided) the OnFocus and reseted the focus on an other (hidden) Control.

All the best,

Martin

Dave Herren22-May-07 6:38

Dave Herren

22-May-07 6:38

Oh and another thought, how about disabling the controls and hooking the paint event to display them as though they were enabled.

topcoderjax - Remember, Google is your friend.