I have written a considerable number of macros for Microsoft Word running on Windows 10.
One macro in particular takes lines of text from a Word.Table in one Word.Document, copies them to Word.Paragraphs another Word.Document, and formats them with various Word.Styles.
The use case is that the macro is writing a contract for me, from a table of template clauses.
Normally, this runs quite slowly, as there is a lot of work going on underneath, both in selecting template clauses, and formatting; and I have optimised later when possible.
However, by chance I found that if I held down the CRTL + ALT key whilst the macro was running, the speed seemed to increase by 2x or more.
I observed this through the speed by which Debug.Print messages appeared when tracking the progress of the macro, and anecdotally have seen the same effect on other macros I have written.
It seems an unlikely quick win or free lunch.
Has anyone else encountered this for their own macros, or am I imagining things?
Pressing this key combination must be turning ScreenUpdating off.
Related
The problem
Although one might assume this is a de rigeur problem with a mismanaged workbook, please hear me out. I'm working with a relatively modest (80-100kb) excel file. It has minimal formatting, very few formulas, and it's vba code doesn't do anything too fancy. I've been working with vba for a few months now and have had this problem exactly once before. As this tool will be used in producing reports for a while to come, and as I've limited time, I'd rather not rebuild the whole thing or turn in an unwieldy project.
Details
My code loops through several dozen 200+kb .xls files using Workbooks.Open method and grabs 1-2 values depending on what it's opened. It's been working through over a half dozen iterations with no change in size. In my latest version it's balloned from 100kb to 10mb. No tabs have been added, I've looked extensively for all sorts of formatting and other traditional pitfalls—it's not my first rodeo in that respect. I am new-ish to vba though, and so often step through code and have to pause or stop debugging before resuming to correct syntax. Sometimes this will happen before any Workbooks.Close method.
I think, inexplicably, during some combination of saves/crashes/debugging, excel has 'saved' some of the opened workbooks in this file's memory. It gets weirder: if I copy all of my worksheets, as well as my code, to a new workbook, the file size falls back down to 100kb or so. I've had this problem once before. Using a 20kb workbook I was trying to pull values from a 135mb workbook; after one save I noticed that my workbook was now 135mb and change, and I was only able to get it back down to 20kb by copying everything one sheet at a time to a new workbook. Does anyone know what's going on?
Attempting to google this produces dozens of pages on extraneous formatting, formulas, and VBA code unrelated to my issue.
I could post pseudo-code if it would be useful to see, but I'm pretty sure it wouldn't be too enlightening, and that my problem is some memory issue that occurs between .Open and .Close methods.
Edit: after looking through some of the workbooks that I'm opening, quite a few of them are 'around' 10mb. It seems suspicious to me that my tool would increase in size by about as much as one of the .xlsx files I'm opening.
I have exactly the problem described here:
From what I can see on the web, this is a fairly common complaint, but answers seem to be rarer. The problem is this:
We have a number of Excel VBA apps which work perfectly on a number of users' machines. However on one machine they stop on certain lines of code. It is always the same lines, but those lines seem to have nothing in common with one another.
If you press F5 (run) after the halt, the app continues, so it's almost like a break point has been added. We've tried selecting 'remove all breaks' from the menu and even adding a break and removing it again.
We've had this issue with single apps before and we've 'bodged' it by cutting code out of modules, compiling and then pasting it back in etc.
The problem now seems to relate to Excel itself rather than a single .xls, so we're a little unsure how to manage this.
I have managed to resolve it with the accepted answer, but now, when I send the VBA file to my colleagues, they have the same problem.
My question and my problem is - any ideas what to do, as far as it is really not a good idea to go to everyone and to debug every time. And I somehow do not want to add Application.EnableCancelKey = xlDisabled to my macros.
Sounds like a ghost break. File saved one time with a break in there. What has worked for me in the past was to remove any breaks you see and manually step through the code (F8) through completion and then save file. Prob now necessay to step all the way through but I like to know I went all the way and didn't miss any.
This has been a long and unresolved problem with Excel VBA code that runs a repeated loop via the Application.OnTime Now + TimeSerial(x,x,x). Users will find that their code is running fine for a few days and may, or may not, mysteriously stop.
I'm facing such a situation and hoping to resolve it. I've read over 30 forum answers, some written by experienced developers, and came to this understanding. My conclusion and question follow.
The conclusion is that Excel randomly goes into a break mode but no one knows the reason why this occurs, more so, why it randomly occurs.
Shall we then conclude that in fact this randomly occurs? And that Excel VBA isn't as robust as other languages.
Some notes:
I know this can be resolved by pressing Ctrl+Break twice. It doesn't explain why we have to do it in the first place.
I realize that this error is code independent. It'll occur with both simple and involved programs.
After trying multiple ways to simulate this error, and I mean a lot - long and multiple ADODB SQL connections and queries, cell editing while macro is running, using multiple and 1 second Application.OnTime recursive calling, I can't replicate the error. It is truly random.
I'm running only one workbook and one Excel instance.
Some say, for each break point we did in the debugging, that break point remains in memory. And then when we run a macro in the future, a write to that part of memory triggers this random break. This is a plausible explanation and does conclude that this error is random. No way can we inspect memory in VBA.
I need something to go by, even if it isn't to solve this problem, to act as proof for my boss.
I've solved the bug! I've not read this answer to this problem before so it is pivotal that the Excel community receives this.
Excel fails to call its sub routines in the Application OnTime queue whenever this happens. You have started to edit a cell, stayed in edit mode, and then switched away from Excel either by minimizing the window or by clicking onto another window.
All the sub routines in the Application OnTime queue will wait until the cell is finished editing. So once you switch back to Excel, the cell switches edit mode off, and then all the sub routines will run.
I'm actually quite impressed I solved this myself.
I'm writing a VBA code that will run everything after I leave the office.
The macro works fine, the problems is that sometimes (more often than I'd like) I get the message:
Excel cannot complete this task with the available resources. Choose less data or close other applications. Excel cannot complete this task with the available resources. Choose less data or close other applications. Continue without Undo?
I just click OK and the code runs fine, but I have do click the OK manually,
I've already tried the
Application.DisplayAlerts = False
but this doesn't work.
Does anyone know if I can't make excel "overpass" this problem?
Thank you in advanced
I believe "Continue without Undo" means Excel is temporarily clearing the RAM it uses to track undo levels and then (it seems) your macro has the resources it needs to complete the process.
Take a look at what your macro is doing to use so much RAM: Is there a way to modify it so that less RAM is required? There are several options for this listed here:
How to clear memory to prevent "out of memory error" in excel vba?
Second option to fix this might be adding RAM to your machine, but it will not fix the cause of the error.
Third, if you want to risk a registry edit and reduced or eliminated undo levels in Excel, you might be able to prevent this error by reducing the number of undo levels (http://support.microsoft.com/kb/211922).
I have an Excel macro that takes an exceedingly long time. It seems to crash Excel (I get a Not Responding message in the taskbar) when I leave it unattended, but if I put a breakpoint that gets hit every five or ten seconds, it's OK. Trouble is, I'll need to step on from the breakpoint about a quarter of a million times (we're looking at about 200 hours to execute this beast)
I'm guessing that the absence of message pump activity is antagonising the kernel, so how might I flush the message queue? Or am I barking up the wrong tree entirely?
I'm very new to this, by the way, so documentation references will be very welcome.
Cheers,
Guy
Seconding the opinion that 200h is a bit worrying, however you can try the DoEvents statement which "surrenders execution of the macro so that the operating system can process other events". (Note that calling DoEvents has an additional time penalty)
I have to agree with 0xA3, if you have an excel routine that is expected to take over 200 hours to run then you're either setting it up in a very inefficient manner or you're using the wrong tool for this job.
In any case, there are a few things you can do to optimize the routine. These will be especially helpful if you are constantly writing values to individual cells.
Sub MarathonCalc
Application.EnableEvents = False
Application.ScreenUpdating = False
' Code to decode human genome goes here
Application.EnableEvents = True
Application.ScreenUpdating = True
End Sub
Again, if you post some of your code perhaps we can help track down why it's taking so long.
"Not responding" doesn't mean that Excel is crashing, it simply means that it does not actually respond to window messages.
Unless that is a problem there is nothing you need to worry about. I'm rather worried about your comment that you expect the task to take 200h (which is more than a week!). It seems to me that you are not using the right tool for this job. Try to find out what is taking so long and explain what you are actually doing. Then we can see how to better solve this task.
The previous answers have given you 'DoEvents' and that's the first-line fix for your problem.
However... A closer look at what's happening raises some worrying questions. Firstly, Excel's threading model is rather primitive: there's one process (according to the documentation) and no new threads are created by internally- or externally-generated events, callbacks and messages. One process, and one process ONLY, and everything else has to wait until the current VBA macro or spreadsheet calculation runs to completion.
Actually, some things can interrupt this: {esc} and {ctrl-break} (although these can be temporarily disabled), so there's at least one other thread running in Excel all the time, and you'd EXPECT the operating system to be allowed to break into a process... Wouldn't you?
The ugly reality is that the Excel application does not allow external events and messages to run to an 'event sink' while a macro or calculation is running, unless you call 'DoEvents' and some Windows Messages (note the capitalisation) still won't be dealt with.
If an undocumented number of messages and external events are left hanging around, the application will crash. Based on my own tests, I think the number is 50; there's documentation about a registry setting out there, but I'm not linking to material that I consider unreliable - I've tried the setting in question and found it to be ineffective.
So where does that leave you?
Firstly, look at your code again. Application.EnableEvents = False and Application.ScreenUpdating = False are useful settings: your next step is to find all and every read- or write operation to individual cells on the sheet and just grab arrays of cells - it's much faster to grab an array using myVBAarray=Range.Value, do your calculations in VBA, and write the VBA array variant back to Range.Value.
Secondly... You've also seen that the 'wait' state imposed by a breakpoint allows some things to sort themselves out. That sounds like an external process (a database query?) running asynchronously: could it be that the message or event which is crashing Excel is coming from that very process?