I am trying to develop a little macro for PowerPoint using VBA. However, the "Development Environment" is an absolute nightmare!
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there! So I am currently using MsgBox to generate debug messages. :-(
What's also really bad is, that errors in a macro always crash PPT. So one has to wait, until it is gone and then one has to restart it again and get rid of all the Recovery attempts. This always takes ages!
If I set On Error Resume Next it doesn't crash - at least not as often - but then things just silently don't work and I can't see what and why things go wrong (unless I plaster the code with MsgBox calls, but that requires 100'000 clicks during each execution).
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode. So this debugging is driving me nuts!
Is this really the only possibility or environment to develop VBA code in? At least some idea re. debug output, anyone?
M.
The worst: there seems to be no real good way to generate debug output! I read that the Debug.Print output is supposed to go to the Immediate Window, but nothing appears there!
At the risk of sounding insulting (which I don't intend!) do you have the Immediate window open? While in the IDE, press Ctrl+G to see if anything new appears. If so, that's the Immediate window.
What's also really bad is, that errors in a macro always crash PPT.
Not ordinarily, no. It can happen that way, of course; your code might be triggering a bug in PPT. Heaven knows, I ran into enough of that in PPT 2002 and 2007. If you're using reasonable error handling and still running into errors that crash PPT, stepping through the code as it runs should allow you at least to narrow it down to the line or two that cause the crash.
And running the code in the debugger and single stepping trough the code doesn't work, either, since my macro refers to the current "ActivePresentation" and that doesn't seem to exist unless one starts the slideshow mode.
Again, no. The ActivePresentation refers to whatever presentation has focus in the app, whether it's in slide show or any other view. If your code's in one presentation and its' supposed to be acting on another, that can cause some confusion, but you simply need to switch to normal view, make sure the presentation you want to access is visible (I'd make sure not to have several in view) then Alt+F11 to return to the IDE and run your code.
All of these suggestions apply to any Windows version of PPT, going back to Office 97 (Mac? Thinks different. If you're using a Mac, mention that. There are a few differences but for the most part, everything above applies except for the Alt+F11).
If none of this seems to help on your setup, it may be time to do a repair of Office.
Related
I have a button click event in an Access form that sometimes opens the VBA editor with the 'On Error...' line highlighted as if it is in debug mode. I can F5 to continue the rest of the procedure and it works fine.
It doesn't happen everytime. It seems random except there seems to be a pattern that it happens on the first click of this button right after the file is opened. Not everytime though.
Any thoughts on this or previous experience with the same thing happening and subsequent solution? What might be causing this? It's a terrible user experience.
Well, before running any code (hold down shift key during startup to prevent any code from running).
Now, ctrl-g (jump to VBA IDE). Now from tools. Choose
debug->Clear all Breakpoints
Like this:
Now, open up any code module - hit enter key to "dirty" the code. Now choose debug->Compile (first menu option). It will say Compile "my app name".
Make sure the code compiles. If it does not, then stray break points can still exist.
Next up, you need to check/change the default behavior for a error.
While STILL in VBA editor/IDE
From menu bar choose tools->options. The default is "Break on Unhandled errors"
If you have break on ALL Errors? Well then code that even assumed to trap or even on-error resume next code it BLOW UP and stop. Often developers will say try for existence in a collection, and we error tap to "mean" the element is not in that list. However, the THIS assumes that the default Error trapping setting was not change.
So, double, and then triple check this setting. You can develop for years, and even have some code ASSUME to error out. But that years of development code assumed the default (break on unhandled Errors. If you have break on all errors, then your are toast, and you find all kinds of breaking of code. (the idea of that option is to LET you debug code with error handling without having to disable errors. And with say on-error resume next, you in effect can't debug parts of code anymore.
Now, if above steps don't fix your issues?
Then the next step is to de-compile your application. This will remove the compiled (binary) part of the application. Once you do this, then you do a full re-compile.
To de-compile, you can't do this from the IDE, and you have to use a FULL qualified path to your existing version of access. Say like this:
"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE"
"c:\MyCoolApp\Invoice.accDB" /decompile
Now, when you run above, you REALLY must not let any startup forms or code run. (hold down shift key. Now exit access/application. Now re-launch (and again no code to run on startup).
Now, at this point I high recommend a Compact+ Repair (and AGAIN no startup or code to run). So even on the C+R, you have to hold down shift key.
If you during the decomp, start application, then C+R allow ANY code to run, then you have to start over again at the first decompile step.
Ok, now you done the C+R. Now ctrl-g, and now debug-compile.
I am trying to learn VB.Net coming off from experience using VBA. I was wondering if there was something similar that uses the "Debug.Print" from VBA in VB.Net. Also is there also something that is similar to the immediate window that exists in VB.Net? I was also looking for that too.
A great question. (have no idea why the poor sports here are down voting this question – what a miserable bunch – they must have missed their morning coffee.
So, yes, there is a immediate window.
More interesting? The same key in Access/VBA (ctrl-g) will in fact launch the immediate window for you! (so yes to the immediate window, and same key (ctrl-g) to show it).
So this allows a “similar” approach in vb.net
In VBA:
Debug.print "Hello"
In vb.net
Debug.print ("Hello")
So, just keep in mind that WHEN you using debug.print in vb.net, you have use () for the expression. So parentheses "()" are requied. (in VBA that was optional).
ONE MORE very important tip:
By default, debug.print output NOT directed to the immediate window.
So, while in VS, go tools->options.
On the left pane choose “Debbuging”, and then output window.
In that area, check this box:
So, once you do this?
During debugging, the immediate window should appear. (if not, then hit ctrl-g).
The windows unfortunately does hide WHEN you stop debugging, but you CAN hit ctrl-g again.
And WHAT VERY FEW vb.net folks know that VBA Access folks know?
You can in the immediate window even while not debugging, type in a code call such as:
VS will flip into debug mode, and call/run that code! So you can even call + use subs and functions you created (or built in ones) without EVEN being in debug mode (this is exactly what long time VBA developers do, and vb.net supports this wonderful approach to development.
This great idea from VBA is thus avaialble in vb.net,and few seem to know this great tool.
It not “quite” as fluid and easy as the immediate window in Access we all come to know and love, but checking the above box, and using the “long time” ctrl-g key to open/show the immediate window goes a VERY long way and lays out a nice welcome mat of helping VBA developers making the jump to vb.net.
In addition to ctrl-g, you can display the window by going:
from IDE. debug->windows->immedate.
You can use
#If DEBUG Then
'do something
#End If
This is ignored in Release build.
OK, this might be a bit of a generic and repeated non-code question but the latest article I can find about this is from over 2 years ago, so I'm wondering if there's been a fix or an update or maybe some clever dude out there has cracked the secret to curing this.
Every time I extend my screen while Excel (2007, 2010 or 2013) is running, and every time I unplug from an extension while Excel is running, my ActiveX controls are rendered useless, because with each click they either shrink or get bigger, depending on if I extended or unplugged.
This happens until I close the Excel application and restart it, unfortunately if I've saved it while the buttons are bigger/smaller they might end up stuck like that.
There is a thread here which has a bit code to help deal with the issue but quite frankly I'm hoping by now, two years later, someone has a slightly more efficient method of dealing with it.
I've took to using hyperlinks to run macros now but that's no good for my drop-boxes and things. And for me personally, I can just make sure I close Excel before extending/unplugging, but the real issue is I'm developing apps for people around the company and it's starting to cause problems with these damned buttons.
Does anyone know of a definitive fix for this yet?
If you only need ActiveX buttons to run macros, use Shapes instead. You can assign macros to a s shape's Click event. Right-click the shape and select "Assign Macro".
I'm building a document-level VSTO customization for an Excel 2016 workbook, and I'm encountering this error repeatedly in the development process. Basically, Visual Studio 2015 builds the project, Excel loads the workbook, and immediately Excel displays an "Automation Error / Catastrophic Failure" message. It kicks me into the VBA editor, but there's no code on the screen to edit.
I read in a few places that the error means there is something wrong with the "References" settings in the VBE, but it won't let me open that screen, the option is grayed out. Anything else I try to do just pulls that error up again. The only way out is to stop the process through Visual Studio. If I open the source workbook directly from the project folder, the same problem occurs, and I have to quit Excel via Task Manager.
This problem has been coming and going over the past 24 hours; last night and this morning it wasn't happening for some reason, so I was having no issues running and testing my project, but now the problem is back. If anyone has an idea of what could be causing this problem (bearing in mind it must be something that has not been constant over the past day), I'm all ears. Even just an idea of what to look for would be helpful, as I don't even know what this error means or what kinds of things to look for. This is my first VSTO project and I've been pretty excited by what I was able to accomplish when this error wasn't coming up every time, so I'd like to eliminate the problem permanently.
Edit: I should point out that the reason I included VSTO in the question title is that this workbook was totally fine before I started the VSTO project. But I saw this error when I tried to run the VSTO project for the first time, yesterday.
So, I think I "kinda-sorta" figured out my own problem. I'm still not 100% sure what caused it in the first place, but I'll leave this here for anyone else who runs into the same issue someday:
When you get this error, don't despair like I did because the VBE window has no code highlighted as the problem area. Look through ALL the VBA code in every object/module/sheet; in my case, I eventually found a function highlighted as the cause of the problem. I was able to bypass the error temporarily by turning off automatic calculations, and I commented out the offending function. It broke some things in my workbook to do so, but it gave me the opportunity to debug my VB.net code in Visual Studio, and when I uncommented the "problem" VBA function after doing so, it all worked perfectly fine.
I´d like to know how can I stop execution in smalltalk. I entered an infinite loop and don´t want to loose the code that´s written. I tried using pause button but doesn´t seem to be right.
Normally, even if you are unable to stop execution, you should be able to get the code changes you made back from the .changes file. If you can restart the image, there is a 'recover lost changes' menu entry. Always first make a backup copy of the changes and image files before trying this. (In Pharo/Squeak. Other smalltalk have similar possibilities)
it depends on the dialect and possibly keyboard settings.
try CMD-. or CTRL-., which works in most dialects.