I've written a macro in Excel VBA, which I have used many times before. Today I loaded it up and it wants me to define all the variables (before I let Excel auto-assign everything). When I assigned all the variables, it then didn't recognize simple VBA functions like trim, split, again which it always has before.
I'm not using option explicit. Any idea what my problem could be?
It might have something to do with a recently installed a trial Excel addin (from a respectable company), the trial ran out and I uninstalled the addin, now none of my macros work.
did you try turning off the OPTION Explicit requirement in the VBA Options:
To do this go into the VBA editor ─► Tools ─► Options ─► Editor ─► uncheck Require Variable Declaration.
Related
I have VBA code in 6 modules in an Excel workbook. The code in each module is interlinked. I must also mention that I am using the selenium webdriver along with VBA to automate my work. When the macro is run, the code works perfectly functionality wise, but I can't use Excel for anything else at all during this time. The entire program run time is 30 minutes.
I want to be able to use Excel for other operations and not let the macro affect my system performance. Is there a solution to this?
I read somewhere that creating an Excel ribbon through VSTO to run the macro will help reduce the memory impact on Excel. Not too sure about it though.
Any help would be appreciated.
Thank you.
My personal workbook (PERSONAL.xlsm) has stopped allowing me to view the code or any details of the modules I have saved there. It also will not allow me to run any of the Macros it once included. I don't know if they got deleted or are hiding somewhere (but I am hoping it is the later). I have not done anything out of the ordinary. Before this issue was happening all I had done with excel today was run one of these macros (without issue), make an edit to include the solver in a macro, and save it.
In addition to this problem there are a few others that seem to accompany it:
Occasionally when I close excel without saving a file, excel crashes.
If I attempt to record a macro (either in the Personal Workbook or to
another location) one of the following happens:
a. Excel crashes.
b. Excel gives me an Invalid Name Error (despite the name being perfectly valid.
It is worth noting that macros not saved in the Personal Workbook work just fine. I am very stumped and cannot find a solution to this problem anywhere. I have tried the obvious (rebooting my computer), the not so obvious (restoring previous versions of files), and the weird (disabling and enabling random things in the excel options section). Please, if you have a solution let me know!
Thank you in advance, all and any suggestions are appreciated!
I had a similar problem a while ago. I had to:
close Excel
re-name PERSONAL.xlsm to something else (like temp.xlsm)
open Excel and verify it does not "see" or attempt to open PERSONAL
create a new PERSONAL.xlsm
copy all VBA from temp.xlsm to the new PERSONAL.xlsm
Can't comment yet, so i apologize in advance.
It is definitely Excel at fault, it happens to me so often (on big files including VBA) that my before_save saves a copy of the file with time in its name, and all module's, userform's, sheet's code as *.frm, *.cls, *.bas.
I usually can also open corrupt files by holding SHIFT key (force designer mode) and then copy manually stuff.
As of yesterday, I had a working macro that generated histograms using analysis toolpak (VBA). As you can see below, the analysis toolpak VBA add in is enabled, and I have set a reference in VBA.
The file is saved as .xlsm (macro enabled) and I can produce histograms without a macro:
But if I record a macro to make a histogram, I get this same error. This is happening for all functions within the analysis toolpak. What happened here?
... I'm going to have to call this one solved. Very VERY strange error that must be related to this
error message I received when I disabled both the analysis toolpak and the analysis toolpak for VBA add-ins. My code is back in working order after disabling/re-enabling these add-ins. Maybe someone knows exactly why this is happening, but I have to guess that add-ins are handled as hidden workbooks with VBA functions and something strange happened to that workbook. No clue.
my issue was that when I run the macro (to create a histogram), the first time, it runs normally but when rerun it, it gets the error, mentioned above.
I solved it by unchecking atpvbaen.xls from the references.
I have been searching this for a while without any positives . We can create new modules, form ,report, but macros .Can we at all do this? This post asks the same question but answers another one.
"Create a macro for Microsoft Access via Interop "
here VBA module is being added not macro.
Theoretically it seems feasible as macro is an access object so why we cant do it ?
I dont think you can create macros via vba.
There is an object AllMacros (Application.currentproject.allmacros) and its members are representations of the individual macros in your project - but they are of the type Object, thus there doesn't seem to be any vba representation of the macro object.
You also can't import macros, autogenerate them or convert from vba to macros... So it seems pretty obvious ms isnt encouraging using them and hasn't done anything for us to create them
Where I'm at the developers have been updated to Excel 2007, but most of the users haven't. I'm building a spreadsheet template (*.xlt) for a user that's gonna need some vba code included, and I'm wondering what issues I'm likely to run into building this in 2007 instead of 2003? I don't have access to a machine with Excel 2003 for testing, and I'm worried this particular project is headed for disaster.
The VBA language hasn't changed, but there are additional objects in Office 2007 that are not in Office 2003. Naturally, this will cause a runtime error when you try to access these items in a 2003 environment. What's stopping you from setting about a virtual machine with Excel 2003 to develop under?
Rather than depending on a probably incomplete list of objects and methods which have been added to Excel 2007's object library, the best (mmost relliable) practice is to always develop in the oldest version of Excel likely to be used to run the code.
One difference I discovered is that a subroutine must have a different signature to be called from a menu (in Excel 2003) than when called from the ribbon (in Excel 2007). Whatsmore, Excel 2003 doesn't recognise IRibbonControl and throws compile errors.
To work toward cross-version compatability, I use a Conditional Compilation Argument and then check that in pre-processor macros.
e.g.
#If USINGRIBBON Then
Public Sub CallFromRibbon(control As IRibbonControl)
#Else
Public Sub CallFromRibbon()
#End If
' Code here
End Sub
This does mean that you have to save one version of your add-in with the USINGRIBBON flag set to false (for Excel2003) and another with the USINGRIBBON flag set to true (for Excel2007), but this is far easier than maintaining two completely separate codebases.
billb2112 is right. There are numerous changes to Excel 2007 over excel 2003 that are not backward compatible. While the language might not have changed, the objects have been updated. Some have had additional properties added, some work differently and some functions in Excel have changed.
You need to be very careful that what you code works in Excel 2003.
I would suggest as billb2112 said that you get a virtual machine to not only test in but also to code in. I do all my Excel development for clients who only have 2003 in a 2003 machine. Note that if users have Excel 2002 or 2000 there are even more differences as you go back and you will simply get runtime errors on any code that these older versions don't support.
update
unfortunately jeffs answer is not quite correct. while yes the vba language hasn't been updated it is not the same in 2007 as in 2003. as in 2003 its not the same as in 2002 etc.
what has happened is extra and additional functions and arguments for functions have been added. for example there are more options in the FIND function in Excel in 2003 than in 2002. thus if you record a macro (the best way to find these problems) in 2003 and then run it in 2002 you will have run time errors relating to the new arguments that simply do not work in the 2002 VBA editor. following the same process for functions that have changed in excel 2007 and then going back to 2003 to test will help you locate these problems. some examples include conditional formatting, colours (themes) and numerous new spreadsheet functions.
jon peltier has the best advice from that regard - develop in the oldest possible version that the client /user will use.
Virtual PC 2007 is free to download and install. you will just need a licensed copy of XP/Vista and office to install to run in it.
i used to develop a lot of macros under 2003, what a POTA,, things like Find, Dir and some others are not available or something change. therefore some erros can be expected, i used to count from 65000 row to the first non empty row to count the rows to work on.... now more rows means more work to do