On the other hand, Mike, perhaps he is always executing in his own
environment and neither he, nor a system administrator, has chosen to
disable FSO (and, if really careful, search and destroy any "rogue
reinstalls" of the WSH on every startup), as many do. If you can count on
it being there, FSO pretty much works as advertised, though for the things I
do, it has never proven any better, and sometimes not so good as, regular,
traditional VB File I/O.
I remember FSO being highly touted it in a column in one of the trade
magazines. You'd have thought it was the greatest discovery since slicing
bread (or an even more monumental discovery sometimes used as a simile), but
for each of the examples used, I created a File I/O example that did exactly
the same thing each with at least one less line of code. When I e-mailed
about it, the columnist had a hard time not admitting that someone at
Microsoft had done a good sales job about the wondrousness of FSO.
A line of code, more or less, is no big deal, but why spend time and effort
to learn a "new thing," in order to be even minutely LESS efficient, even if
you could count on it being in random systems where your code might be
executed (which you can't)?
Larry
Post by Mike WilliamsPunk_History.def is a binary file,
not a text file.
This is the first time you've told us what kind of file you are
dealing with and until that little secret was out of the bag the other
respondents simply posted a sample showing you how to write a text
based data file purely as an example. The main point of their
responses was to inform you that the CommonDialog does not actually
write any files for you. They probably assumed that once they had told
you that little fact you would be able to write the file yourself
using a method suitable to the file you are dealing with.
I use a CommonDialog because it is familiar to
all users, but the file copying [since I was taught
how the CommonDialog works by the previous kind
reponses to my question!!!] is using the
FileSystemObject.
Now it appears that you are copying a file [where the meaning is quite
clear] instead of writing one [where it is not clear, because you
could have meant either crerating from new or copying or almost
anything]. This is the first time you have told us that you are
copying an existing file rather than creating one.
The darn thing works [the FileSystem object]
Not on my system it doesn't. Nor on my wife's laptop. And I've just
nipped over to Uncle Charlie's Kebab shop where he does the accounts
and, blow me down with a feather, it doesn't work on his computer
either! I wonder why? Is it perhaps because the FileSystem object
relies on a scripting system that is historically viewed as a
potential virus delivery system due to the fact that such scripts can
be contained in otherwise innocuous files such as word processor
documents and spreadsheets and things? Do you think the administrator
might have disabled the little beast in order to protect his sytem
from it? How sad. I would advise you to follow the advice of Uncle
Charlie in the Kebab shop and ditch the FSO :-)
Line Input and Print work on a text file.
Ditch the FileSystem object and have a look at standard VB6 file
handling. Regarding your comments about Input and Print (which of
course deal mostly with ascii data or ascii repesentations of the
contents of variables of one sort or another, since that is their job)
have you looked at all the other built in VB file I/O methods? You'll
find all sorts of things such as Open for Binary and Get and Put and
lots of other stuff that allows you to handle files and file data in
just about any way you wish, including very easy binary data handling.
The user uses the commondialog to determine
where to copy the file to, and fPath [part of
my obnoxious and foul FSO code ;-)] does
the actual copying.
Check out the VB FileCopy statement :-)
Mike