I'm looking to disable to the BREAK (or pause) key in VBA, but I have come up against 2 walls.
How do you tell VBA that the function key is being pressed
What is the On.Key {NAME} for interrupt?
My workbook forces users to have macros enabled by setting every sheet to xlVeryHidden when the workbook is closed, and setting them to visible when opened (and various other bits centered around logging in to certain areas of the workbook), meaning the VBA has to be used. However, at certain points in the "Workbook_open" routine, if someone interrupts the program, it leaves the login access vunerable and I do not want this.
I want to be able to bind the interrupt command to any key combination I desire, so only I know what it is, leaving the break key disabled.
Thanks for your help in advance
You can do this via the command Application.EnableCancelKey = xlDisabled.
This link explains it pretty well.
Using Manu's link, I resolved the problem by using this code:
On Error GoTo errorhandler
Application.EnableCancelKey = xlErrorHandler
'***Code that you don't want interupted goes here***
Exit Sub
errorhandler:
If Err.Number = 18 Then
Call error_handler_message
Resume
Else
MsgBox "Something went wrong!"
Exit Sub
End If
in the "error_handler_message" procedure is:
Application.EnableCancelKey = xlDisabled
MsgBox "Breaking Of Code Execution Has Been Disabled", vbOKOnly, "Unable To Stop Process!"
The reason there is the xlDisabled is because without it, the user could press ctrl + break again and break that operation, if you disable it, they can't break the anti-break code too.
Related
I have an Excel macro that I would like to run automatically when the file is opened. The only way I have gotten this to work is by adding a msgbox before calling to my subroutines. However, this requires me to click OK or close the box for the macros to run. I have tried using a timed msgbox sub, but this also does not work.
For some reason, the msgbox pops up before Excel is fully opened, at which point the macro gets stuck here (code for this is below). From here, I tried waiting for the file itself to be opened until it is in write-mode (Workbook.ReadOnly = false). This also did not work.
Public Sub msgBoxTimer()
Const timeout = 2
Dim objShell As Object
Set objShell = CreateObject("WScript.Shell")
objShell.Popup "Measurement will begin shortly", timeout
End Sub
Private Sub Workbook_Open()
Call msgBoxTimer
Call init ' initiate device
Call updateIndex ' collect & record measurements
End Sub
I get from your comment that you are probably running other shell commands in init and updateIndex.
What needs to be clear is that when you execute a Shell command via a Shell object in VBA, the default behavior is not to wait for the shell command to complete before running the next line of codes.
If you want Excel to wait for the Shell command to be completed before continuing, you can have a look at the answers to this question.
That being say, if you want Excel to be fully open before running any shell commands, you can use a MsgBox like you originally intended, but it has to be VBA's MsgBox that you would simply call like this:
MsgBox "Measurement will begin shortly"
The VBA thread will wait for the "OK" button to be pressed before continuing the execution.
I'm having a problem trying to debug some code I've written that opens a shared Excel file from SharePoint (in desktop Excel app), scrapes schedule data, makes a few changes, saves and closes that file, then populates the scraped data into the current workbook formatted as a calendar.
As is typical, the code executes fine for me, but only works about 50% of the time when another user runs it. I'm still searching for fixes to those bugs - they are not the reason for my question today. I'll try as best I can to describe my problem and hopefully someone can tell what I'm doing wrong.
First step I do is to check whether the SharePoint file exists and if so, open it (no problems/errors typically encountered here for myself or anyone else):
Sub getcalendardata()
...define variables...
Application.EnableEvents = False
Application.ScreenUpdating = False
schedule = "https://mycompany.sharepoint.com/sites/Schedule/Shared Documents/Schedule.xlsx"
If URLExists(schedule) = 0 Then
MsgBox "Schedule not found. Check internet connection, login to Office 365, and try again."
Exit Sub
End If
Set schedulewb = Workbooks.Open(schedule, False, False)
schedulewb.AutoSaveOn = False
Application.WindowState = xlMinimized
Set schedulews = schedulewb.Worksheets("Design")
...more code here...
Application.ScreenUpdating = True
Application.EnableEvents = True
End Sub
Function URLExists(url As String) As Boolean
Dim Request As Object
Dim ff As Integer
Dim rc As Variant
On Error GoTo EndNow
Set Request = CreateObject("WinHttp.WinHttpRequest.5.1")
With Request
.Open "GET", url, False
.Send
rc = .StatusText
End With
Set Request = Nothing
If rc = "OK" Then URLExists = True
Exit Function
EndNow:
On Error Goto 0
End Function
*** Occasionally, I run into issues with the cached file in MS Office's Upload Center becoming out-dated and asking to save a copy or discard changes, but that is a problem for another day.
The main problem I've come here for is that after stepping through the Workbooks.Open line, if I open the "Locals Window" to view the stored variables and try and expand the Workbook object "schedulewb" (Here:
Locals Window during code execution), code execution seems to stop or go into an infinite loop. It's like VBA is trying to expand the schedulewb object to display the properties, but isn't getting a response, so it just waits. I've not been patient enough to see if it ever self recovers.
The only thing I see is that the Locals Window schedulewb line goes blank (like it's trying to expand) and I can no longer step through, continue, or reset/end the code execution. I can however, break/pause the execution, at which point, schedulewb returns to the Locals Window list and I'm able to expand it with a very brief delay. Restarting or resetting code execution after this just puts the program into the previous stall pattern and the only recovery option (besides waiting potentially forever) is to close and restart excel via Task Manager. Interestingly, the actual Schedule Workbook I'm trying to peak inside now shows up in the Office Upload Center as a pending upload or having just been synced.
I've tried bypassing SharePoint by opening a local version of the Schedule Workbook saved to my computer, and as expected, I can interact with the Locals Window variables without consequence.
Is there something wrong with setting a SharePoint Workbook to a variable like I've done?
Has an upload/refresh been triggered by me trying to inspect the object properties, causing some other uncontrollable VBA/SharePoint event to infinitely loop in the background?
Could this be connected somehow to the Upload Center cache headache that I think is unrelated?
Thank you in advance for any insight...
Cleanly cancelling a long API-Ridden procedure is hellish, and I'm attempting to work out the best way to navigate the hellishness.
I'm using excel 2016 (with manual calculations and no screen updates) - I may take some time to attempt to run the procedure on 2010 to see if any issues resolve in the coming days (I'm aware of the slowdowns).
Over time, my procedure LongProcedure has lost its ability to successfully use its cancel feature (presumably due to increasing complexity). It was initially inconsistent and required significant spam-clicking to cancel, and now it fails altogether
Here's the setup:
First, LongProcedure is in a class module LongClass with a public property checked against for early cancelling, allowing it to clean up.
Public Sub LongProcedure()
' [Set up some things] '
For Each ' [Item In Some Large Collection (Est. 300 Items)] '
' [Some Code (ETA 5 Seconds) Sprinkled with 3-4 DoEvents] '
' [Export workbook (ETA 10 Seconds)] '
If (cancelLongProcedure) Then Exit For
Next
' [Clean up some things] '
GeneratorForm.Reset ' Let the UserForm know we're finished
End Sub
Second, I have a UserForm shown from a macro, which instantiates the procedure class, and runs the procedure. It contains a run button, a status label, and a cancel button.
Private MyLong As LongClass
Public Sub ButtonRunLongProcedure_Click()
Set myLong = New LongClass
myLong.LongProcedure()
End Sub
So the issue overall is twofold.
The ExportAsFixedFormat call opens a "Publishing..." progress bar which freezes excel for around ten seconds - fine. In all of my efforts, I haven't found a single way to process user input while this is happening.
On top of this, the DoEvents calls seemingly no longer do anything to allow the cancel button to be clicked. The process inconsistently freezes excel, tabs into other open programs, and (when not freezing) updates the status label.
I've Tried:
Appending DoEvents to the SetStatusLabel method instead of sprinkling - while the form still often freezes, it otherwise updates the status label consistently (while still not allowing the cancel button)
Using winAPI Sleep in place of, and in addition to DoEvents with delays of 1, 5, 10, 50, and 250ms - The form simply stopped updating at all without doevents, and with both it froze more.
Using a Do While loop to run DoEvents constantly for one second (Froze)
Overriding QueryClose to cancel the form. This one helped significantly. For some reason, the close [x] button can be clicked far more consistently than the userform buttons - Still not as consistently as I'd like. The problem? during publishing, Excel stops responding, and as such, modern windows will end the process if you click the close button twice... without cleanup.
Using Application.OnTime to regularly call DoEvents. Didn't seem to improve the situation overall
Alt-Tabbing. No, really. for some reason, while alt-tabbing occasionally just makes the UserForm freeze harder, sometimes it makes it stop freezing and update.
This is an issue I'm willing to do significant refactor work for, including smashing up the idea of the long procedure into separate methods, performing setup initially, and cleanup on class termination. I'm looking for something that provides consistent results. - I'll accept anything from excel versions to excel settings to refactors to winAPI calls.
Thanks for any insight into this one.
As it turns out simply combining together some of the useful improvements, along with a new one, made all the difference.
QueryClose is up to personal preference. Leave it in to catch more terminations, leave it out to ensure users use the new solution
Stick to sprinkling doEvents in places you feel are logical (not just when the status bar updates - like before and after an Application.Calculate call)
Optimize the long-running process as best you can, avoiding excel calls
And, most significantly
The integrated cancel key feature (CTRL+Break by default) is significantly more responsive than UserForm buttons and the form close button, without the chance of accidentally ending the excel task.
Here's the process to polish that for a finished product
First, set up a debugMode, or the inverse handleErrors, module-level variable to control whether to implement break-to-cancel and error handling. (Error handling will make your code harder to debug, so you'll appreciate the switch)
If your process is handling errors, you'll set Application.EnableCancelKey to xlErrorHandler, and On Error GoTo [ErrorHandlingLabel]. The error handling label should be directly before cleanup, and immediately set EnableCancelKey to xlDisabled to avoid bugs. Your handler should check the stored Err.Number and act accordingly, before continuing on to the cleanup steps.
Ensure that if you defer to any other complex vba in your script (such as using Application.Calculate on a sheet with UDFs), you set On Error GoTo 0 beforehand, and On Error GoTo [ErrorHandlingLabel] after, to avoid catching cellbound errors.
Unfortunately, the drawback is that for the UX to be consistently readable, you'll have to leave the cancel key on xlDisabled until the form is closed.
And in code:
Public Sub LongProcedure()
If handleErrors Then
On Error GoTo ErrorHandler
Application.EnableCancelKey = xlErrorHandler
End If
' [Set up some things] '
For Each ' [Item In Some Large Collection (Est. 300 Items)] '
' [Some Code (ETA 5 Seconds) Sprinkled with 3-4 DoEvents] '
' [Export workbook (ETA 10 Seconds)] '
Next
ErrorHandler:
If handleErrors Then
Application.EnableCancelKey = xlDisabled
If (Err.Number <> 0 And Err.Number <> 18) Then
MsgBox Err.Description, vbOKOnly, "Error " & CStr(Err.Number)
End If
Err.Clear
On Error GoTo 0
End If
' [Clean up some things] '
GeneratorForm.Reset ' Let the UserForm know we're finished
End Sub
and in the UserForm
Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
If MyLong.handleErrors Then Application.EnableCancelKey = xlInterrupt
End Sub
A small note that this method will likely generate a few bugs you weren't expecting to encounter because the execution jumps directly to the specified label. Your cleanup code will need to have required variables instantiated from the start.
Overall, once these issues are fixed, this setup ensures that the user can click CTRL+Break as many times as they could possibly want without causing crashes or popups.
I have a scheduled LotusScript agent that runs on a client (9.0 Social edition.) One of its purposes is to open a Word document and save it as PDF, but that's not really important. Here's the relevant code snippet
Declarations
Dim wrdApp as Variant
Sub Initialize
[Getting the usual Notes Session, Database, View values]
Set wrdApp = createObject("Word.Application")
wrdApp.visible = True
starthere:
'we check to see if there is anything that has been deferred
Set v = db.GetView("RIT")
strStatus = "Success"
Set doc = v.Getfirstdocument()
If (doc Is Nothing) Then Exit Sub
[Snip]
End Sub
Sub Terminate
wrdApp.visible = True
Dim quitCode As Variant
quitCode = 0
Call wrdApp.quit(quitCode)
Print "Quit called, waiting 3 seconds"
' Wait a couple seconds
Sleep(3)
Print "Done waiting, setting wrdApp to Nothing"
Set wrdApp=Nothing
Print "Exiting agent"
End Sub
The problem I'm having is that since we upgraded to Office 2016, sometimes the agent will never terminate. In the log I see "Done waiting, setting wrdApp to Nothing" but not "Exiting agent." I'll wind up with a Word window open (but no documents of course) and when I look in Task Manager, I see a WINWORD.EXE running with 0% CPU and 2 or 3 seconds of CPU time. And of course just to add to the intrigue, this doesn't happen every time either. And since the agent never ends, all other scheduled agents get held up until I kill the zombie Word instance. I've tried all the suggestions I can find (you'll notice I make Word visible and use a Variant as the parameter to Quit, and I even threw in the sleep(3) out of desparation), but none have made any difference. We never had this problem with Office 2010 (even when the agent code was far sloppier.) Also, the problem can happen whether or not I actually open a Word document. Is there a solution? Or is going back to O2010 the only option?
Sorry for the delay. I developed a wrapper class that can handle both Word and OpenOffice files "transparently". Parts of it you'll find below. I never had complaints from my client that the code no longer works, but that can also be due to the fact that they use the library to open a document using a template, then fill the document with data and then leave the document open.
One difference at first glance: I use Close where you have Quit.
-- to open a document
Function CreateMSWordDocument As Variant
Dim msWord As Variant
On Error Goto CreateNewInstance
Set msWord = GetObject("", "Word.Application")
Done:
Set CreateMSWordDocument = msWord
Exit Function
CreateNewInstance:
Print "Loading Microsoft Word.... Please Wait...."
Err = 0
Set msWord = CreateObject("Word.Application")
Print "Microsoft Word Loaded"
Resume Done
End Function
Set wdDoc= CreateMSWordDocument
-- to close it again:
Sub Close
Call wdDoc.Close
End Sub
I don't have more info for you than the above...
I am not sure if this is still relevant to you.
I have used Word for ages like the way you do (just wrapping it in a Class). However, I have experienced the exact same problem...
The solution was to do NOTHING once I had closed the document - then the WINWORD task just silently quits in the background!
HTH
/John
As a way of update/answer this question, I gave up looking for the real answer and instead wrote a C# program that looks for any instance of WINWORD.EXE that has been running for longer than 15 minutes and kill the process. Then I use the Task Scheduler to kick that program off every 15 minutes. It's crude and ugly, but it put out the 4-alarm fire I had before.
I have not had much experience with VBA, but I sometimes use it at work. Recently, I have encountered a problem that shouldn't happen, and that neither my boss nor myself can figure out.
Basically, the issue is that the Application property DisplayAlerts is set to True by default and can't be changed for some reason. Possibly related is that when I hit an error, it always display the End|Debug|Help alert and never hits the applied error handling.
I am running 64-bit Office 2010 on a 64-bit Windows 7 machine. However, I do not believe it to be a platform issue, as I have tested on multiple different platforms, operating systems and software permutations and no other machine has this error; just mine.
I have created some sample code in case anyone has encountered this before or has any ideas. The only thing I can think of, is that I have something installed on my machine that is causing this. But after a program purge and many restarts, I am no closer to deciphering what it might be.
Public Sub TestErrorHandler()
' Suppress alerts
Application.DisplayAlerts = False
Dim strArray(1) As String
strArray(0) = "Hello"
strArray(1) = "World"
' Set up error handler
On Error GoTo ErrHandler
For i = 0 To 3
MsgBox strArray(i)
Next
' Strip the error handler
On Error GoTo 0
' Unsuppress alerts
Application.DisplayAlerts = True
Exit Sub
ErrHandler:
MsgBox "Error: " & Err.Description
Resume Next
End Sub
The error is thrown on the third enumeration of the for-loop (as it should). The type of the error is irrelevant, what is relevant is that I get the error and never hit the error handler.
Any suggestions or help on this would be greatly appreciated.
Many thanks!
Press ALT + F11 from within Excel to reach VBA editor.
Goto Tools menu -> Options item -> General tab.
Set the error trapping to "Break on unhandled errors"
(source: microsoft.com)