No announcement yet.

Form size in PB3.5

  • Filter
  • Time
  • Show
Clear All
new posts

  • Form size in PB3.5

    Is there a way of setting up a form size in PB3.5. Need to print a 7" form


  • #2
    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

    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:

     ' ---
    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]
    Mike Luther
    [email protected]


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

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

      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]