Board index » Visual Studio » Newbie: Works when stepped through, but not when run?

Visual Studio204
I have a simple code to rename the files in a specific folder. When I

stepped through it to check it, it worked fine. I'm sure I even ran the exe

after creating it just to make sure. But that was last week!



Today, if I run the exe, it tells me it's done, but it didn't work. If I

step through it, everything works fine! Can someone tell me what's going

on, and how to correct it, please?



Ed



Private Sub Command1_Click()



Dim objFSO As Object

Dim objFolder As Object

Dim objFile As Object



Set objFSO = CreateObject("Scripting.FileSystemObject")

On Error Resume Next

Set objFolder = objFSO.GetFolder _

("C:\Documents and Settings\emillis\Desktop\Files\")

If Not objFolder Is Nothing Then

On Error GoTo 0

For Each objFile In objFolder.Files

With objFile

.Name = .Name & ".doc"

End With

Next

End If



MsgBox "I'm done!"



End Sub


-

Did you try to run without the On Error Resume Netx ?

Put some MsgBoxes in the code and try to figure out what's the difference

between step=through enad run the exe.

Let us know the results.



John



"Ed" <ed_millis@removethis.hotmail.com>schreef in bericht



---

Outgoing mail is certified Virus Free.

Checked by AVG anti-virus system (www.grisoft.com).">www.grisoft.com).

Version: 6.0.580 / Virus Database: 367 - Release Date: 6-2-2004





-

Ed-



I've encountered issues like this quite a few times and it always turned out

to be a timing issue. Stepping through code causes a small pause because you

have to hit the f8 button.



I'd probably start by seeing what your code is seeing though. Kill the On

Error Resume Next and change your for/next loop and see what it says:



For Each objFile In objFolder.Files

With objFile

'.Name = .Name & ".doc"

debug.print .Name

End With

Next



hth



Matt





"Ed" <ed_millis@removethis.hotmail.com>wrote in message



-

Thanks for replying, Matt.

That's what I would think - somehow the code is outrunning the computer's

ability to keep up with what it's doing, or something like that?

I watched in the "Locals" window, and everything changed as designed on

stepthrough. I didn't try that with F5, though. I've never used the

Debug.Print - but I guess it's time to learn? 8>)



Ed





-

Thanks for replying, John. I should have thought of that - but that's why

I'm a newbie asking questions! I'll comment out the error lines and see

what happens, and then try the message boxes - maybe to show me the original

and the changed file names. When I stepped through it, the Locals window

showed everything changing as designed, though - which it would, because

everything worked! Go figure!



Ed



"JohnK" <johnk@nomailback.com>wrote in message



-

Ed-



I use debug.print quite a bit because you can see the values as the code

runs normally. The values will appear in the immediate window and you can

custom format them to display however you want.



HTH



Matt





"Ed" <ed_millis@removethis.hotmail.com>wrote in message



-

It can also be a matter of events.



For testing purposes, put in DoEvents just before the Next. Also

you can always try doing this with the Dir$ function and see how

it works out.



Saga



"Ed" <ed_millis@removethis.hotmail.com>wrote in message



-

Okay - it works now. It looks like this:

For Each objFile In objFolder.Files

With objFile

strName1 = .Name

strName2 = .Name & ".doc"

.Name = strName2

strName3 = .Name

Debug.Print strName1

Debug.Print strName3

End With



My thought was: setting the file names in strings forces the program to

evaluate everything, and I left the Debug.Print in as further processing

requirements - if it has to look at it, then it has to be there to look at.



Uh, I also remembered *this time* to make a NEW .exe. Not that I didn't

have a problem with my old .exe - it still didn't work this morning. But I

suddenly realized that this is NOT my Word macro code, and if I don't make a

new .exe, it won't execute the code I've got in there - unless I launch the

window and step through the code.



Thanks for all your help.

Ed



"Matt Williamson" <ih8spam@spamsux.org>wrote in message



-

It'd be interested to see the difference if you tried it using VB's

intrinsic file handling command such as Dir, Name, etc - as I've got a

program at work that renames multiple files in a directory to a different

extension (without using FSO) that works seamlessly. It's possible the

renaming of the file is somehow messing up the FSO's concept of its

enumerator for its Files collection. Although the fact that it works when

you step through suggests it is a timing issue, possibly that requests to

rename files are actually scheduled, to be done by the operating system when

it gets round to it ? or something like that...





HTH





"Ed" <ed_millis@removethis.hotmail.com>wrote in message



-