what do you mean by *user intervention*?? your question makes it sound like you want to avoid the execution of the FSO code by issuing a simple conditional statement:User intervention to abort Scripting.FileSystemObject CopyFile() with a button.
if [some condition TRUE] then
Scripting.FileSystemObject CopyFile(args)
else
'redirect somewhere else because condition is false. do something else
end if
what do you mean by *user intervention*?? your question makes it sound like you want to avoid the execution of the FSO code by issuing a simple conditional statement:Code:if [some condition TRUE] then Scripting.FileSystemObject CopyFile(args) else 'redirect somewhere else because condition is false. do something else end if
from a software development standpoint, IMO, doing something like that should never be necessary. proper coding and contingency measures would strip out the need to ever do it.Not at all, I need somehow that a user could interrupt during the copy progress just as how windows simulate it.
from a software development standpoint, IMO, doing something like that should never be necessary. proper coding and contingency measures would strip out the need to ever do it.
I didn't mean to sound like an a$$, daryll. I've never:Please elaborate "proper coding and contingency measures would strip out the need to ever do it", if you are copying 1 huge file to a server? If you don't mind.
....depending on the definition of *huge file*. What I was simply saying is that, if you are a professional developer and you code in such a way that you can anticipate what a typical user does/attempts to do when using your application, an operation of aborting a file copy using vba's FSO should never need to have happen. Does that make sense? It's hard to explain, however maybe a suitable *sideways-looking* illustration would be something like this in the simplist sense:copied 1 huge file to a server
If MsgBox("this file copy will take several minutes" & vbCrLf & vbCrLf & _
"are you sure you want to proceed?", vbYesNoCancel + vbInformation, "Confirm File Transfer") = vbYes Then
'proceed with FSO file copy here
Else
'exit routine, the user does not wait for the file copy to complete
End If
You ask user is it OK to copy
They answer yes to to dialog you start the copy
user answers no
you exit sub
end ask
I didn't mean to sound like an a$$, daryll. I've never:....depending on the definition of *huge file*. What I was simply saying is that, if you are a professional developer and you code in such a way that you can anticipate what a typical user does/attempts to do when using your application, an operation of aborting a file copy using vba's FSO should never need to have happen. Does that make sense? It's hard to explain, however maybe a suitable *sideways-looking* illustration would be something like this in the simplist sense:Code:If MsgBox("this file copy will take several minutes" & vbCrLf & vbCrLf & _ "are you sure you want to proceed?", vbYesNoCancel + vbInformation, "Confirm File Transfer") = vbYes Then 'proceed with FSO file copy here Else 'exit routine, the user does not wait for the file copy to complete End If
that's where you come in to play, man! As a developer, I would assume you would inform the user that a client-server process, when it comes to large files, always takes a while. The people that I talk to over here understand that, even though sometimes they don't like hearing it. If I properly educate them on *why* stuff happens or needs to happen, they tend to understand. I've been successful in that regard 99% of the time, but I have had a few failures. Note though, that in those instances, the user went to another developer only to find out that the new one told them the same thing. I had a conversation last week with a GoDaddy agent (God help us all in that regard!) and I was complaining about timeouts and weird server errors happening intermittently when requesting page loads from an IIS server running the windows OS. Her response:Have you put in to consideration by clicking that "YES" button, user tends to get bored and will decide to abort the process?
She's right of course, but the funny thing is....I've *never* had that stuff happen with an Apache server running Linux. One more reason why open-source people are so great.there's no way for me to know why that happens. Sometimes things just don't work. I would give it a few minutes and try again.
that's where you come in to play, man! As a developer, I would assume you would inform the user that a client-server process, when it comes to large files, always takes a while. The people that I talk to over here understand that, even though sometimes they don't like hearing it. If I properly educate them on *why* stuff happens or needs to happen, they tend to understand. I've been successful in that regard 99% of the time, but I have had a few failures. Note though, that in those instances, the user went to another developer only to find out that the new one told them the same thing. I had a conversation last week with a GoDaddy agent (God help us all in that regard!) and I was complaining about timeouts and weird server errors happening intermittently when requesting page loads from an IIS server running the windows OS. Her response:She's right of course, but the funny thing is....I've *never* had that stuff happen with an Apache server running Linux. One more reason why open-source people are so great.
I understand where you're coming from daryll. But I'm a big proponent of educating un-educated people about how technology works and why, in this day in age, stuff happens and it's impossible to explain it. Do you honestly believe that, for instance in my GoDaddy example, with the millions of tiny shelf-sitting servers around the world sitting in 'x' number of massive warehouses in endless number of vertical racks, that *something* is *not* bound to happen that's unexplainable!? that's like saying there's no need for the kill switch on the stock market in New York City because the millions of algorithms coming from all the trading firms can't possibly get confused with each other during the day and cause a market crash (which, by the way, has already happened more than once). but there has already been a possible solution provided to you here, hasn't there? I would assume if you researched this on the web, you would find a suitable alternative if you really wanted to.That's it? What you see is what you get? C'mon man, that's where "professional programmers" thing come in to play, at least there might be an alternative than just letting the user bleed.
I understand where you're coming from daryll. But I'm a big proponent of educating un-educated people about how technology works and why, in this day in age, stuff happens and it's impossible to explain it. Do you honestly believe that, for instance in my GoDaddy example, with the millions of tiny shelf-sitting servers around the world sitting in 'x' number of massive warehouses in endless number of vertical racks, that *something* is *not* bound to happen that's unexplainable!? that's like saying there's no need for the kill switch on the stock market in New York City because the millions of algorithms coming from all the trading firms can't possibly get confused with each other during the day and cause a market crash (which, by the way, has already happened more than once). but there has already been a possible solution provided to you here, hasn't there? I would assume if you researched this on the web, you would find a suitable alternative if you really wanted to.
are you *really* sure about that? I'm sure you've done plenty of research, but I'm not sure I'm convinced. I would have to run my own research efforts to be sure though. I've done so many countless workarounds for so many unintended problems over 10 years now, that I've found that there's rarely a scenario that *cannot* be manipulated to get the result an executive wants, when he/she doesn't know anything about what they're doing/wanting. Come to think of it, I'll try and look up your problem right now....I was aware though that once the process started i't can't be stopped.
daryll,
I was suspecting that you're issue was unsolvable, primarily because of the apparent inability of VBA to execute more than 1 process at a time (check with others here about that though). This thread gives an explanation of why you can't kill the FSO process you're talking about while it's transacting. Furthermore, this thread pretty much says the same thing. And after this search of mine, I looked up the concept of multi-threading, which in my mind, is similar to what a programming language *can* be capable of (I'm not sure if any languages can do this, because I've never had a need to care, check with others about it). I remember having a conversation with the access experts around here about this stuff many years ago, but I can't remember the details of what came out of it.
Once you start the copy file I don't think it can be stopped.
Option Compare Database
Option Explicit
'Mendip Data Systems - 23/11/2017
'API declarations & Type checked/updated
Private Type SHFILEOPSTRUCT
#If VBA7 Then
hwnd As LongPtr
hNameMappings As LongPtr
#Else
hwnd As Long
hNameMappings As Long
#End If
wFunc As Long
pFrom As String
pTo As String
fFlags As Integer
fAnyOperationsAborted As Long
lpszProgressTitle As String
End Type
'####################################
#If VBA7 Then
Private Declare PtrSafe Function SHFileOperation Lib "shell32.dll" _
Alias "SHFileOperationA" (lpFileOp As SHFILEOPSTRUCT) As Long
#Else
Private Declare Function SHFileOperation Lib "shell32.dll" _
Alias "SHFileOperationA" (lpFileOp As SHFILEOPSTRUCT) As Long
#End If
'#####################################
Private Const FOF_ALLOWUNDO = &H40
Private Const FOF_NOCONFIRMATION = &H10
Private Const FO_COPY = &H2
Public Function apiFileCopy(src As String, dest As String, _
Optional NoConfirm As Boolean = False) As Boolean
'PARAMETERS: src: Source File (FullPath)
'dest: Destination File (FullPath or directory)
'NoConfirm (Optional): If set to true, no confirmation box
'is displayed when overwriting existing files, and no
'copy progress dialog box is displayed
'Returns (True if Successful, false otherwise)
Dim WinType_SFO As SHFILEOPSTRUCT
Dim lRet As Long
Dim lflags As Long
lflags = FOF_ALLOWUNDO
If NoConfirm Then lflags = lflags & FOF_NOCONFIRMATION
With WinType_SFO
.wFunc = FO_COPY
.pFrom = src
.pTo = dest
.fFlags = lflags
End With
lRet = SHFileOperation(WinType_SFO)
apiFileCopy = (lRet = 0)
End Function
You can pause or cancel the file copy process if you use a Windows API rather than file scripting object.