Login  | |
|
 |
RE: printing without formfeed - 12/14/2006 5:01:09 AM
|
|
 |
|
| |
ebgreen
Posts: 4613
Score: 31
Joined: 7/12/2005
Status: offline
|
quote:
but what can i do to avoid this?
You would have to take it up with the author of the ActiveX component.
quote:
is there anybody who have a list of the printer objects?
You can get a list of the printers installed on the machine via WMI, but I'm not sure that is what you are asking for.
quote:
or, perhaps, can i find this in the vb.net express edition help?
If you want to do this in VB.Net instead of VBScript (the two are not the same at all) then you are probably right.
You may try posting your question in German. I believe one of our best members also speaks German.
_____________________________
"... when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick
Goog places to start:http://www.visualbasicscript.com/m_24727/tm.htm
http://www.visualbasicscript.com/m_47117/tm.htm
|
|
| |
|
|
|
|
RE: printing without formfeed - 12/16/2006 7:58:23 AM
|
|
|
|
| |
ehvbs
Posts: 2114
Score: 50
Joined: 6/22/2005
From: Germany
Status: offline
|
Hi KALEL,
thank you for testing my script even before I could explain it! I really feel
that's a sign of confidence from your side.
There are three aspects that need further elaboration.
The first concerns how to use the script as it is. It doesn't really matter
whether you saved the code as .HTML (as I assume) or as .HTA (as I intended,
because .HTAs avoid security issues .HTMLs are prone to rise - e.g. silently
not creating ActiveX components). As you obviously could load the script and
use the printer, we are in business/luck.
To be absolutly sure: If you press the "Print" button once, you should get
either
immediate output of two lines of text on a lineprinter
no visible reaction on a page printer
but no formfeed whatsoever. Pressing the button again should add text to the
same page, but definitely no formfeed. As soon as you close the document, a
formfeed should be sent. My prediction is based on this law about the behaviour
of a decent printer object:
A formfeed should be sent, if and only if
(a) the user asks for it (.EndPage, .EndDoc, printer control code)
(b) the printer object is destructed
(c) the - suitably defined - page is full
Your "when i press the print-b. i get a normaly print with formfeed." can
be understood as "each time the button is pressed/text is printed there immediately
follows a formfeed". If that's the case, my prediction is falsified.
To come to second aspect: How the script works (or should work). Let's tackle the
4 points raised (a, b, c, formfeed on each button press) in order:
The script handles (a) in a cavalier way: There is no button/Sub to send
.EndPage or .EndDoc to the printer, so we can be sure, that no formfeed
is caused by (a).
The (b) case is handled in the script by declaring the variables used to
hold the objects at the global (out of Functions or Subs) level of the
script:
' Global vars
Dim PrinterObj
Dim Printer
and intializing them with:
Set PrinterObj = CreateObject( "avbScriptPrinter.PrinterObj" )
Set Printer = PrinterObj.Printer
This way they will 'live' as long as the script stays in memory, the
browser will destruct them just before he?/she?/it? terminates. Each time
the
Sub PrintIt()
With Printer
.ScaleMode = 7 ' Zentimeter
.CurrentX = 5
.CurrentY = 10
PrinterObj.PrintText "Hallo!"
.CurrentX = 5
PrinterObj.PrintText "Ist da jemand?"
End With
End Sub
is called, it will use the same objects. Contrast this with a Sub like
this:
Sub PrintIt_destructive()
Dim PrinterObjLocal : Set PrinterObjLocal = CreateObject( "avbScriptPrinter.PrinterObj" )
Dim PrinterLocal : Set PrinterLocal = PrinterObjLocal.Printer
With PrinterLocal
.ScaleMode = 7 ' Zentimeter
.CurrentX = 5
.CurrentY = 10
PrinterObjLocal.PrintText "Hallo!"
.CurrentX = 5
PrinterObjLocal.PrintText "Ist da jemand?"
End With
End Sub
Those local objects will go out of scope and be destroyed at the end of (each
call of) the Sub. Such a Sub should lead to the behaviour you complained
about in your first posting: Just printing same text will cause a formfeed
(by destruction).
At a first glance (c) can be done with in a short way like a: As long as
you don't press the Print button as often as to fill a whole page there
shouldn't be any formfeed from the script.
But if my prediction is wrong (each press causes output and formfeed; the fourth
case at last) than we at least know: The Sub PrintIt() must be the culprit, it
must - somehow - 'flood the page'.
While setting .CurrentX = 5 looks innocent enough, setting the .ScaleMode
(to the same value) each time you print a line, may cause a very dump printer
driver to give up on this page and start a new one with a (presumably) new
.ScaleMode. But shouldn't that cause a page break before the text is printed on
the new page? I do think so.
Next suspect: Setting .CurrentY = 10.
Hey - shouldn't that cause each print to start at a top margin of 10 cm?
Hey - aren't you using a lineprinter ("in my printer i want to use continuous
paper for printing")?
Hey - how could this poor beast move up to 10 cm if the last print caused
it to move to 10 + LineHeight + LineHight cm?
[ I know my old NEC C 90 from the last century could do that - if
programmed in a very special way; and there were many older Brothers and
cousins of him which couldn't
]
The hypothesis, that your printer/printer driver/activex componentent
will 'keep it simple' and just issue a formfeed if you try to print
to a position above/smaller than the one you used before, looks very
plausible.
Let's take revenge on the problem by keeping it simple too. If you use .CurrentY
in your current protool hosted script, take/comment it out and test. If there
are no more nasty formfeeds and the perforation between sheets is correctly
skipped - problem solved. (Feel free to skim the rest of this posting.)
If page margins are not kept, you'll have to
increment .CurrentY in your (equivalent of) PrintIt()
issue a .EndPage and set .CurrentX to TopMargin before .CurrentY grows greater
than BottomMargin
Feel free to ask here, if you need help with that (post your code).
And what if I'm wrong again? Don't setting .CurrentY to the same value before the
print still doesn't get rid of the formfeeds? Then all I can say (without further
discussion/looking at your code) is:
(1) Make sure your (equivalent of) PrintIt() doesn't look like PrintIt_destructive()
(2) Consider whether protool & your protool code are comparable to IE/MSHTA &
the script I posted; if not: would you say that protool is more akin to a web
server: calling a server side script (with complete load/unload cycle) each
time a request is made?
(3) In the later case: Is there something like Global.asa in protool? If yes, try
to move the top level/init code and the global variables to this file. If no,
I'm just running out of ideas.
But I'm not allowed to run out of aspects. The third one isn't done with yet. It has
to do with all the "Class cFakePrinter" code and the "CreateObject" action, which I
simplified in the above citation. As I don't like to write/post code that can't be
tested immediately and I'm not allowed to install to the ActiveX printer (not only
printers have to obey laws!), I had to fake (or mock - that's the term to google
for) the behaviour of the objects I wanted to use. For this I created a - in this
case trivial - class and used a structly localized "On Error Resume next"
' initialized with dirty trick
On Error Resume Next
Set PrinterObj = CreateObject( "avbScriptPrinter.PrinterObj" )
On Error Goto 0
If IsEmpty( PrinterObj ) Then Set PrinterObj = New cFakePrinter
Set Printer = PrinterObj.Printer
to assign a my cFakePrinter object to the vaiable PrinterObj if the CreateObject()
call should fail. After that all my code used the fake.
This aspect of the script is the most uninteresting for you, KALEL. It's proven
that your script's call to CreateObject( "avbScriptPrinter.PrinterObj" ) succeded
and that your code used that PrinterObj - alas to produce formfeeds. So you could
delete all this fake code to make the script more easy to understand; perhaps more
easy to enhance, if you think of using it for testing out of protool.
But other interested people without the component would need the simulated object
to get a complete run (and some MsgBoxes) from the script. I once used this technique
to fake and test all the interaction between a professional Document Management
System and my script. Doing this from the documentation only was hard work, that I
can tell you. But when the script was installed at the first customer's side, it
ran (and did what it should do) without any further editing. Ok, by now you have
perceived that I'm proud of this fake. So rest assured: if you feel the need to
do something similiar and can't work from this simple example, just ask and you'll
get a posting longer than this.
|
|
| |
|
|
|
|
|
Printable Version
great. normaly this were better for me. ;) 
