suppress form feed on xprint close?

[John Tate]

I worked for hours getting a logo printed with text enclosed in box - looks great. I print the logo, then using dllprint, I want to print the rest of the invoice below the logo. I find that xprint close generates a form feed. I did not want to use xprint for the body of the invoice, since I already have it working.
Is there a way to suppress the form feed after the xprint close statement?

Other wise, I will have to knuckle down and write the body of the invoice using xprint!!

Any suggestions?

John Tate

[Michael Mattias]

Just reading the help file ....

Remarks XPRINT CLOSE detaches the printer from the current process, and allows printing to a HOST printer to begin. If XPRINT CLOSE is not executed, printed data may be lost.

. I'd have to say "no."

If there is no page feed, you can't start printing since Windows API printing is all page-oriented.

Maybe you could change to LPRINT in your application?

[John Tate]

Thanks, Michael.
I was afraid that was the problem. I understood I had to use xprint close, but was unaware that it automatically forced a form feed after printing. My logo and header are dutifully printed before any form feed. If I understand correctly, the form feed "flushes the print buffer", so to speak, and thus printing occurs.

One other question came up: the compiler allows me to use xprint with no parameters to move to the next line. Is it the height of the currently used font that tells it how much to move?

I have some more learing to do in using the xprint statements!

John Tate

[Gösta H. Lovgren-2]

John,

A thought occurs to me. Can you send your logo to the printer, then print the invoice (with whatever method, maybe shelling out to another program) BEFORE using Xprint Close.

Not very elegant, but if it works ....

One other question came up: the compiler allows me to use xprint with no parameters to move to the next line. Is it the height of the currently used font that tells it how much to move?

Yes, that's exactly what it does (at least as far as I have used it). I think Xprint Get Lines will tell how many printable lines are left on the page.

{A brief search later} I got a LOT of forum help with Xprint here (http://www.powerbasic.com/support/pb...ghlight=xprint). It might help to have a look at that John.

[quote]

================================================================
"For centuries, theologians have been explaining the unknowable
in terms of the-not-worth-knowing."
Henry Louis Mencken (1880-1956)
================================================================

[Michael Mattias]

then print the invoice (with whatever method, maybe shelling out to another program) BEFORE using Xprint Close.

I'd be real careful with that. Whatever handles XPRINT is obtaining won't be valid in another process unless the SHELL/CreateProcess or whatever is used is careful about handle inheritance and/or the child process does some handle duplication.

i.e., it's not quite that simple. (It's also the true beauty of Win/32.. terrific process isolation).


MCM

[Kev Peel]

Assuming DLLPRINT is an actual DLL, is it not possible for it to be passed the handle to the open printer? AFAIK, the windows print spooler will always eject the current page when the handle is closed, so it would need to be kept open for any additional printed output on the same page.

[Michael Mattias]

DLLPRINT is a third-party product, right? Is that doing 'pure' API printing (eg XPRINT) or is that passing the data directly to the printer (eg LPRINT)?

I don't know that you can mix and match API/Direct stuff at all.

Maybe it's time to just 'bite the bullet' and convert your invoice print to 100% XPRINT syntax so you'll have a more mantainable product. That is, your existing software may have reached that magic point in its life-cycle where additional modification/enhancement is going to cost you more (time) than just rewriting starting with a blank page. Plus you get the third-party library out of the mix.

I know emotional attachments accrue to code that has served you long and well, but life is for the living.

[Gösta H. Lovgren-2]

I'd be real careful with that.
MCM

Of course be careful.

Psewdo code:

Xprint Open, Attach, ....
XPrint Logo
 
Call Print_Invoice_Subroutine 'Where Invoice is printed (It_Works as long)
 
Xprint Close 'After return from Sub
 
If It_works then
   GoTo Work_On_New_Xprint_Invoice_Routine_When_You_Have_Time.
 Else
  GoTo Work_On_New_Xprint_Invoice_Routine_Right_Now.
End if

Obviously one can invent all kinds of possible disaster scenarios, But if it doesn't work, it isn't like the world is going to end just by trying it ....

[John Tate]

Well, I did bite the bullet and am rewriting the print routines. It was not so hard after all, once I got used to the get pos, set pos stuff.

I have a sub that prints the Logo, etc. It is called from the actual sub that does the printing of the statement, in this case.
I have a gosub pageup where the linecount is checked after each printing of the detail line items. When the linecount reaches 50, I do an xprint formfeed, then call the sub that prints the logo and start printing the remaining detail lines.
It all work fine, except it ejects a blank page between the printed report pages.
I was using the "xprint attach default" at the beginning of the sub that prints the logo and xprint close in the sub that prints the detail.
It seems that xprint attach also forces a formfeed. When the program sees the xprint attach default when the second page logo is printed, I get a form feed.
Where is the best place to apply the xprint attach statement? What is the scope of the xprint attach?

Thanks for all the comments and information.

John Tate

I have two different scales being used. That is my main problem. The scope of the xprint attach and xprint close covers all my subs and functions.
I am back to the drawing board and will figure it out.

[keith shelton]

Only use XPRINT ATTACH 1 time when you are printing an invoice. I have have a program which does the same thing. It reads the logo file and builds the entire invoice or estimate, be 1, 2 or 20 pages. After the pages are built then I do an XPRINT CLOSE to force the spooler to send it to the printer.
Of course because of the limitations of the POS system I have to work with, doesn't know what a windows, or usb printer are, I have to write the invoices to a text file and then read and print them from the PowerBasic program.
KS

[John Tate]

I finally am more proficient in use xprint. I have my program printing using the xprint commands.
It is easy to change point sizes, etc.
It was just a matter of sitting down and doing it.

One problem I had was: I was using the default scale in pixels in the logo print routine, then changing to a scale of (1,1)-(80,66). When I called the logo print for the second page, of course the scale was not in pixels any more. That did not work at all. I changed the logo print to the same scale I used in printing the detail, and all seems to be ok now.

I have used dllprint for many years, but I guess it is time to use the latest tools that PB has supplied me.

thanks again for all the comments

John Tate

[Michael Mattias]

>rewriting the print routines. It was not so hard after all,

You know, I find the same thing happens to me. I dread having to rewrite ten-year old stuff, but once I start on it I realize...

A. I code better and have more experience now than ten years ago, so it's easier - especially testing.
B. Knowing exactly what I have to support un-complicates the routines so much that I understand my dread was misplaced.

Right now I dread having to rewrite my ANSI ASC X12 EDI scanner routine. I want to make "one more enhancement" but as I was laying it out, I realized I'd have to insert code in four or five places, although deep down inside I know it should be doable by putting the relevant enhancement in one place.

It just may be that time.