Vensia said:I have a text box in Detail section. The text box has property Can Grow =
Yes.
Is it possible to know the height of the text box in Detail_Format event ?
Marshall Barton said:Text boxes don't have "rows".
To draw a line the same height as a can grow text box, get
rid of the line control and use the Line method in the Print
event:
Me.Line (txtbox.Left,txtbox.Top) - Step(0,txtbox.Height)
The VBA Help file for the Line, Circle and PSet methods is
totally garbled, but the examples are valid.
--
Marsh
MVP [MS Access]
Actually I want to know how many rows the text box will expand.
I have a vertical line (line control) and I want the text box and the line
control has the same height.
Thx.
Vensia
event
?
Marshall Barton said:You can not get the can grow height of a text box in the
Format event no mstter how much you want to.
Have you tried setting the report's DrawWidth property?
Me.DrawWidth = 3
Me.Line ( . . .
If that can not be made to generate the desired effect, you
can calculate a close approximation of the text box's final
height by using the fTextWidthHeight function at
www.lebans.com You may have to make the text box and
detail section taller and use CanShrink, because the format
event can not make the line taller than the pregrow height
of the detail section (kind of a catch 22).
--
Marsh
MVP [MS Access]
I can't use line method because the border width of the line is not same
(unstable) if I use different printers to print the report.
So I decide to use line control and if I can know the height of the can
grow text box, then I can set the same height for the line control.
Thx.
"Marshall Barton" wrote
Marshall Barton said:You can not get the can grow height of a text box in the
Format event no mstter how much you want to.
Have you tried setting the report's DrawWidth property?
Me.DrawWidth = 3
Me.Line ( . . .
If that can not be made to generate the desired effect, you
can calculate a close approximation of the text box's final
height by using the fTextWidthHeight function at
www.lebans.com You may have to make the text box and
detail section taller and use CanShrink, because the format
event can not make the line taller than the pregrow height
of the detail section (kind of a catch 22).
--
Marsh
MVP [MS Access]
I can't use line method because the border width of the line is not same
(unstable) if I use different printers to print the report.
So I decide to use line control and if I can know the height of the can
grow text box, then I can set the same height for the line control.
Thx.
"Marshall Barton" wrote
Marshall Barton said:Since it is just a VBA module you import into your app, yes,
it will work in Access 97, 2000, 2002, 2003 (and probably
2007) on Windows 98, ME, 2000, XP (and probably Vista).
All those API calls only rely on the standard Windows
interface, so, no, you do not need any additional libraries.
It's not often that it's needed, but when it is, it is
ridiculously easy to use. Stephen did a terriffic job
creating that code.
I hope it helps solve your problem.
--
Marsh
MVP [MS Access]
I have downloaded module modTextHeightWidth.
Can this module used for Access XP and Access 2003 ?
Do I need additional library ?
"Marshall Barton" wrote
Marshall Barton said:For your purposes, you don't want the number of lines, you
want the Height (in twips). This is the value you want to
use to set the line control's Height property.
I have never seen that function be off by more that a few
twips. Pehaps you are not using the appropriate arguments??
I think your case only needs something like:
Me.yourline.Height = fTextHeight(yourtextbox)
--
Marsh
MVP [MS Access]
I have used fTextHeight function to calculate the height of the text box.
But in several cases, I find the calculation is false. Actually the text
box
contains 3 lines but the function returns 2.
"Marshall Barton" wrote
same (unstable) if I use different printers to print the report.
can grow text box, then I can set the same height for the line control.
the line control has the same height.
Marshall Barton said:For your purposes, you don't want the number of lines, you
want the Height (in twips). This is the value you want to
use to set the line control's Height property.
I have never seen that function be off by more that a few
twips. Pehaps you are not using the appropriate arguments??
I think your case only needs something like:
Me.yourline.Height = fTextHeight(yourtextbox)
--
Marsh
MVP [MS Access]
I have used fTextHeight function to calculate the height of the text box.
But in several cases, I find the calculation is false. Actually the text box
contains 3 lines but the function returns 2.
"Marshall Barton" wrote
same (unstable) if I use different printers to print the report. the
can grow text box, then I can set the same height for the line control. and
the line control has the same height. property
Can Grow = Yes.
Stephen Lebans said:I did not realize that Vensia posted to the NG's as she made no reference to
this in her Email to me. I replied that the issue has to do with how Access
determines line breaks/hyphenation specifically for extended numerical
sequences.
As you suggested Marshall, the OP should add a fudge factor or better yet,
return to the Line method as you outlined. The issue of ensuring that the
line thickness ise the same on all printers can be resolved.
The following is previous post of mine on this issue.
Hi Duane,
here is a previous post of mine to aid the OP in understanding this issue.
He will have to use the Printer Object to check the current resolution of
the desired printer in order to set the DrawWidth property accurately.
' *** START ORIGINAL POST
Hi Matthias.
If I remember correctly the DrawWidth property is expressed in output
device Pixels. If Kathy desires a line of two points in width then you
will have to factor in the output device resolution. For example: 72
points per inch(Standard printer scale)
600 DPI output resolution
600/72 = 8 device pixels per printer point
So we would need to set the DrawWidth to 16 to get a 2 Point line width.
Obviously I've rounded 600/72 = 8.33 to 8 as the DrawWidth prop is an
Integer value. Also if accuracy is paramount remember that the output
resolution is never what is listed for the device. For example a laser
printer rated at 600DPI does not mean there are:
600 * 8.5 = 5100 pixels horizontally
600 * 11 = 6600 pixels vertically
on the output page. Most printing devices have a nonprint area, a border
that their print engine cannot image onto. This reduces the effective
output resolution by the amount of this "margin".
' *** END ORIGINAL POST
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
Marshall Barton said:For your purposes, you don't want the number of lines, you
want the Height (in twips). This is the value you want to
use to set the line control's Height property.
I have never seen that function be off by more that a few
twips. Pehaps you are not using the appropriate arguments??
I think your case only needs something like:
Me.yourline.Height = fTextHeight(yourtextbox)
--
Marsh
MVP [MS Access]
I have used fTextHeight function to calculate the height of the text box.
But in several cases, I find the calculation is false. Actually the text
box
contains 3 lines but the function returns 2.
"Marshall Barton" wrote
Since it is just a VBA module you import into your app, yes,
it will work in Access 97, 2000, 2002, 2003 (and probably
2007) on Windows 98, ME, 2000, XP (and probably Vista).
All those API calls only rely on the standard Windows
interface, so, no, you do not need any additional libraries.
Vensia wrote:
I have downloaded module modTextHeightWidth.
Can this module used for Access XP and Access 2003 ?
Do I need additional library ?
You can not get the can grow height of a text box in the
Format event no mstter how much you want to.
Have you tried setting the report's DrawWidth property?
Me.DrawWidth = 3
Me.Line ( . . .
If that can not be made to generate the desired effect, you
can calculate a close approximation of the text box's final
height by using the fTextWidthHeight function at
www.lebans.com You may have to make the text box and
detail section taller and use CanShrink, because the format
event can not make the line taller than the pregrow height
of the detail section (kind of a catch 22).
Vensia wrote:
I can't use line method because the border width of the line is not
same (unstable) if I use different printers to print the report.
So I decide to use line control and if I can know the height of the
can grow text box, then I can set the same height for the line control.
"Marshall Barton" wrote
Text boxes don't have "rows".
To draw a line the same height as a can grow text box, get
rid of the line control and use the Line method in the Print
event:
Me.Line (txtbox.Left,txtbox.Top) - Step(0,txtbox.Height)
The VBA Help file for the Line, Circle and PSet methods is
totally garbled, but the examples are valid.
Vensia wrote:
Actually I want to know how many rows the text box will expand.
I have a vertical line (line control) and I want the text box and
the line control has the same height.
Vensia wrote:
I have a text box in Detail section. The text box has property
Can Grow = Yes.
Is it possible to know the height of the text box in
Detail_Format event?
The answer is no, not until the Print event.
Marshall Barton said:Thanks for jumping in, Stephen.
I've never run into this problem and I have your
TextWidthHeight in every one of my apps. I thought(?) the
function actually built the formatted text in a rectangle
the same size as the text box. Are you saying that the API
formats the text differently than Access does???
--
Marsh
MVP [MS Access]
Stephen said:I did not realize that Vensia posted to the NG's as she made no reference
to
this in her Email to me. I replied that the issue has to do with how
Access
determines line breaks/hyphenation specifically for extended numerical
sequences.
As you suggested Marshall, the OP should add a fudge factor or better yet,
return to the Line method as you outlined. The issue of ensuring that the
line thickness ise the same on all printers can be resolved.
The following is previous post of mine on this issue.
Hi Duane,
here is a previous post of mine to aid the OP in understanding this issue.
He will have to use the Printer Object to check the current resolution of
the desired printer in order to set the DrawWidth property accurately.
' *** START ORIGINAL POST
Hi Matthias.
If I remember correctly the DrawWidth property is expressed in output
device Pixels. If Kathy desires a line of two points in width then you
will have to factor in the output device resolution. For example: 72
points per inch(Standard printer scale)
600 DPI output resolution
600/72 = 8 device pixels per printer point
So we would need to set the DrawWidth to 16 to get a 2 Point line width.
Obviously I've rounded 600/72 = 8.33 to 8 as the DrawWidth prop is an
Integer value. Also if accuracy is paramount remember that the output
resolution is never what is listed for the device. For example a laser
printer rated at 600DPI does not mean there are:
600 * 8.5 = 5100 pixels horizontally
600 * 11 = 6600 pixels vertically
on the output page. Most printing devices have a nonprint area, a border
that their print engine cannot image onto. This reduces the effective
output resolution by the amount of this "margin".
' *** END ORIGINAL POST
Stephen Lebans said:I did not realize that Vensia posted to the NG's as she made no reference to
this in her Email to me. I replied that the issue has to do with how Access
determines line breaks/hyphenation specifically for extended numerical
sequences.
As you suggested Marshall, the OP should add a fudge factor or better yet,
return to the Line method as you outlined. The issue of ensuring that the
line thickness ise the same on all printers can be resolved.
The following is previous post of mine on this issue.
Hi Duane,
here is a previous post of mine to aid the OP in understanding this issue.
He will have to use the Printer Object to check the current resolution of
the desired printer in order to set the DrawWidth property accurately.
' *** START ORIGINAL POST
Hi Matthias.
If I remember correctly the DrawWidth property is expressed in output
device Pixels. If Kathy desires a line of two points in width then you
will have to factor in the output device resolution. For example: 72
points per inch(Standard printer scale)
600 DPI output resolution
600/72 = 8 device pixels per printer point
So we would need to set the DrawWidth to 16 to get a 2 Point line width.
Obviously I've rounded 600/72 = 8.33 to 8 as the DrawWidth prop is an
Integer value. Also if accuracy is paramount remember that the output
resolution is never what is listed for the device. For example a laser
printer rated at 600DPI does not mean there are:
600 * 8.5 = 5100 pixels horizontally
600 * 11 = 6600 pixels vertically
on the output page. Most printing devices have a nonprint area, a border
that their print engine cannot image onto. This reduces the effective
output resolution by the amount of this "margin".
' *** END ORIGINAL POST
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
Marshall Barton said:For your purposes, you don't want the number of lines, you
want the Height (in twips). This is the value you want to
use to set the line control's Height property.
I have never seen that function be off by more that a few
twips. Pehaps you are not using the appropriate arguments??
I think your case only needs something like:
Me.yourline.Height = fTextHeight(yourtextbox)
--
Marsh
MVP [MS Access]
I have used fTextHeight function to calculate the height of the text box.
But in several cases, I find the calculation is false. Actually the text
box
contains 3 lines but the function returns 2.
"Marshall Barton" wrote
Since it is just a VBA module you import into your app, yes,
it will work in Access 97, 2000, 2002, 2003 (and probably
2007) on Windows 98, ME, 2000, XP (and probably Vista).
All those API calls only rely on the standard Windows
interface, so, no, you do not need any additional libraries.
Vensia wrote:
I have downloaded module modTextHeightWidth.
Can this module used for Access XP and Access 2003 ?
Do I need additional library ?
You can not get the can grow height of a text box in the
Format event no mstter how much you want to.
Have you tried setting the report's DrawWidth property?
Me.DrawWidth = 3
Me.Line ( . . .
If that can not be made to generate the desired effect, you
can calculate a close approximation of the text box's final
height by using the fTextWidthHeight function at
www.lebans.com You may have to make the text box and
detail section taller and use CanShrink, because the format
event can not make the line taller than the pregrow height
of the detail section (kind of a catch 22).
Vensia wrote:
I can't use line method because the border width of the line is not
same (unstable) if I use different printers to print the report.
So I decide to use line control and if I can know the height of the
can grow text box, then I can set the same height for the line control.
"Marshall Barton" wrote
Text boxes don't have "rows".
To draw a line the same height as a can grow text box, get
rid of the line control and use the Line method in the Print
event:
Me.Line (txtbox.Left,txtbox.Top) - Step(0,txtbox.Height)
The VBA Help file for the Line, Circle and PSet methods is
totally garbled, but the examples are valid.
Vensia wrote:
Actually I want to know how many rows the text box will expand.
I have a vertical line (line control) and I want the text box and
the line control has the same height.
Vensia wrote:
I have a text box in Detail section. The text box has property
Can Grow = Yes.
Is it possible to know the height of the text box in
Detail_Format event?
The answer is no, not until the Print event.
Vensia said:Stephen,
1 Point line width = ........ twips ??
Thx.
Stephen Lebans said:I did not realize that Vensia posted to the NG's as she made no reference to
this in her Email to me. I replied that the issue has to do with how Access
determines line breaks/hyphenation specifically for extended numerical
sequences.
As you suggested Marshall, the OP should add a fudge factor or better
yet,
return to the Line method as you outlined. The issue of ensuring that the
line thickness ise the same on all printers can be resolved.
The following is previous post of mine on this issue.
Hi Duane,
here is a previous post of mine to aid the OP in understanding this
issue.
He will have to use the Printer Object to check the current resolution of
the desired printer in order to set the DrawWidth property accurately.
' *** START ORIGINAL POST
Hi Matthias.
If I remember correctly the DrawWidth property is expressed in output
device Pixels. If Kathy desires a line of two points in width then you
will have to factor in the output device resolution. For example: 72
points per inch(Standard printer scale)
600 DPI output resolution
600/72 = 8 device pixels per printer point
So we would need to set the DrawWidth to 16 to get a 2 Point line width.
Obviously I've rounded 600/72 = 8.33 to 8 as the DrawWidth prop is an
Integer value. Also if accuracy is paramount remember that the output
resolution is never what is listed for the device. For example a laser
printer rated at 600DPI does not mean there are:
600 * 8.5 = 5100 pixels horizontally
600 * 11 = 6600 pixels vertically
on the output page. Most printing devices have a nonprint area, a border
that their print engine cannot image onto. This reduces the effective
output resolution by the amount of this "margin".
' *** END ORIGINAL POST
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
Marshall Barton said:For your purposes, you don't want the number of lines, you
want the Height (in twips). This is the value you want to
use to set the line control's Height property.
I have never seen that function be off by more that a few
twips. Pehaps you are not using the appropriate arguments??
I think your case only needs something like:
Me.yourline.Height = fTextHeight(yourtextbox)
--
Marsh
MVP [MS Access]
Vensia wrote:
I have used fTextHeight function to calculate the height of the text box.
But in several cases, I find the calculation is false. Actually the
text
box
contains 3 lines but the function returns 2.
"Marshall Barton" wrote
Since it is just a VBA module you import into your app, yes,
it will work in Access 97, 2000, 2002, 2003 (and probably
2007) on Windows 98, ME, 2000, XP (and probably Vista).
All those API calls only rely on the standard Windows
interface, so, no, you do not need any additional libraries.
Vensia wrote:
I have downloaded module modTextHeightWidth.
Can this module used for Access XP and Access 2003 ?
Do I need additional library ?
You can not get the can grow height of a text box in the
Format event no mstter how much you want to.
Have you tried setting the report's DrawWidth property?
Me.DrawWidth = 3
Me.Line ( . . .
If that can not be made to generate the desired effect, you
can calculate a close approximation of the text box's final
height by using the fTextWidthHeight function at
www.lebans.com You may have to make the text box and
detail section taller and use CanShrink, because the format
event can not make the line taller than the pregrow height
of the detail section (kind of a catch 22).
Vensia wrote:
I can't use line method because the border width of the line is not
same (unstable) if I use different printers to print the report.
So I decide to use line control and if I can know the height of the
can grow text box, then I can set the same height for the line control.
"Marshall Barton" wrote
Text boxes don't have "rows".
To draw a line the same height as a can grow text box, get
rid of the line control and use the Line method in the Print
event:
Me.Line (txtbox.Left,txtbox.Top) - Step(0,txtbox.Height)
The VBA Help file for the Line, Circle and PSet methods is
totally garbled, but the examples are valid.
Vensia wrote:
Actually I want to know how many rows the text box will
expand.
I have a vertical line (line control) and I want the text box and
the line control has the same height.
Vensia wrote:
I have a text box in Detail section. The text box has property
Can Grow = Yes.
Is it possible to know the height of the text box in
Detail_Format event?
The answer is no, not until the Print event.
Stephen Lebans said:Why do you need twips? As I stated in my last post, the DrawWidth property
is expressed in output Device Pixels which is dependant on the current
Resolution setting for the selected Printer Driver.
If there are
1440 Twips per Inch
and
72 Points per Inch
then there are
20 Twips per Point
But again, that is not relevant to this discussion. You really should follow
Marshall's advice to use the Line method of the report object and mine to
calculate the DrawWidth property. It's the only way to guarantee exact
results.
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
Vensia said:Stephen,
1 Point line width = ........ twips ??
Thx.
"Stephen Lebans"wrote in message news:[email protected]...referenceI did not realize that Vensia posted to the NG's as she made no
toboxthis in her Email to me. I replied that the issue has to do with how Access
determines line breaks/hyphenation specifically for extended numerical
sequences.
As you suggested Marshall, the OP should add a fudge factor or better
yet,
return to the Line method as you outlined. The issue of ensuring that the
line thickness ise the same on all printers can be resolved.
The following is previous post of mine on this issue.
Hi Duane,
here is a previous post of mine to aid the OP in understanding this
issue.
He will have to use the Printer Object to check the current resolution of
the desired printer in order to set the DrawWidth property accurately.
' *** START ORIGINAL POST
Hi Matthias.
If I remember correctly the DrawWidth property is expressed in output
device Pixels. If Kathy desires a line of two points in width then you
will have to factor in the output device resolution. For example: 72
points per inch(Standard printer scale)
600 DPI output resolution
600/72 = 8 device pixels per printer point
So we would need to set the DrawWidth to 16 to get a 2 Point line width.
Obviously I've rounded 600/72 = 8.33 to 8 as the DrawWidth prop is an
Integer value. Also if accuracy is paramount remember that the output
resolution is never what is listed for the device. For example a laser
printer rated at 600DPI does not mean there are:
600 * 8.5 = 5100 pixels horizontally
600 * 11 = 6600 pixels vertically
on the output page. Most printing devices have a nonprint area, a border
that their print engine cannot image onto. This reduces the effective
output resolution by the amount of this "margin".
' *** END ORIGINAL POST
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
For your purposes, you don't want the number of lines, you
want the Height (in twips). This is the value you want to
use to set the line control's Height property.
I have never seen that function be off by more that a few
twips. Pehaps you are not using the appropriate arguments??
I think your case only needs something like:
Me.yourline.Height = fTextHeight(yourtextbox)
--
Marsh
MVP [MS Access]
Vensia wrote:
I have used fTextHeight function to calculate the height of the text box.
But in several cases, I find the calculation is false. Actually the
text
box
contains 3 lines but the function returns 2.
"Marshall Barton" wrote
Since it is just a VBA module you import into your app, yes,
it will work in Access 97, 2000, 2002, 2003 (and probably
2007) on Windows 98, ME, 2000, XP (and probably Vista).
All those API calls only rely on the standard Windows
interface, so, no, you do not need any additional libraries.
Vensia wrote:
I have downloaded module modTextHeightWidth.
Can this module used for Access XP and Access 2003 ?
Do I need additional library ?
You can not get the can grow height of a text box in the
Format event no mstter how much you want to.
Have you tried setting the report's DrawWidth property?
Me.DrawWidth = 3
Me.Line ( . . .
If that can not be made to generate the desired effect, you
can calculate a close approximation of the text box's final
height by using the fTextWidthHeight function at
www.lebans.com You may have to make the text box and
detail section taller and use CanShrink, because the format
event can not make the line taller than the pregrow height
of the detail section (kind of a catch 22).
Vensia wrote:
I can't use line method because the border width of the line is not
same (unstable) if I use different printers to print the report.
So I decide to use line control and if I can know the height of the
can grow text box, then I can set the same height for the line control.
"Marshall Barton" wrote
Text boxes don't have "rows".
To draw a line the same height as a can grow text box, get
rid of the line control and use the Line method in the Print
event:
Me.Line (txtbox.Left,txtbox.Top) - Step(0,txtbox.Height)
The VBA Help file for the Line, Circle and PSet methods is
totally garbled, but the examples are valid.
Vensia wrote:
Actually I want to know how many rows the text box will
expand.
I have a vertical line (line control) and I want the text
andthe line control has the same height.
Vensia wrote:
I have a text box in Detail section. The text box has property
Can Grow = Yes.
Is it possible to know the height of the text box in
Detail_Format event?
The answer is no, not until the Print event.
Stephen said:Hey Marshall,
it's a hyphenation/line break issue specifically related to the embedded
dashes within the OP's field values.
Access is either using a different API call than me or applying
logic(internal fudge factor) I am not privy to in order to determine line
breaks. Specifically, when a string containing too many chars to fit on a
single line, without a readily identifiable line break position, must be
displayed/printed.
The OP emailed me a sample of their data and control setup info.
Field value : ABCDE-009-23423423423423423422 Text box width : 0.9625 inch
Text box height : 0.375 inch Font : Times New Roman 7
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.