I wrote some VBA in Excel 2013 which references Outlook and is now used on a virtual machine. My laptop was upgraded to Office 2016 last week, I made some changes in this tool and then it failed to run on the VM.
Turns out the VBA Outlook reference in the file changed to v16.0 (Office 2016) and so when the VM tried to run the code (on 2013), it couldn't find this reference.
There was also the generic Office reference which stayed as v15.0 though.
I haven't been able to find any documentation on this - is this standard behaviour and if so, any ideas on how I can make further changes to this file without the reference messing up every time?
This is standard behaviour.
You need to move from Early to Late binding. Remove the Outlook reference in VBE and declare the outlook application as Object in code.
Dim olApp As Object
Set olApp = CreateObject("Outlook.Application")
Bare in mind by doing so you will lose intellisense and you may have to change some constants to their numeric values, e.g. olMailItem to 0.
Make sure you have Option Explicit at the very top of your module(s), as this will highlight compilation errors.
Related
I have the below code to create an instance of Visio from Excel. It works on machines where I have a single version of Visio installed, but on some machines I have 2 versions (2010 and 2016) installed. On these machines it fails to run with the error "Method 'Visible' of object 'IVApplication' failed". When I check AppVisio its empty, and I am guessing it is because both applications are visio.exe. Is there a way to create the object from a specific path, or any way to createobject when 2 versions are installed?
Set AppVisio = CreateObject("visio.application")
AppVisio.Visible = False
Set docsObj = AppVisio.Documents
There are some options I believe.
Solution 1 (I would recommend this one). Install only Visio 2010 on your development machine (and uninstall 2016). It's safest to have the lowest version you want your app to run with on your dev machine anyways. Add a reference to Visio 2010's type library in Excel. Remove the reference to Visio 21016 type library. Visio versions are upward-compatible, so the code should run properly even on the machine with Visio 2016.
Solution 2. Use late binding. Remove the reference to the Visio from your excel project altogether and use only script-like access. In this case, you will lose auto-completion though. If your app is not a big one, that should not be an issue.
Solution 3. (if you want to run a specific version). You can start the Visio application from the program files (like any other executable), and then connect to it using "GetObject(...)" instead of "CreateObject(...)"
BTW, there is a better way to run Visio as invisible app (without flashing):
Set appVisio = CreateObject("Visio.InvisibleApp")
If you early-bind it by adding a reference (Tools | References) to the desired version then Diming your object as that type, you'll be guaranteed which version you're using.
Dim visioApplication as Visio.Application
Set visioApplication = new Visio.Application
However, that may not be the full solution if your company is mid-upgrade and some folks have the new version and some the older version. You'd get run-time issues on the machines that don't have your chosen version.
To solve that issue, you could create MyApp2010 and MyApp2016, each linking to the appropriate version of Visio, but that becomes a bit of a maintenance nightmare for you...
Early-binding does add loads of benefits like IntelliSense and turning most run-time errors into compile-time errors, so it's probably still worth it.
I am, perhaps foolishly, running an old and complex MDB (originally written in Access 2003, where everything worked smoothly for about a decade under good old XP) with lots of VBA in Access 2013 under WINE (well, Crossover Linux). Most things work, surprisingly, but I have a strange problem with automation. The following code launches an instance of Word that can be seen in task manager, but doesn't assign any object to oWord. It fails at oWord.Visible=True with error 91 and oWord is Nothing.
Dim oWord As Word.Application
Set oWord = CreateObject("Word.Application")
oWord.Visible = True
I've tried early binding and late binding and more or less every line of code that can possibly be used to start Word. Using New Word.Application (or New anything) instantly crashes Access and WiNE's crash report is beyond me. I have exactly the same problem with automating Adobe Acrobat Pro, so this isn't about Office: Acrobat starts, but no object is assigned and I get error 91. Both programs launch happily from Shell. CreateObject is not always failing, either: oddly elsewhere in the database I have no problems with
Dim HttpReq As Object
Set HttpReq = CreateObject("MSXML2.XMLHTTP.6.0")
(but it fails without the version number).
I don't think this is to do with references, either, though I can list them if anyone thinks it's worth it.
Sorry this post is all over the place, but, to summarise.
I think my problem is probably with one of the dlls that WINE uses, and the advice I want is about which dll is likely to cause these particular problems if it is corrupt or incorrect. Then I can try different versions, maybe extract a clean copy from a Win 7 ISO (I've tried several copies of oleaut32.dll, which can be a sore subject with WINE, to no effect save that you can't run VBA at all with WINE's builtin version). I don't want to reinstall Office 2013 because it's so twitchy about activation under WINE. I don't want to risk blowing a perfectly valid licence testing it in a new wineprefix/bottle. I have a separate installation on a second workstation that's doing exactly the same thing. I'm running Lubuntu 18.04 LTS with WINE 3.0.5 and Crossover Linux 18; the wineprefixes are emulating Win 7.
Any help would be very, very gratefully received. I know this is a quixotic project, but so much works perfectly that this is really frustrating. Thank you.
I have a VB.NET 2010 program that works perfectly with MS Office XP. Because of security concerns attributed to Office XP, I recently upgraded to MS Office 2007. I made no changes to the VB program.
A single Build Error, Type Excel.Global is not defined. is preventing the program from running. The ErrorList points to the UpgradeSupport module as the location of the error.
The entire UpgradeSupport module is as follows:
Module UpgradeSupport
Friend DAODBEngine_definst As New DAO.DBEngine
Friend ExcelGlobal_definst As New Excel.[Global]
End Module
The instance of Excel.[Global] above is the only visible instance of it in the entire program, and there are no instances of Excel.Global at all, anywhere. The variable name, Excel.Global (or Excel.[Global]) suggests a structure. Moreover, I believe Global (or [Global]) is a property, not a type, and I believe Excel.Global and Excel.[Global] are not equivalent expressions. I can successfully define structure Excel.[Global] as follows:
Public Structure Excel
Shared Property [Global] As Object
End Structure
Note: The above will not define successfully without the square brackets around Global, which supports my assertion that the two expressions are not equivalent. I question whether any instance of Type Excel.Global exists in the program. Nevertheless, the Build Error continues to prevent the program from running. How can I eliminate the Build Error?
I have a Microstation macro that reads the reference files in the current drawing and then prints them to a text file. We are working on getting this running for the new Microstation v8i (upgrade from v8). The macro normally runs through each reference file (from index = 1 to MbeRefFiles.maxRefFiles) and finds the active reference for output.
Now instead, it keeps throwing an Object variable not Set error when referencing the MbeRefFiles(index) object. I'm just doing a Set refFile = MbeRefFiles(index) and it says MbeRefFiles isn't set, which doesn't make sense because it doesn't need to be set. The macro is completely unchanged and has been working for years, and now suddenly it can't read the reference file object. Anyone have any insights?
As far as I know, you have to use VBA than you can get more comfortable support.Microstation's VBA is based on Microsoft's engine while MBE is cooked by Bentley.
MicroStation BASIC became obsolete in 2001 when Bentley Systems released MicroStation v8.
Prefer to use MicroStation VBA. It fully supports MicroStation V8 where MicroStation BASIC falls short. MbeRefFiles.maxRefFiles is an example of the shortcomings of MicroStation BASIC. MicroStation VBA provides a collection (ModelReference.Attachments) that you can iterate using VBA idioms.
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