Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
@...SAY form tearoff or top of form wrong after printing
Message
From
05/08/2003 17:31:29
 
 
To
05/08/2003 17:19:07
General information
Forum:
Visual FoxPro
Category:
Reports & Report designer
Miscellaneous
Thread ID:
00816639
Message ID:
00817093
Views:
25
For once, I won't snip the batch. See your response at the bottom - what you are saying can't be so, or 3 pages would have been fed - correct? 66 line feeds, 1 form feed. Are you getting any extraneous data on the printouts (primarily at the top)? Improper ESC sequences can sometimes manifest itself this way and could be the source of your extra lines. WHAT ARE YOU DOING DIFFERENT IN THESE REPORTS? Are your control sequences in strict adherence with the OKI IBM emulation listing? Let me see your initialization code for each of these reports and maybe I can see something...

>I have now determined by testing repeatedly that any command sequence sent to the printer using ??? also issues a line feed. If I print the report without any codes being sent, it works fine, but for every ??? it feeds that many lines...this is a problem because I need to send condensed print commands, etc for the other two that are doing this...
>
>>Well, it doesn't work for me here - ???Chr(27)+CHR(64) does something, but does not return the printer to the power on state. Loose the reset as a test. Why this would change from report to report escapes me, but...
>>
>>>Yes, the printer is always in IBM PPR mode and I've verified that. chr(27) is the reset code. We store special codes for a printer (like page length, lines per inch, font size, etc in vars that are sent to the printer before and after a printjob such as:
>>>
>>>
>>>???opt      && this could be chr(15)
>>>@1,1 say "Line 1"
>>>EJECT
>>>???resetopt && this could be chr(18) or just chr(27)
>>>*Standard end of print jobs commands go next such as the set printer to...
>>>
>>>
>>>Typically the opt and resetopt vars are actually empty so it is sending nothing. For some reason, at times, sending nothing causes the line feeds, hmmmmm, got me thinking of an obvious test....
>>>
>>>
>>>>And what emulation are you currently running? You are sending a bare ESC (CHR(27)) as a Reset?
>>>>
>>>>>Running your code, the printhead ends up exactly where it should be, at the form tearoff. It appears to occur after a reset code is sent to the printer, but only on those 3 forms and the same reset code (27) is sent after all printjobs...
>>>>>
Previous
Reply
Map
View

Click here to load this message in the networking platform