Announcement

**Mike Luther** · 23 Feb 2003, 11:45 PM

As far as I know, form size to a pure DOS program and PB 3.5 by itself
is a printer specific issue for form size. I'm sure there is a utility
tool set out there for use in BASIC which knows about most of the pile
of printers out there. But long ago for my use I made my own printer
setup library. You take the book for a given printer or group of
printers, such as the Epson series. You carefully look up the ESCape
code sequences for the standard commands like font size, line spacing,
and so on. Then you have to deliberately, one way or another cooperate
with that printer or family group of printers and do it the hard way,
as far as I know.

When you need a 7 inch form size for the Epson family of this and
that, you have to tell it font, line spacing, and form length, all as
a combination of CHR$(27) 'escape' codes plus other characters. In fact,
I actually have a whole library of standardized SUB's for doing just
this, the guts of which are changed in my master facility control
menu where you choose your printer from any of the supported ones.

The printer, reset to this .. cooperates.

Yes, modern operating systems, such as OS/2, WIN whatever, do much of the
work of this for you. With them we set the system printer, fonts, character
points, lines per inch or whatever it is called, and the system has the
capability for the printer driver to do our bidding. For example, in OS/2,
the Epson Omni Driver covers virtually all of the entire Epson series in one
fell swoop. And yes, with such a printer chosen for the system, we can then
go and get it to do whatever it will do for the whole system, graphics the works.

But when it's just (back?) to DOS, all I've ever done is drag out the book and
initialize it to what is wanted and away we go.

Controversy below... Just a suggestion for what it may be worth.

There is one thing I might note which will start a possible discourse here that
I have watched at least with IBM's DOS and PB 3.5 in VERY large programs. It's
not admitted by some folks. I can't help that. Nor can I demonstrate it to
anyone with the complexity and compiler use unless they are willing to use OS/2
for a platform, although it is *NOT* OS/2 specific come time to run the program
under pure DOS, or WIN in DOS, whatever. If I am going to use the line printer in
a program, at the top of the program I've discovered it can save me hours of time
chasing strange errors that simply can't be what they are, if I take a couple extra
steps.

Right after I dimension all my variables, initialize them, craft my UDT's get my
INCLUDE files and libraries all set up and have my SUBS all defined, I personally
have stopped a very significant issue of never found why program instability with
one stunt that makes no sense to me at all.

I use a printer LINE WIDTH statement for the maximum number of characters to be
used for the printer considering the font size to be used. But there is more to
the story, at least here. Just before I actually begin work with the program
itself, in every single one of them, I have found the following helps stop hours
and hours of wasted time for me in chasing program instability at run time for
variables that simply don't have the right value in nested calls, UDT's and so
on. And no, when it starts up, you can't add any way to pointer the thing without
simply moving the error somewhere else to even trace it. But I have noticed that
this is one of the tricks which somehow stabilizes whatever "it" is that does this:

Code:

MEMPACK
 ' ---
DEF SEG '                                   Reset before init
WIDTH LPRINT 132 '                          Set lprint max
DEF SEG '                                   Reset after init

This is not just an OS/2 issue at run time for execution collapse and fall into the
"Unhandled . But the programs are large enough at this
point that demonstarting anything simply can't be done without it. I've gone
nuts chasing why, for example, an integer will have the correct value just
before being passed to a deeply nested SUB call in very large and complex
programs, for example. yet either PUBLIC or carried in as a passed parameter,
the value of the variable will *NOT* be correct when the SUB is executed, leading
to hours and hours of misery chasing this thing.

I've discovered that I can work the thing with the DEF SEG statements up, up, up
toward the beginning of the program, without breaking the false error. Then, in
SOME of these merciless error deals, the instant I use the DEF SEG trick above ..
POOF! The whole error deal vanishes. If I take out either of them, I am right
back in the false error soup mess again. Which also dissapears if I add even
one line of program code with any other new variable in it in any way to attempt
to pointer it or trace it further.

THe program will fail in DOS, not with DOS in WIN, or OS/2 DOS-VDM's, or fail in
WIN-DOS, not in DOS or OS/2, or fail in OS/2 and not in either DOS or WIN-DOS. If
it fails in OS/2 .. that operating system is good enough to not totally lock a box
up and give us:

SYS3170: A program in this session encountered a problem and
cannot continue.

EXPLANATION: The process was ended because the program generated
an unhandled fatal user (non-system) exception through DosRaiseException.

ACTION: If you purchased this program, contact the supplier of the
program. If you are the developer of this program, refer to the
information in the register.

And during the hours and hours of trying to trace things, the compiler
will often come apart in the same issue .. then as you add the below,
POOF, it's gone. This is one of the whatever and why I don't care but it
works and I can forget about this part of whatever.

Please .. don't ask me to furnish examples, with 25000 line plus source code,
close to 2000 variables and a dozen units, plus many segments. And yes, nobody
can fix what they can't see. So let's leave it at that.

I've cut my misery by a significant number of hours by doing the above and,
as far as I know, it can't hurt anything. Nor do I claim to know why the errors
go away for me when I do this. But it works for me and is trivial to do. So
it's become a standard feature here and I bless the day I discovered the
kludge, for whatever reason it works.

Just a suggestion.

------------------
Mike Luther
[email protected]

**Michael Mattias** · 24 Feb 2003, 05:56 AM

"Traditionally" forms are printed on line printers (page printers are different) by counting the number of lines printed on the page so far..

Code:

   DO
      CreateReportLine (TheTextLine$)
      IF LinesPrintedThisPage >= MaxLinesPerPage THEN
         PRINT #hPrinter, CHR$(12);   ' form feed
         LinesPrintedThisPage = 0
      END IF   
      PRINT #hPrinter, TheTextLine$
      INCR LinesPrintedThisPage
   LOOP

MCM

Announcement

Form size in PB3.5

Form size in PB3.5

Comment

Comment