[quoted text, click to view] "al jones" <alfredmjones@shotmail.com> wrote in message
news:q7u3ekr1t4lq.9adjqzbd0bxp.dlg@40tude.net...
<<>>
>> What question are you asking which gets the same answer you don't
>> understand?
>
> It's the same old 'I've gotten some information fron a form and I'm trying
> to print lines of text from within a <literal> mess of calculations. It's
> a matter of print a line or three, perform more calcs and print a few more
> lines of text. (I realilze GDI+ and draw - not print a line). With the
> exception of one from Allen everything I get back is how to print a:
> 1) rtf document
> 2) block of text encoded in the program
> 3) big X on a page
> 4) pretty picture
> I can see the call to draw the line of text and increment the pixel
> position for the next line in all of the examples (except the x of
> course),
> but fail to see how to extract just that portion of the sub and
> encapsulate
> the remaining calcs / prints within the open doc / close doc structure.
>
> The one from Allen was interesting in that goes direct to the printer (it
> says) but again, it's printing a graphic and I can't convince my
> BrotherPrinter that it's a HP (control codes, etc) and don't really want
> to
> try that route.
>
> I'm pushing 60, programmed in COBOL, (GW)BASIC(A), Fortran, etc from my
> 20's up till about 10 years ago when I took a break... and cannot get my
> head around how to do things 'the VB way' (or is that 'the VISUAL way'??).
It's the object orientated way mate.
Can't say as I've ever tried to do what you're doing so I don't have
anything ready to roll.
In DotNet everything is an object.
Even what you might think of as a variable.
So you declare something. stick a value in it and can convert it using
methods of that variable.
whatever.tostring
That's of weird if you think in cobol terms.
What you're looking for is some sort of file object.
You got to open it, chances are open is some sort of method.
You'll then use methods of this to bung data into the file.
All output I ever did to a printer was from crystal reports.
Seeing as that handles the actual writing to the printer that bit 's easy.
You could write the data to a table, base a report on that table and it'd do
the biz.
Bit long winded though.
Unless - and this is why I mention it - you write the guff away to a
database anyhow.
In which case a form write the data away and a crystal report prints it
starts to look a lot more logical.
Otherwise I think I'd write the stuff to a flat file.
Then chuck the flat file at the printer, and I guess you already have some
info on how to do that.
