This works fine aligning the figures for my financial reports (apolgies for
the double linespacing) BUT note the first imports line. Can anyone suggest
a modified coding that does not need this line(anticipating that support for
it may weell disappear...) it is the p.xxx lines that don't work. looks like
the others will.

Imports Microsoft.VisualBasic.PowerPacks.Printing.Compatibility.VB6

Imports System.Drawing

'Added a reference to: Microsoft.VisualBasic.PowerPacks.Vs

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

TestLabel.Text = "starting"

End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

PrintSample()

End Sub

Private Sub PrintSample()

'Dim col() As Integer

'ReDim col(0 To 3)' if presetting columns

' col(0) = 20... etc

Dim p As New printer

p.PrintAction = Printing.PrintAction.PrintToPrinter 'in System.Drawing
namespace

p.ScaleMode = vbMillimeters ' changed from twips

p.Orientation = vbPRORPortrait ' orientation

p.PaperSize = vbPRPSA4 ' paper size

p.Font = New Font("Arial", 12, FontStyle.Regular)

Dim PrintDialog1 As New PrintDialog() 'just shows dialog and doesn't use it

PrintDialog1.ShowDialog() 'more coding to do to read the ouput from the
dialog

Me.Refresh()

Dim AlanVariable As Decimal = 1234.56 ' experiment

Dim AnotherVariable As Decimal = 45.1 'experiment

Dim ThirdVariable As Decimal = 651.11 ' experiment

Dim FourthVariable As Decimal = 9 ' experiment

'the format produces 2 decimal points

'the TextWidth allows alignment (right) decimal

'the decimals line up perfectly here despite '1', '0' and a proportional
font

p.CurrentY = 80

p.CurrentX = 100 - p.TextWidth(Format(AnotherVariable, "#,###0.00"))

p.Write(Format(AnotherVariable, "#,###0.00"))

p.CurrentY = 85

p.CurrentX = 100 - p.TextWidth(Format(AlanVariable, "#,###0.00"))

p.Write(Format(AlanVariable, "#,###0.00"))

p.CurrentY = 90

p.CurrentX = 100 - p.TextWidth(Format(ThirdVariable, "#,###0.00"))

p.Write(Format(ThirdVariable, "#,###0.00"))

p.CurrentY = 95

p.CurrentX = 100 - p.TextWidth(Format(FourthVariable, "#,###0.00"))

p.Write(Format(FourthVariable, "#,###0.00"))

'p.NewPage() if required (could increment a Line counter)


p.EndDoc()

End Sub

End Class

StrandElectric expressed precisely :
> This works fine aligning the figures for my financial reports (apolgies for
> the double linespacing) BUT note the first imports line. Can anyone suggest a
> modified coding that does not need this line(anticipating that support for it
> may weell disappear...) it is the p.xxx lines that don't work. looks like the
> others will.


Yeah, learn to use the PrintDocument class....

--
Tom Shelton

"StrandElectric" <Strand@dummyspit> wrote in message
news:4d410db0$(E-Mail Removed)...
> (apolgies for the double linespacing)

It's because the code is copied in Rich Text format. Try pasting it into
Notepad, and copy that.

StrandElectric wrote:
> This works fine aligning the figures for my financial reports (apolgies for
> the double linespacing) BUT note the first imports line. Can anyone suggest
> a modified coding that does not need this line(anticipating that support for
> it may weell disappear...) it is the p.xxx lines that don't work. looks like
> the others will.
>
> Imports Microsoft.VisualBasic.PowerPacks.Printing.Compatibility.VB6

The reason the above line is required is so that you can write
Dim p As New Printer
instead of
Dim p As New
Microsoft.VisualBasic.PowerPacks.Printing.Compatibility.VB6.Printer

You can still use the same code in .NET 4 (ie VS2010).

How do you know the above won't work in .NET 5 and beyond?

The only (current) cause for concern is if you want to use Linux - as
Mono probably doesn't contain the equivalent of the above Microsoft
assembly.

And, if you REALLY want your decimal points to line up properly, then
you should use a routine like...

Public Sub PrintAmount(ByVal p As Printer, ByVal right As Double, ByVal
amount As Double)
p.CurrentX = right - p.TextWidth(Format(amount, "#,###,###,##0.99"))
p.Write(Format(amount, "#,###,###,##0.00"))
End Sub

