Get Button Text location

[Nathan Laff]

How can I get the bottom position of a buttons text?

I have a usercontrol which has 2 button, both side by side, both 23px
height. both at Y pos of 0.

I want the snapline to act just like a regular button but I'm having
trouble finding the bottom position of the text in the the buttons in the
user control.

 

[Guest]

You could estimate the location of a rectangle that encompases the bounds of
the text by using a GetTextExtent method. The drawback is that it requires a
Graphics object in order to know the context in which to draw, so you'll have
to do that in a Paint event (or OnPaint override). For example (which
assumes there is a button1 object, in a class named Form1, with a Label
control whose variable is named label1, button1_MouseMove is subscribed to
button1's MouseMove event, and Form1_Paint is subscribed to Form1's Paint
event):

private Rectangle textRectangle;

private void Form1_Paint ( object sender, PaintEventArgs e )
{
VisualStyleRenderer vsr = new
VisualStyleRenderer(VisualStyleElement.CreateElement(VisualStyleElement.Button.PushButton.Normal.ClassName,
VisualStyleElement.Button.PushButton.Normal.Part,
VisualStyleElement.Button.PushButton.Normal.State));
// get the extent of the text in a button relative to the button.
textRectangle = vsr.GetTextExtent(e.Graphics, button1.Bounds, button1.Text,
TextFormatFlags.VerticalCenter | TextFormatFlags.HorizontalCenter);
}

private void button1_MouseMove ( object sender, MouseEventArgs e )
{
if (textRectangle.Contains(e.Location))
{
label1.Text = "Over button text";
}
else
{
label1.Text = "NOT Over button text";
}
}

 

[Peter Duniho]

[...]
The drawback is that it requires a
Graphics object in order to know the context in which to draw, so you'll
have
to do that in a Paint event (or OnPaint override).

That's not correct. You can get a Graphics object at any time, using
Control.CreateGraphics(). There's no need to wait for the Paint event.

It may make sense to simply get the text size metrics once, only updating
it if and when the formatting changes.

Pete

 

[Guest]

Except that the Graphics object is not in the same state as it was in the
Paint event. So, the button could be painted differently in the two Graphics
objects.
--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

[...]
The drawback is that it requires a
Graphics object in order to know the context in which to draw, so you'll
have
to do that in a Paint event (or OnPaint override).

That's not correct. You can get a Graphics object at any time, using
Control.CreateGraphics(). There's no need to wait for the Paint event.

It may make sense to simply get the text size metrics once, only updating
it if and when the formatting changes.

Pete

 

[Peter Duniho]

Except that the Graphics object is not in the same state as it was in the
Paint event. So, the button could be painted differently in the two
Graphics
objects.

It *should* be the same though. I agree that it is theoretically possible
for them to differ. But extremely unlikely.

In any case, my point is simply that it's not true that when something
"requires a Graphics object" that it is a necessary conclusion that
"you'll have to do that in a Paint event".

Pete

 

[Guest]

BTW, I don't consider it unlikely at all. If the user changes their display
settings, moves the application from one monitor to another, goes in and out
of hibernation, etc. you're likely to need to update the Graphics object.

 

[Guest]

It also depends on what level of "unlikely" you want to handle. From an
end-user's stand point it doesn't matter that what they did just to crash the
application was deemed "unlikely" to occur by the programmer. For example,
how unlikely is it that a user will enter some SQL commands when they enter
their name into application...

If you want reliability you want it all the time; not just in the most
likely of cases. If that's what you want, then "requires" is an appropriate
verb.

 

[Peter Duniho]

BTW, I don't consider it unlikely at all. If the user changes their
display
settings, moves the application from one monitor to another, goes in and
out
of hibernation, etc. you're likely to need to update the Graphics object.

None of those things are common, nor do I see any reason any except the
change in display settings would cause a difference between the measured
metrics the actual output. Certainly simply hibernating and resuming
isn't going to affect the metrics, and that's the only scenario in your
list that is even close to being arguably common (and then only common for
laptops, even though possible on any suitably-equipped PC).

But that's not relevant anyway. I refer you to my previous statement
(which you quoted, so surely you already saw it):

In any case, my point is simply that it's not true that when
something "requires a Graphics object" that it is a necessary
conclusion that "you'll have to do that in a Paint event"."

Pete

 

[Peter Duniho]

[snip]

Wow. Was that really bugging you for the last three weeks, or what?

See my previous post in which I reiterate the actual point I was making,
as opposed to the straw man points by which you appear to have been
disturbed.

I apologize if the issue caused you undue stress.