Aligment works but...

[StrandElectric]

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

 

[Tom Shelton]

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....

 

[Nobody]

(apolgies for the double linespacing)

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

 

[Jason Keats]

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.

 

[StrandElectric]

StrandElectric expressed precisely :


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

Ready and willing, but where and how, given the 'documentation'?

 

[StrandElectric]

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

Thanks. I'll try that..

 

[StrandElectric]

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?

 

[Jason Keats]

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!

 

[Armin Zingler]

Am 27.01.2011 10:20, schrieb Jason Keats:

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=decimalsinlinenyalakx9n.png

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

 

[StrandElectric]

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!

 

[Jason Keats]

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

Thanks, Armin - I learned a couple of things from your analysis of my
code. I obviously had a couple of misconceptions about how things were
working. Your version of the routine looks a lot nicer.

Now all we have to do is get StrandElectric to run his code using the
Nyala font - so that he can see what we're talking about.

BTW, no trees were killed in the development of my code, either. I too
use a PDF printer.

 

[StrandElectric]

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!

Just tested it again. Perfect alignment!

 

[Jason Keats]

Just tested it again. Perfect alignment!

It depends on the font you use. Try Nyala to see a big difference.

 

[StrandElectric]

Thanks, Armin - I learned a couple of things from your analysis of my
code. I obviously had a couple of misconceptions about how things were
working. Your version of the routine looks a lot nicer.

Now all we have to do is get StrandElectric to run his code using the
Nyala font - so that he can see what we're talking about.

Sorry lads! I really appreciate all your efforts, but I repeat, having the
sample right in front of me, plus a real-life financial report from my vb6
app, the decimal points DO line up*, so I see no point in trying another
font! (I fully understand you rlogicbut...) *If there is any discrepancy
it is less then 0.25 of a mm, which is the limit of the measuring
instruments I'm using for the task. That's quite close enough for the real
world. It wouldn't be if you were fitting (in metalwork) but it's enough not
to be displeasing to the eye and certainly good enough not to be distracting
when looking at financial reports.

 

[StrandElectric]

It depends on the font you use. Try Nyala to see a big difference.

Tell you what! I will and will report back!

 

[Jason Keats]

Tell you what! I will and will report back!

Don't bother. I've done it for you.

Your code and Armin's code printed the following.

http://member.melbpc.org.au/~jkeats/files/align.png

Can you see the difference?

 

[StrandElectric]

It depends on the font you use. Try Nyala to see a big difference.

Well Jason, in a real life, I do see a difference but it is almost
imperceptible. It is not what I call big.

My major accounting suite (using my vb6 code and Arial) is in daily use and
turns out ad hoc, quarterly and annual reports. They look fine and are
accepted by the authorities.

 

[StrandElectric]

Don't bother. I've done it for you.

Your code and Armin's code printed the following.

http://member.melbpc.org.au/~jkeats/files/align.png

Can you see the difference?

Hi Jason. Certainly can! But what I am printing here is nothing like that.
I wonder if that is due to the fact that I usually have figures with no more
than 5 figures before the decimal point.

 

[StrandElectric]

Don't bother. I've done it for you.

Your code and Armin's code printed the following.

http://member.melbpc.org.au/~jkeats/files/align.png

Can you see the difference?

The difference in those is obvious but that's not Arial is it?

 

[Armin Zingler]

Am 28.01.2011 08:59, schrieb Jason Keats:

Thanks, Armin - I learned a couple of things from your analysis of my
code. I obviously had a couple of misconceptions about how things were
working. Your version of the routine looks a lot nicer.

I hope this isn't full of irony. Sorry, it wasn't meant to be a
find-as-many-errors-as-possible competition. (even if it looked as if
afterwards). I was only trying something here, one thing lead to the
other there, etc. I hope you really don't took it the wrong way.

Now all we have to do is get StrandElectric to run his code using the
Nyala font - so that he can see what we're talking about.

BTW, no trees were killed in the development of my code, either. I too
use a PDF printer.

:-D