Re: Mass delete files and directories

--->
"Grand_Poobah" <yoohoo@xxxxxxxxxxxxxx> wrote in message news:OTngFUKsIHA.3780@xxxxxxxxxxxxxxxxxxxxxxx

Use Long only [for fAborted] , anything else could cause a
GPF. BOOL in C++ is 4 bytes. Boolean in VB6 is 2 bytes.
Long is 4 bytes, so use Long.

Done.

When you say, "Done" do you mean that it has fixed the problem for you, or do you just mean that you have now done that but have not yet tested it? If you look at the code I originally posted you'll see that I have used a Long at that position in the UDT and it works fine here on both my machines, but you said that it does not work on one of your four customer machines, and you also said that you had tried both Boolean and Long at that position with the same result. Are you absolutely sure that all four customers are using exactly the same copy of your code? fAborted needs to be a four byte variable (a VB Long) and fFlags needs to be a two byte variable (a VB Integer). Then it works fine. You will still have problems if you try to use any of the three remaining items in the UDT though (the three items immediately following fFlags) because they are two Longs and a String pointer and VB will "pad" the fFlags integer with two padding bytes so that the first of those Longs starts on a LongWord boundary. This causes the data for those items to be offset by two bytes in the UDT from where the SHFileOperation function expects it to be, which will almost certainly result in a crash of the kind you have described. So, if you plan to use any of those last three entries in the UDT then you would be better off replacing all three of them with a byte array (which VB does not require to offset because it does not require a Byte array in a UDT to start on a LongWord boundary) and "poking" [there's an old fashioned word ;-)] the required data directly into the bytes. In fact it might be worth doing that anyway (replacing the last three items with a Byte array) just to be "on the safe side".

Mike





Mike:

Here's an update. I had my problem tester completely uninstall any vestiges of my app and install a newer clean copy of the newer test app. He removed the 'compatibility' setting and ran the program. The messagebox immediately before the API call told him I was going to call the API. When he clicked OK, the program crashed as usual. He changed the compatibility back to Win98/ME and it ran flawlessly.

My other three testers run XP Pro. My own XP Home machine exhibited the same error when run here (I was wrong before when I said it worked ok) and, after changing compatibility, worked just fine also. At least now I can test further without having to go to Australia :<)

fFlags is definitely an Integer and fAborted is definitely a Long. I do not use the last three elements of the structure and did replace them with a byte array to be sure. There were no strange things in the array before the call.

Both my Pro and Home systems have identical versions of "shell32.dll" but, for some strange reason, the call needs that compatibility setting in order to complete on the Home system. I'm thinking that 'shell32' needs some other dll and THAT dll may not be the same between the two systems. Hard to believe since I bet the OS itself calls that API hundreds of times a day just for housekeeping.

GP
.