I've run into this issue with many different VBA programs, so I'm thinking I may have some incorrect settings in Excel or the VBA editor. Honestly, I'm pretty clueless after a lot of web searching.
Basically, I'll be running a normal piece of code and the application (both Excel and the VBA Editor) will go into (Not Responding) mode. However the code is running fine. Once the code is finished, the application will no longer be in non-responsive mode and everything returns to normal
Really kinda frustrating on users who think something is wrong when really it's just taking a while to run the code.
Any help would be great! Thanks!
Try putting DoEvents statements in your code, so that DoEvents is executed every so often during a lengthy process. See http://support.microsoft.com/kb/118468/en-us
This will return control to the OS, so that the OS can do what it needs to do while your program is running, and this should prevent the OS from thinking that your program is not responding.
Basically, I'll be running a normal piece of code and the application (both Excel and the VBA Editor) will go into (Not Responding) mode. However the code is running fine. Once the code is finished, the application will no longer be in non-responsive mode and everything returns to normal
The User Interface is not responding because you are doing a bunch of processing in response to a UI event.
If this is acceptable to you and your users, all's well enough. If not, consider doing the work on a background thread.
Related
I am experiencing intermittent runtime error when doing the following in Word 2007 VBA:
Doc.PrintPreview
Doc.ClosePrintPreview
Here Doc is a valid document that was successfully opened by the same VBA script (not by the user).
Basically, I need print preview to open (for the purposes of forcing the update of all the fields) and then close it right away. The problem is that in about 20% of cases ClosePrintPreview crashes with runtime error 4605, complaining that the document is not in print preview mode, as if previous PrintPreview method call never did its job.
I can't visually confirm whether the PrintPreview actually did its job because the whole thing happens in pretty busy and tight loop, so Word does not update anything on the screen (even though I never turned off Application.ScreenUpdating).
It happens when the script is processing large documents that have several thousands of fields (print preview takes time to be generated when called interactively). It does not happen on simple, small-size documents.
And the whole thing happens intermittently, so I really can't figure out what triggers it. In about 80% of cases the script runs just fine.
So, the question is whether it is PrintPreview that really fails (which is not good and would need to be addressed, because I call it for a reason) or is it just ClosePrintPreview that gets confused and I could safeguard it with something like
If Application.PrintPreview = True Then Doc.ClosePrintPreview
Has anyone seen anything similar?
This is something I didn't think was even possible, but here goes. I was trying to learn how to use the Windows API in Visual Basic to use system calls, and this tutorial (yes, I had to type out the link manually to ask this question, more on that later) showed me how to use the clipboard to retrieve text that the user copied with Ctrl+C. Out of curiosity, and under the assumption that all user input is bad input, I tried pressing Print Screen and then running the code just to see what would happen. I got some error message (can't remember what) but what's very strange is, now the clipboard no longer works! Any attempt I make to paste after a cut or copy, no matter what program I'm using, either does nothing or returns an error message in the program I'm using it in. Yes, it's my fault for intentionally trying to break the code example, but let's be honest - there's no excuse for the OS to fall apart so easily. If it matters, I'm using a PC running Windows 10.
EDIT: Settings won't let me clear the clipboard, and when I try to view the clipboard history, it shows nothing is there. Unfortunately I wasn't able to screenshot the clipboard history because it closes by itself when I try to open Snipping Tool.
Sounds like you've missed a CloseClipboard(), keeping the clipboard locked since Windows thinks a program is reading to it or writing from it. This will prevent other programs from working with the clipboard, since only one program can access it at a time. If Access is still open, you can try running CloseClipboard in the immediate window, else, I recommend a reboot.
On code like this, always add an error handler that calls CloseClipboard() to prevent leaving the clipboard open if something unexpected happens. Note that when working with WinAPI, you might encounter hard crashes that may not call the error handler, so always triple-check your pointers and expect crashes and reboots.
The code you've found is also not adjusted for 64-bit use, so beware. If you've got it to work by just slapping PtrSafe on the functions, you may end up with invalid pointers which can crash Access, leaving the clipboard open and unusable.
The code you've found, while written by Microsoft, is not of particularly good quality. I recommend first checking if there's text on the clipboard using EnumClipboardFormats, then only requesting text if there actually is text on the clipboard.
Beware that using WinAPI through VBA is tough, it's not beginner stuff, especially regarding the clipboard.
Note that there's no excuse for the OS to fall apart so easily is not the attitude to have when working with WinAPI. You're directly interfacing with the OS without any of the securities that managed languages offer, and manually working with pointers. It can and will break if you do something invalid. There's a reason most people use libraries that abstract the dangerous stuff away, if you don't, all bets are off.
similar problem for me. I did not have a CloseClipboard() but when I looked in another module there was already a EmptyClipboard() so used that before the DupRec() call at each instance and no more problems with clipboard. just FYI
For my customer i had to do a change in a visual basic 6 application running on a windows xp computer.
It's nothing special, just communicating with a plc and functions as a user interface.
My changes work absolute perfect in developer environment(IDE), but when i create the exe it crashes when opening some forms or pressing some buttons. Some stuff works, and some stuff crashes.
Compiler in develop doesn't give any errors even after full compile!
I found some "bugs" by iterating the code and this really is just deleting some variables. (that already existed + It isn't a programmable error) The compiler doesn't give an error, just the exe crashes on it.
An example from bug that crashed:
sub On form_load()
Some code
Global_String_Variabel = "Something"
some code
End sub
By deleting the global string variable just in this form, it didn't crash any more.
It's weird because this peace of code already existed, works perfectly fine in develop but not in .exe
Does somebody have any idea why this could happen?
If I understand your question correctly, the program runs on your development machine both in IDE and compiled in both states, with the string assign and without, yet works only without on the client's machine. Something like this happened to me many years ago, and while it may not be your problem, you might at least be able to rule it out. The client may have a virus scanner that erroneously thinks that a segment of your code is malware. Just adding another line like x = x or something else benign can sometimes fix it.
You may also need to look further into other differences, like other things they have/run that you don't.
Not that it should matter but are you declaring the variable somewhere and using Option Explicit?
My Labview Program works like a charm, until I look at the Block Diagram. No changes are made. I do not Save. Just Ctrl+E and then Ctrl+R.
Now it does not work properly. Only a Restart of Labview fixes the problem.
My Program controls two Scanner arrays for Laser Cutting simultaneously. To force parallel working, I use the Error handler and loops that wait for a signal from the Scanner. But suddenly some loops run more often than they should.
What does majorly happen in Labview when I open the Block diagram that messes with my code?
Edit:
Its hard to tell what is happening without violating my non-disclosure agreement.
I'm controlling two independent mirror-Arrays for Laser Cutting. While one is running one Cutting-Job, the other is supposed to run the other Jobs. Just very fast. When the first is finished they meet at the same position and run the same geometry at the same slow speed. The jobs are provided as *.XML and stored as .net Objects. The device only runs the most recent job and overwrites it when getting a new one.
I can check if a job is still running. While this is true I run a while loop for the other jobs. Now this loop runs a few times too often and even ignores WAIT-blocks to a degree. Also it skips the part where it reads the XML job file, changes the speed part back to fast again and saves it. It only runs one time fast.
#Joe: No it does not. It only runs once well. afterwards it does not.
Youtube links
The way it is supposed to move
The wrong way
There is exactly one thing I can think of that changes solely by opening the block diagram.
When the block diagram opens, any commented-out or unreachable-code-compiler-eliminated sections of code will load their subVIs. If one of those commented out sections of code were somehow interfere with your running code, you might have an issue.
There are only two ways I know of for that to interfere... both of them are fairly improbable.
a) You have some sort of "check for all VIs in memory" or "check for all types in memory" that you're using as a plug-in system. When the commented-out sections load, that would change the VIs in memory. Such systems are not uncommon when parsing XML, so maybe.
b) You are using Run VI method for some dynamically invoked VI to execute as a top-level VI, but by loading the diagram, it discovers that it is a subVI of your current program. A VI cannot simultaneously be top-level and a subVI, so the call to Run VI returns an error.
That's it. I can't think of anything else. Both ideas seem unlikely, but given your claim and a lack of a block diagram, I figured I'd post it as a hypothesis.
In the improbable case someone has a similar problem. The problem was a xml file that was read during run time. Sometimes multiple instances tried to access it and this produced the error.
Quick point to check: are Debug and "retain data in wires" disabled? While it may not change the computations, but it may certainly change the timing of very tight loops, and that was one of the unexpected program behaviors, OP was referring to.
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.