The ".99" above will eliminate the slight variation in alignment of the
decimal points when using a proportional font.

"Tom Shelton" <(E-Mail Removed)> wrote in message
news:ihr328$6i2$(E-Mail Removed)...
> StrandElectric expressed precisely :
>> This works fine aligning the figures for my financial reports (apolgies
>> for the double linespacing) BUT note the first imports line. Can anyone
>> suggest a modified coding that does not need this line(anticipating that
>> support for it may weell disappear...) it is the p.xxx lines that don't
>> work. looks like the others will.
>
>
> Yeah, learn to use the PrintDocument class....
>
> --
> Tom Shelton
>
Ready and willing, but where and how, given the 'documentation'?

"Nobody" <(E-Mail Removed)> wrote in message
news:ihr3fb$a93$(E-Mail Removed)...
> "StrandElectric" <Strand@dummyspit> wrote in message
> news:4d410db0$(E-Mail Removed)...
>> (apolgies for the double linespacing)
>
> It's because the code is copied in Rich Text format. Try pasting it into
> Notepad, and copy that.
>
Thanks. I'll try that..

"Jason Keats" <(E-Mail Removed)> wrote in message
newsNa0p.8963$(E-Mail Removed)...
> StrandElectric wrote:
>> This works fine aligning the figures for my financial reports (apolgies
>> for
>> the double linespacing) BUT note the first imports line. Can anyone
>> suggest
>> a modified coding that does not need this line(anticipating that support
>> for
>> it may weell disappear...) it is the p.xxx lines that don't work. looks
>> like
>> the others will.
>>
>> Imports Microsoft.VisualBasic.PowerPacks.Printing.Compatibility.VB6
>
> The reason the above line is required is so that you can write
> Dim p As New Printer
> instead of
> Dim p As New
> Microsoft.VisualBasic.PowerPacks.Printing.Compatibility.VB6.Printer
>
> You can still use the same code in .NET 4 (ie VS2010).
>
> How do you know the above won't work in .NET 5 and beyond?
>
> The only (current) cause for concern is if you want to use Linux - as Mono
> probably doesn't contain the equivalent of the above Microsoft assembly.
>
> And, if you REALLY want your decimal points to line up properly, then you
> should use a routine like...
>
> Public Sub PrintAmount(ByVal p As Printer, ByVal right As Double, ByVal
> amount As Double)
> p.CurrentX = right - p.TextWidth(Format(amount, "#,###,###,##0.99"))
> p.Write(Format(amount, "#,###,###,##0.00"))
> End Sub
>
> The ".99" above will eliminate the slight variation in alignment of the
> decimal points when using a proportional font.

Thanks Jason, but they already *do* line up perfectly. I'm looking at them
now. Could it be that although the font is proportional, the figues in it
are monospaced precisely to avoid decimal lineup problems. Ater all 1 and 0
must be the ultimate test? Or am I off the beam here?

StrandElectric wrote:
>>
>> And, if you REALLY want your decimal points to line up properly, then you
>> should use a routine like...
>>
>> Public Sub PrintAmount(ByVal p As Printer, ByVal right As Double, ByVal
>> amount As Double)
>> p.CurrentX = right - p.TextWidth(Format(amount, "#,###,###,##0.99"))
>> p.Write(Format(amount, "#,###,###,##0.00"))
>> End Sub
>>
>> The ".99" above will eliminate the slight variation in alignment of the
>> decimal points when using a proportional font.
>
> Thanks Jason, but they already *do* line up perfectly. I'm looking at them
> now. Could it be that although the font is proportional, the figues in it
> are monospaced precisely to avoid decimal lineup problems. Ater all 1 and 0
> must be the ultimate test? Or am I off the beam here?

No, they don't line up perfectly. I agree that your old eyes probably
can't tell the difference, but the horizontal position of the decimal
point varies by as much as the width of the decimal point using your
code! :-)

