print

[Marc Weber]

Hello,

How can I make this script ??
- print a document named for example "C:\Temp\Test.txt"
I have not found in the VBS documentation a function "Print"!

Has anybody an idea for me ?
Thanks,
Marc

[Harvey Colwell]

There isn't a PRINT function.

Example 1
But if the file type has an application associated with it you can use the
Shell.Application object to invoke it's Print verb. What this means is, if
when you right click on the file, the pop-up menu has Print as a choice,
then this script will work.

[--- Begin: Print File Test.vbs ---]

001. fName = "Test.txt"
002. fdrName = "C:\temp"
003.
004. Set oFS = WScript.CreateObject("Scripting.FileSystemObject")
005. Set oShellApp = CreateObject("Shell.Application")
006. Set oFolder = oShellApp.Namespace(fdrName)
007.
008. If CheckFile(fdrName & "\" & fName) Then
009. oFolder.ParseName(fname).InvokeVerb("&Print")
010. Else
011. MsgBox fName & " not found..."
012. End If
013.
014. '---------------------
015. Function CheckFile(fName)
016. If oFS.FileExists(fName) Then CheckFile = True Else CheckFile =
False
017. End Function

[--- End: Print File Test.vbs ---]

Example 2
Most Windows applications support the "/p" command line option. If you have
the application for the given file type you can simply execute the program
with the Run method of the WScript.Shell object.

Set oWS = WScript.CreateObject("WScript.Shell")
oWS.Run "NotePad.exe /p C:\Temp\Test.txt"

Marc Weber <mar...@pt.lu> wrote in message news:1103_978534159@mc5951...

[Tom Lavedas]

Also, the standard DOS LPT ports can be opened for writing for simple
text files (or string output) from a script. For example, this will
send the raw text to the printer to be printed in that printer's
currently selected (default) internal font.

For example, ...

CreateObject("Scripting.FileSystemObject")_
CopyFile SourceTextFileName "PRN"

or

CreateObject("Scripting.FileSystemObject")_
CopyFile SourceTextFileName "\\server\printername"

or even ...

Set oOut = CreateObject("Scripting.FileSystemObject")_
.OpenTextFile("LPT1", 2)
oOut.WriteLine "This is a test file"
oOut.WriteLine "This is a second line"
oOut.Write Chr(12) ' Ejects page - on most printers

The biggest advantages of this approach are that a printer other than
the 'default' printer can be designated and/or a script can be used to
print text as desired. The biggest disadvantage is that there is little
control over the font/formatting of the document, unless you program it
into the output stream, consistent with the printer being targeted.

As an aside to Mr. Colwell: I'm curious. Why did you create the
CheckFile function? Isn't it just as easy to write ...

008. If oFS.FileExists(fdrName & "\" & fName) Then
009. ...

Tom Lavedas
-----------
http://www.pressroom.com/~tglbatch/

[Harvey Colwell]

This is an old version of some reusable code of mine. I now call this
function IsFile. As a general practice I always check for the existence of
any file or folder before I use it. I have this function in almost every one
of scripts and I've used it so much, that at least to me, it seems like
part of VBScript. I also think it makes it easier to read your code with
functions like IsFile() or IsFolder().

[Tom Lavedas]

I have only one problem with this approach, especially since you say it
is reusable code. That is, your procedure is dependent on the
definition of the global oFS object. This seems like a potential
maintenance issue. I don't like to build general purpose routines that
require globals. It makes them that much harder to paste into another
script. It just might use a different name for the FileSystemObject or
I might forget why I have that global defined when I revamp a script
some months from now. I suppose it's as much a matter of style as your
desire for names like IsFile or IsFolder (although those names could be
mistaken for 'type' testing routines, rather than existence testing).

Tom Lavedas
-----------
http://www.pressroom.com/~tglbatch/

[Harvey Colwell]

Very true. But its hard to write generic code just to respond to a post. I
usually start off with a script that I've already written and cut out what I
think is superfluous.

But for my own scripting, I've created a New.vbs file under the
\Windows\ShellNew folder and added the appropriate entries to the registry.
Therefore, when ever I start a new script, I just right-click the folder
background and select New VBScript File.vbs from the New submenu.

Along with the basic structure of the script, this template file contains
all of my global code as well. So for me it makes perfect sense to assume
that it will be there, even though its not as portable or follows all of the
recommended coding rules.

Even though I started writing utility (troubleshooting) programs over 19
years a go in machine language (binary and octal, no assemblers, compilers,
or interpreters), I've never done it for a living. I often write scripts for
my clients to automate procedures, but I'm the only one that has to be able
to read them.

Over time I have seen the benefit of having more structure and following
certain other coding conventions. Of course I had developed many conventions
of my own over the years, that worked quit well for me. But I'm slowly
adopting more and more of the commonly accepted coding conventions, such as
prefixing variables names with their type.

Now if I could just get myself to add "g_" to the global variables?

Tom Lavedas <lav...@pressroom.com> wrote in message
news:3A55E7CF...@pressroom.com...

[Al Dunbar]

"Harvey Colwell" <HarCo...@AOL.COM> wrote in message
news:OL1yNi3dAHA.1856@tkmsftngp03...

> Very true. But its hard to write generic code just to respond to a post.
I
> usually start off with a script that I've already written and cut out what
I
> think is superfluous.
>
> But for my own scripting, I've created a New.vbs file under the
> \Windows\ShellNew folder and added the appropriate entries to the
registry.
> Therefore, when ever I start a new script, I just right-click the folder
> background and select New VBScript File.vbs from the New submenu.
>
> Along with the basic structure of the script, this template file contains
> all of my global code as well. So for me it makes perfect sense to assume
> that it will be there, even though its not as portable or follows all of
the
> recommended coding rules.

So, presumably, you delete the global items you will not need in the given
program?

What I did to resolve this issue is to write a "linker" that allows me to
skip all the manual cutting and pasting. If a routine needs "oFS" (actually,
my global variable is "FSO"), then it contains a directive like:

@link FSO

FSO is actually just another "source" file that defines and instantiates
FSO. It has another directive that forces it to be linked into the result
before any routines referencing it. The @link directive is not an "include"
function, so that any number of modules can have this statement, but only
one instance of the FSO code will be included.

Of course, the latest versions of WSH and VBScript make this a little
obsolete, and also make it mor feasible to avoid the bane of global
variables altogether. But we still use the older versions at work, and it
was a fun vbs project.

/Al

> Even though I started writing utility (troubleshooting) programs over 19
> years a go in machine language (binary and octal, no assemblers,
compilers,
> or interpreters), I've never done it for a living. I often write scripts
for
> my clients to automate procedures, but I'm the only one that has to be
able
> to read them.
>
> Over time I have seen the benefit of having more structure and following
> certain other coding conventions. Of course I had developed many
conventions
> of my own over the years, that worked quit well for me. But I'm slowly
> adopting more and more of the commonly accepted coding conventions, such
as
> prefixing variables names with their type.

There are pluses and minuses there. I try to name my variables so that the
type is intuitive, and apply prefixes to indicate where the variable comes
from: gbl = global, lcl = local, arg = argument.