Yes it does. That is what we do, however if you have a temporary created window you have to allow to release it in all error traps if something happens during printing. Additionally, there are times when for some reason the printer font will take affect in the _screen so we have to reset the screen font back to the correct size after printing as a precaution for this. That is why the need for setting _screen.fontname and _screen.fontsize. Locking the screen works but when you unlock the screen it flashes and the @...says that were on the screen are gone so you have to restore the screen from a saved screen which is not reliable either. All appear to work somewhat, but none have tested to be reliable all the time. A myriad of minor issues I'm afraid that are major for the user...
>Trace,
>
>< UPDATE > nevermind, it looks like it uses _screen colors....
>
>I'm not terribly familiar with changing colors the way you are doing it...can you have two windows with different colors in them? (I assume yes). Does printing to the printer use the colors of the currently selected window?
>
>>Hi Steve,
>>
>>If your screen colors are white on blue and you print a report, chances are you do not want the printer to attempt to print white on blue, but black on white as is normal. There must be a way to ignore it so the printer prints black on white without using the current screen colors to print. MSFT lists it as a bug too...
>>
>>
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B154170
.·*´¨)
.·`TCH
(..·*
010000110101001101101000011000010111001001110000010011110111001001000010011101010111001101110100
"When the debate is lost, slander becomes the tool of the loser." - Socrates
Vita contingit, Vive cum eo. (Life Happens, Live With it.)
"Life is not measured by the number of breaths we take, but by the moments that take our breath away." -- author unknown
"De omnibus dubitandum"