Re: Find The Text :-)
- From: "Ivar" <Ivar.ekstromer000@xxxxxxx>
- Date: Mon, 23 Jul 2007 21:42:05 GMT
"Mike Williams" <mikea@xxxxxxxxxxxxxxxxx> wrote in message
news:eJNuEdWzHHA.484@xxxxxxxxxxxxxxxxxxxxxxx
"Ivar" <Ivar.ekstromer000@xxxxxxx> wrote in message
news:JE6pi.956$ie3.577@xxxxxxxxxxxxxxxxxxxxxxx
The forms font is MS Sans Serif, Regular, size 8 (the default
font on my system)
Actually, although what I am about to say has nothing whatsoever to do
with the problem you have noticed, the default font point size on your
system is not 8! On the assumption that your machine is running at the
standard "Windows 96 dpi" setting it is not possible to have a screen font
that is 8 points! That's because Windows requires all font sizes to be a
size that equates to a "whole pixel value" on the specified output device
(the screen, in this case) and at the standard 96 dpi screen setting a
font size of 8 points would be the equivalent of 8/72*96 = 10.67 pixels.
That value is not allowed, because it is not a "whole pixel" value, and so
Windows will set the font size to the nearest available "whole pixel"
size, which on your own machine is 11 pixels. That means the font size is
actually 11/96*72 = 8.25 points! On a different Windows machine, which
might be running at some other dpi setting, a "requested 8 point font
size" might be some other value. For example, on a machine running at 120
dpi an "8 point" font would actually be "asking for" 13.33 pixels, and it
would therefore set itself to the nearest whole pixel value of 13 pixels,
which on a 120 dpi machine would be 7.8 points. If you're interested in
what an actual point size comes to on your own machine then you should
check it in code. For example, on your own "default 8 point MS Sans Serif"
machine, try the following in your Form:
Private Sub Command_Click()
Print Me.Font.Size
End Sub
This applies to True Type fonts as well as screen fonts. For example, try
this:
Private Sub Command1_Click()
Dim n As Long
Me.Font.Name = "Times New Roman"
For n = 1 To 72
Me.Font.Size = n
List1.AddItem Format(n) & vbTab & Format(Me.Font.Size)
Next n
End Sub
Yep, understand that, I was just stating what was in the Font Properties
dialog box, but it made interesting reading.
On my system Retval = 261, but the text will print on
the form even though it has a Rect that is 260 wide.
Either the text cannot fit in the allowed area (but it
does) or TextWidth is telling lies.
There are occasions when the width and height of rectangle is dealt with
differently by different pieces of code. For example, offhand I think that
the API drawing functions draw a box "up to but excluding the bottom right
corner" whereas VB draws it "up to and including the bottom right
corrner". But you really should worry too much about an odd pixel or so
under most conditions, unless there are very specific reasons for doing so
(which of course is sometimes the case). In your own specific example
though the TextWidth" is not telling lies! In your code you are drawing a
line of text into a specified rectangle, but you are not "wrapping" that
text. Therefore, any text that will not fit into the rectangle will simply
be clipped. That's what is happening in your code. The text is being drawn
and is being clipped at the right edge of the specified rectangle.
However, the "glyphs" of most characters (the parts of the character cell
that are black in black text) do not actually occupy the entire character
cell and there is some "white space" within the cell, some at the top and
some at the bottom and a little bit less at both sides, and sometimes "the
black bits" even extend outside of the cell they occupy. Fonts are fairly
complicated things. The TextWidth of a character returns the width of the
full character cell, including the "white bits". Therefore, the "odd
pixel" that is being clipped in your own code is not obvious in your
output, because it was a "blank pixel" anyway! To see what really happens
in your "260 pixel wide" output rectangle when you print a "261 pixel
wide" string of text you need to set the DrawText API to "wrap" the text".
This will cause it to wrap onto the next line if even a single pixel of a
character cell will not fit into the desired width, and the result will be
obvious, whereas your existing code is simply "allowing it to clip", which
will not be obvious, especially if the "clipped pixels" were not black
anyway!
Another Blond moment on my part (it has just not been my day) all I was
looking at was the fact that the full stop at the end if the text was being
drawn. so the "glyph" of the full stop was being drawn but not the whole
cell. when I added the wordbreak parameter it truncated the text. It's one
of those things where I knew that, but forgot it on my blond day
By the way, did you not like my TextBox suggestion, where the code allowed
the standard TextBox to wrap the lines and then pulled the individual
lines of text out one by one into a String array? It could help you a lot
(although there are of course all sorts of different ways of tackling this
job).
Like it? I think it's brill, and it's part of the basics of what I'm doing
(attempting) but, I dont understand it. I was going to post a couple of Qs
about it.
"sInitial = Chr$(100 - 1) & Chr(0)"
EH! What's that about? Why Chr$(100 - 1), Why not just sInitial = "C" &
Chr(0)
And why "C" any reason for that?
"Mid(sBuffer, 1, 2) = sInitial". Never seen Mid used like that before, I
know what it does and know it dosn't work without it, But apart from
changing a couple of chars in sBuffer I can't see what it does or why the
sendmessage api does not work without it.
I've still got a fair way to go with this highlighting text stuff yet, but
at least I now understand (I hope) why the area I was highlighting (Via
InvertRect) was sometimes a few pixels off when the main text was center or
right aligned. I'll have another go tomorrow eve.
Thanks Mike
Ivar
.
- Follow-Ups:
- Re: Find The Text :-)
- From: Mike Williams
- Re: Find The Text :-)
- References:
- Find The Text :-)
- From: Ivar
- Re: Find The Text :-)
- From: Mike Williams
- Re: Find The Text :-)
- From: Ivar
- Re: Find The Text :-)
- From: Mike Williams
- Re: Find The Text :-)
- From: Ivar
- Re: Find The Text :-)
- From: Mike Williams
- Find The Text :-)
- Prev by Date: Re: Parent object question
- Next by Date: Re: Check if a DLL exists...
- Previous by thread: Re: Find The Text :-)
- Next by thread: Re: Find The Text :-)
- Index(es):
Relevant Pages
|