VBA - How do I develop macros in Excel 2013 for Excel 2010 clients

I already know the solution, I just don't know how to implement it.

I can find tons of hits on Google about late binding: just declare my variables as Objects, and then use GetObject or CreateObject.

That's easy to do for Excel objects from within Word. But how do I do that for Excel objects from within Excel? The VBE won't let you uncheck the Excel library from within Excel, even in a brand-new, empty workbook!

EE1.jpg
NOTE: this is happening to me from Excel 2013.
LVL 14
ThomasMcA2Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ryan ChongBusiness Systems Analyst , ex-Senior Application EngineerCommented:
it's by default Excel need to use this Library enabled macro (VBA) to run. So you cannot remove it as you wish to.

>>But how do I do that for Excel objects from within Excel?
You can directily refers to:

Application object, like:

Application.Name
Application.Version

Also, look for objects like:

Workbooks
Worksheets

Open the Object Browser (press F2) for a list of objects/functions available in macro environment.
ThomasMcA2Author Commented:
Thanks, but that is an illogical approach for MS to take, which is why I never expected that to be the answer.

If the IDE can access Word or PowerPoint methods and properties via objects, then it should do the same for Excel.

By forcing Excel to be referenced, it is allowing the current application to use early binding, but everything else has to use late binding. But if you do use that early binding, then your code will fail on desktops that have an earlier version of Excel. That seems error-prone to me.

I will wait to see if the older version of Excel generates an error before I accept your answer.
Ryan ChongBusiness Systems Analyst , ex-Senior Application EngineerCommented:
>>Thanks, but that is an illogical approach for MS to take, which is why I never expected that to be the answer.
I tested in Macro environment for Word and Outlook, they didn't allow me to remove the respective Object Library as well. So, this could be the way how macro was built.

This article further explained this behavior was "by design".

OFF: Error When You Remove Forms Object Library Reference
https://support.microsoft.com/en-us/kb/155207
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

Subodh Tiwari (Neeraj)Excel & VBA ExpertCommented:
Why would you want to remove the parent library reference?
[ fanpages ]IT Services ConsultantCommented:
ThomasMcA2:

There is no need to worry about the "Microsoft Excel 15.0 Object Library", "OLE Automation", &/or "Visual Basic for Applications" References.

These are "BuiltIn" type library references within the VBE [Visual Basic Environment] that are required for using the Automation components of the product.

(You may also see a fourth reference; "Microsoft Office 15.0 Object Library")


However, if you were to create a Visual Basic (for Applications) Project in MS-Excel 2013, you will see the "Microsoft Excel 15.0 Object Library" listed as a Reference.

As long as the workbook containing the VBA code is saved in a file format that an earlier version of MS-Excel can open (in this case, MS-Excel 2010's supported file formats are the same as MS-Excel 2013's in any respect), then when the same workbook is opened in the earlier revision of the product, the "BuiltIn" references are automatically changed to reflect the different version.

For example, if you were to create a workbook in MS-Excel 2013, you would see the References:

References - VBAProject - MS-Excel 2013
Saving the workbook, & opening, say, in MS-Excel 2003, the list of References would be automatically changed to accommodate that environment:

References - VBAProject - MS-Excel 2003
The same is true in MS-Excel 2010, & MS-Excel 2007.

The respective "BuiltIn" libraries for each version of the product will be changed accordingly:

MS-Excel 2013 ("Microsoft Excel 15.0 Object Library"), MS-Excel 2010 ("Microsoft Excel 14.0 Object Library"), MS-Excel 2007 ("...12.0..."), MS-Excel 2003 ("11.0"), MS-Excel 2002 ("10.0"), & so on.

This is not unique to MS-Excel.

This is the same across the rest of the products within the MS-Office suite (where Visual Basic for Applications code is supported).

Hence, the answer to your question...

"VBA - How do I develop macros in Excel 2013 for Excel 2010 clients"

...is; just write the VBA code in your MS-Excel 2013 environment, & as long as you are not using any version-specific features that are not supported in the earlier product in the run-time environment, then the code will run as it did within your development environment.

That said, it is often a wise idea to develop code in the same environment as that which the run-time user has available or, at the very least, test within this environment at salient points within your development cycle; certainly before releasing to the user community.

If the community has more than one version available, or you do not know which version is in use by a subset of the users, then develop (&/or test) within the lowest revision available to you to ensure that you are not introducing features that not all of the users can use.

Over the years, as the product(s) have been improved/enhanced, some of the VBA statement syntax has changed in later revisions, & certain parameters/attributes in the most recent revisions are not available/supported within the earlier releases.

If you do not develop in the intended run-time version or, as I mentioned, at the very least, perform some of your project's testing within that version (or those versions), then you may find that the code will not be able to be run without run-time errors.

In order to avoid this, you can, as Ryan Chong mentioned in his first reply above (ID: 40901410), check the value of the Application.Version to establish which specific product version is being used.

The value of Application.VBE.Version may also prove useful in this respect, but whenever I am writing code that is either developed in one environment, but may be run in different versions, I use Application.Version most often to determine which version of the product (MS-Excel, in this case) is being used at run-time in case my code needs to take account of differences.

(I can direct you to recent code samples I have posted in questions at Experts-Exchange.com that make use of Application.Version to influence the execution of the code at run-time, if you wish).

Depending on the "complexity" (in terms of use of product-specific features, or external libraries) of what you are preparing for your user community, you may need to make any considerations whatsoever.

I am happy to discuss further, if you wish to do so.

I write Visual Basic for Applications code in MS-Excel 2013 [32-bit] on a daily basis that is used by the intended user community with different run-time environments:

MS-Excel 2007 & MS-Excel 2010 [32-bit] in an MS-Windows PC Desktop environment, plus
MS-Excel 2010 [32-bit] & MS-Excel 2010 [64-bit] in a Citrix-based (MS-Windows) Virtual Machine implementation.

In order to ensure the 64-bit environments were supported, I used MS-Excel 2010 [64-bit] & MS-Excel 2013 [64-bit] as the development platform for some time during this project.

There is only one version of the code stored in one workbook.  All users are able to use this single workbook in their specific run-time environment(s).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ThomasMcA2Author Commented:
Thanks. I still need to test whether my code works on the lower-versioned desktop.
Martin LissOlder than dirtCommented:
I've requested that this question be closed as follows:

Accepted answer: 500 points for ryancys's comment #a40901410

for the following reason:

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
[ fanpages ]IT Services ConsultantCommented:
Thanks for closing the question, ThomasMcA2.

Good luck with the rest of your project.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Excel

From novice to tech pro — start learning today.