I want to copy a file from c:\ to new location on c:\ ....

[technovice]

...any ideas on what code I should have within a command button.

Within the command button I have been using :

shell "copy c:\file1 c:\newdir\file1"

When I run this I get the error 'file not found'.

Any help is much appreciated.

 

[azrobert]

Do a search in help on copy method

I did this a while back but can't find the code...
You will need to put some error checking in to make sure the file and directories exist.......

I will look further but the help file should get you started

 

[PatrickGreen]

technovice:

You might want to begin using the Microsoft Scripting Runtime Reference.

After referencing this dll.....you will add the following code to your button on click event:

Dim fso As New FileSystemObject
Dim retVal as boolean

If (fso.FileExists("c:\file1&quot) then
fso.CopyFile(c:\newdir\file1,"c:\file1",True)
End If

I hope this helps,
Thanks,
Patrick

 

[harebrain]

Why not just use the FileCopy function?

FileCopy "c:\file1", "c:\newdir\file1"

As the first reply suggested, set an error trap in case the destination directory doesn't exist.
--
HTH,
David

 

[PatrickGreen]

harebrain:

I don't usually set up error handling to handle things that are not errors. It is just as easy to use the FSO and check for the file then change your error routine to look for particular errors.


Patrick

 

[harebrain]

Patrick,

Hmm,

Run-time error '76':

Path not found

Looks like we have different ideas on the meaning of the words "error" and "particular."

--David

 

[PatrickGreen]

harebrain:

What I meant, is that in my error handler, I do not have a case statement with specific errors to return to the user.

Would you rather send to the user

Run-time error '76':

Path not found

or a "clean" message box informing the user of what went wrong. You will never be able to create a case statement that will have a "clean" message for every error. But to eliminate some of the possible errors through different coding techniques is deffinitely a good idea.


Patrick

 

[ADoozer]

My 10 pence!

Im with patrick on this: for me fso is the way to handle this problem, a true or false is a lot nicer than a run time error. If somethings hard to do, its not worth doing - Homer Simpson

 

[harebrain]

Patrick and ADoozer,

No, no, no, I'm not suggesting that you show the user a run-time error, hence the use of the word "trap."

While you might never want to create a "select case" statement to handle every possible run-time error, you can certainly anticipate the "Path not found" error and handle it gracefully. Let me also point out that there is a "case else" clause for the "select" statement, which would allow you to handle unanticipated run-time errors gracefully, thus never allowing the program to just blow-up in the user's face.

And since technovice wasn't using FSO to begin with, why start now? Thar's overhead in instantiating them thar objects! (Just as there was overhead in spawning that shell.)

Imagine: two different techniques to achieve the same result!

--David

 

[Schroeder]

I love the FileSystemObject and wish it was intrinsic. However, if all I'm doing is copying one file and have no other use for the Scripting Runtime library, I would forego the FSO in the interest of conserving a substantial amount of overhead. I don't think errors should be considered "trouble" as much as messages sent from VB to your program. Anticipating and handling one of those messages is just part of writing a program.