Windows Printing

J. Landman Gay jacque at hyperactivesw.com
Sun Aug 29 13:33:30 EDT 2004


David, thanks for the very helpful and informative post. It sounds like 
you have addressed the same problems I'm having. I do toggle the 
formatForPrinting as you describe, but I did not do the close-and-open 
business before the actual printing. I may try that. Maybe it isn't so 
superstitious after all. I have also had the unexplained 
termination/crashing problems you describe.

With Pierre's generous help, I've found that for this particular print 
job I may not need to set the formatForPrinting at all; leaving it false 
appears to work okay. This is because the columns I am printing are 
gennerously wide and there is no text wrap, so it doesn't matter whether 
we are using the printer fonts or not. To keep things simple, I may just 
leave out the formatForPrinting setting entirely.

It seems to me this printing business could be improved, especially on 
Windows machines. Thanks again for your help. I will definitely save 
your scripts for reference.


On 8/29/04 8:18 AM, depstein at att.net wrote:

> Jacqueline Landman Gay wrote of Windows printing problems:
> 
> 
>>The printing stack has its 
>>formatForPrinting set to true.
>>
>>My script fills both fields, prints the card, prints a break, then 
>>repeats until the data is gone.
> 
> 
> The documentation for "formatForPrinting" warns us never to edit a field with its formatForPrinting set to true.  A script that "fills both fields" is editing a field with formatForPrinting set to true.
> 
> I experienced the symptoms you described, plus the program frequently simply quitting, while trying to print in Windows using Metacard 2.5.  I believe I have now remedied the problem by having my script repeatedly call this command:
> 
> on ffp whether
>   set the formatForPrinting of stack <myPrintLayoutStack> to whether
> end ffp
> 
> FormatForPrinting needs to be FALSE before the script changes a field's content (including filling it in the first place), and it needs to be TRUE before you try to determine what changes are needed based on how the text fits in the space available (and before you print).  For example, here's handler I use to determine what text doesn't fit in a field and needs to be moved to the next column or page:
> 
> function extraText f -- returns the htmlText that overflows size of fld f
>   ffp true -- SO THAT FORMATTEDHEIGHT WILL BE PROPERLY CALCULATED
>   repeat with c = 1 to length(fld f)
>     if the formattedHeight of char 1 to c of fld f > the height of fld f then
>       put the htmlText of char c to -1 of fld f into myHtml
>       ffp false -- BECAUSE I'M ABOUT THE CHANGE THE CONTENT OF FLD F
>       delete char c to -1 of fld f
>       return myHtml
>     end if
>   end repeat
>   ffp false -- READY FOR FURTHER EDITS OF FLD F
>   return empty
> end extraText
> 
> Just before you print, set ffp true again.  Somewhere (but not in Rev docs, I think) I read advice suggesting a further precaution:  close and open the stack and then set formatForPrinting to true.  So I added this just before printing:
> 
>     set the destroyStack of stack <myPrintLayoutStack> to true
>     save stack <myPrintLayoutStack>
>     close stack <myPrintLayoutStack>
>     open stack <myPrintLayoutStack>
>     ffp true
> 
> This last bit seems a littler superstitious, but since I made these fixes a couple of weeks ago my Windows printing has worked properly.
> 
> I hope this will help with your difficulties.
> 
> David Epstein
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 
> 


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com


More information about the use-livecode mailing list