Am 27.01.2011 10:20, schrieb Jason Keats:
> StrandElectric wrote:
>> This works fine aligning the figures for my financial reports (apolgies for
>> the double linespacing) BUT note the first imports line. Can anyone suggest
>> a modified coding that does not need this line(anticipating that support for
>> it may weell disappear...) it is the p.xxx lines that don't work. looks like
>> the others will.
>>
>> Imports Microsoft.VisualBasic.PowerPacks.Printing.Compatibility.VB6
>
> The reason the above line is required is so that you can write
> Dim p As New Printer
> instead of
> Dim p As New
> Microsoft.VisualBasic.PowerPacks.Printing.Compatibility.VB6.Printer
>
> You can still use the same code in .NET 4 (ie VS2010).
>
> How do you know the above won't work in .NET 5 and beyond?
>
> The only (current) cause for concern is if you want to use Linux - as
> Mono probably doesn't contain the equivalent of the above Microsoft
> assembly.
>
> And, if you REALLY want your decimal points to line up properly, then
> you should use a routine like...
>
> Public Sub PrintAmount(ByVal p As Printer, ByVal right As Double, ByVal
> amount As Double)
> p.CurrentX = right - p.TextWidth(Format(amount, "#,###,###,##0.99"))
> p.Write(Format(amount, "#,###,###,##0.00"))
> End Sub
>
> The ".99" above will eliminate the slight variation in alignment of the
> decimal points when using a proportional font.

First, there is no difference between "#,###,###,##0.00" and "#,##0.00"
because the "#" are not placeholders for leading blanks.

Second, the "99" doesn't work for me.
Format(1.23, "#,###,##0.99")
returns
"123"
without a decimal point.

Third, p.CurrentX is of type Single only. A double value doesn't fit. ;-)

Fourth, I'd prefer passing "amount As DECIMAL" instead in order to make
the _caller_ think about printing a decimal value. (even though it doesn't
prevent passing a value with more than two digits after the ".") However,
this is not so important.

5th, to me it is a contradiction if you intentinally write code to keep the
"." in line also with proportional fonts on one side, but on the other side,
you pass the 'right' value to the method. I mean, the 'right' value is the
one that is _not_ equal with proportional fonts while lining up the ".".
Hence I'd either pass the location of the ".", or use a monospace font.


So, my version is:

Public Sub PrintAmount(ByVal p As Printer, ByVal DecimalPosition As Single, ByVal amount As Decimal)

Const fmt1 As String = "#,##0"
Const fmt2 As String = fmt1 & ".00"

p.CurrentX = DecimalPosition - p.TextWidth(Format(Math.Truncate(amount), fmt1))
p.Print(Format(amount, fmt2))

End Sub


BTW, luckily I have a PDF printer. Otherwise I'd have to waste paper for this
example because I'm not able to use a Graphics object drawing on a Form
or Bitmap. (Your code is absolutely ok! I'm only mentioning the downside
of using the old Printer object.)

BTW #2, I've written a small program looking for the font with the maximum
deviation between the size of the numbers. The font found was "Nyala", giving
a maximum deviation of 1.46 between the "1" and the "6". Using my code above,
the result is: http://www.abload.de/image.php?img=d...enyalakx9n.png

I think this is more convincing than Arial. ;-)



--
Armin

"Jason Keats" <(E-Mail Removed)> wrote in message
news:K3e0p.8796$(E-Mail Removed)...
> StrandElectric wrote:
>>>
>>> And, if you REALLY want your decimal points to line up properly, then
>>> you
>>> should use a routine like...
>>>
>>> Public Sub PrintAmount(ByVal p As Printer, ByVal right As Double, ByVal
>>> amount As Double)
>>> p.CurrentX = right - p.TextWidth(Format(amount,
>>> "#,###,###,##0.99"))
>>> p.Write(Format(amount, "#,###,###,##0.00"))
>>> End Sub
>>>
>>> The ".99" above will eliminate the slight variation in alignment of the
>>> decimal points when using a proportional font.
>>
>> Thanks Jason, but they already *do* line up perfectly. I'm looking at
>> them
>> now. Could it be that although the font is proportional, the figues in it
>> are monospaced precisely to avoid decimal lineup problems. Ater all 1
>> and 0
>> must be the ultimate test? Or am I off the beam here?
>
> No, they don't line up perfectly. I agree that your old eyes probably
> can't tell the difference, but the horizontal position of the decimal
> point varies by as much as the width of the decimal point using your code!
> :-)

Quaver! I've got out my micrometer and it looks OK here. Maybe it's my 'old
eyes' mate!