I have a working excel workbook that has VBA code and macros to help in data input.
I use a calendar to capture dates and read data out of cells. The application works 100% on my machine (application developed in 2007 but saved as a .XLS – 97/2000 for compatibility in the office).
When I give the file to other people, the calendar control and the TRIM() function do not work.
On my machine I can get to the references section but on all other machines in the office the references function is grayed out. Any idea why a common object like the calendar and a common function like trim() do not work on some machines
Are the references greyed-out in a new workbook on the other PCs? References are usually only greyed-out when code is running. The calendar control was (is?) notorious for not running on the various different releases, so various work-arounds have been developed, such as Allen Browne's calendar pop-up. Trim is part of Visual Basic for Applications and you will probably find that the function is fixed once you get rid of the missing Calendar control reference.
The calendar control has many different versions, you need to build it out of the version they have on their machine.
VBA will automatically update references to the newest version. Example: If I reference Office 10.0 and you have Office 12.0 on your machine the reference will automatically be updated from ten to twelve. But it does not downgrade them. So if you have a reference to Office 12.0 and deploy it on a machine that only has Office 10.0 then you code will break.
There are two ways around this. If you want to stay with early binding then you will need to obtain a copy of the oldest version of the library in use. Then reference that file.
The usual alternative would be to go to late binding. However this can be little more challenging with embedded controls.
Related
An Access database used by multiple people at my office occasionally flashes several error messages in quick succession and then loses some macro functionality. The first time it happened, I researched the topic and found a solution - there were missing references in Visual Basic that had to be fixed. Upon opening the reference list, 4 that were selected all read 'MISSING: Microsoft X 16.0 Object Library' where X is [Word, Powerpoint, Excel, Outlook]. I deselected these references, scrolled down and selected the 15.0 Object Library references. Things were back to normal, full macro functionality restored.
However, the references keep reverting back to 16.0 Object Library ones that are still missing. Sometimes it will be several weeks before I have to replace the missing references with the older version, sometimes it will happen the next day. It's not a difficult fix at all, but it keeps happening, and most of the other users would not know what to do.
I have to imagine the problem is persisting because the database is shared across multiple computers in the same office, though I believe all PCs have the same version of Microsoft Office installed. Any thoughts?
Despite what you believe, I suspect that someone has a newer version of Office, perhaps Access 2016 or an Office 365 subscription. I experience this problem at my office, but it is expected since I know that some computers have Access 2016 while I am using Office 2013.
Creating a separate front-end database is already a best practice for many reason. It would likely eliminate or reduce such problems with your shared database. The shared back-end database can be stripped of all code modules and macros that might be dependent on a particular version. The front-end can then be copied to each client. As long as the front-end database is distributed (i.e. copied) from a lesser version (i.e. references last set to Office 15.0 for example) to each client, any newer versions of Access will automatically update the references of only its local copy.
Yes this is a very annoying feature of Microsoft's Component Object Model. (Although it was extremely cutting edge when it was revealed to us in the mid 1990s.)
A practical solution is to switch the VBA to use late binding rather than early binding. In doing that you can drop the explicit reference altogether and the problem goes away.
A half way house is to use a late binding loader addin which, depending on the client configuration, loads an addin specific to their environment. That loaded addin can use early binding.
The second option might be more practical in that it would require fewer code changes.
I'm making a program that will eventually be used as a simple program to keep track of customers at a campground. I had originally made an excel spreadsheet for the owner where they could add how much each renter paid per month and I set it up in a way that it totaled each month and the whole year for him and displayed it like an accounting spreadsheet, with double underlines and the like. Now, he no longer has a copy of excel. I have set him up temporarily on google docs, but besides it not having all the functionality of excel, he doesn't trust it on the internet and has a hard time navigating to it.
What I'd like to do is create a program that would use forms to let him easily enter information, but display it either in the excel spreadsheet like he's used to seeing, or something that looks and prints pretty much the same.
I've seen people use SQL to work with access and excel. I'd like the connection string for that if anyone knows it. I have Visual Studio 2013 and I have Excel 2010 at home and work and 2013 at work.
My big question for you guys, that I can't find any information on is whether or not excel will work if I install the program on his computer that doesn't have excel installed? Does it work because it's part of the program? Can I only use the sheets and formulas that I set up when I created it? Can I generate new sheets using the program once it's installed on a pc that doesn't have excel installed on it? Thanks a lot for the help guys. I can't find information on this anywhere.
It depends what library you use. If you use Microsoft.Office.Interop.Excel than you will need to have the specific version of excel installed or at least a version that supports your interop assembly (my past experience was that it had to be exact).
The other option is to use another standalone third party library that reads the zipped XML files (.xlsx) and can manipulate it through that. Some libraries worth mention:
NPOI
EPPlus
ExcelLibrary
I am converting a C# VSTO add-in to support multiple versions of Excel (2007, 2010, 2013). My current plan is to have 4 projects in the solution, the core functionality and the AddIn projects. My question is: is it possible to write the AddIn in such a way that it will work with all versions of Excel? If not, is there a common Excel object model that would work?
If there isn't a proscribed way to do it, I would extract out the functionality from the Excel object model into a set of classes/interfaces that could then pass through an adapter to get o the real objects, then have version specific projects that contain the adapters. However, this is a lot of work I'd like to avoid.
Thanks,
Erick
Look at these two options for office version independent addins:
NetOffice is a free wrapper that does something similar to what you described in your second paragraph
Addin express is a similar (but commercial) framework
For the second option the development looks something like this:
you select the lowest version of Office you wish to support
you write the code against the object model of that version
Even with that you will still find some differences in how different versions of Excel work. For example this is one change that needs to be considered.
Sorry if this is a silly question.
What can I do to make my VBA code work on Office 2003/2007/2010 ?
Can it be done or should I create different VBA code for each?
I use
WinHttp.WinHttpRequest.5.1
Make a lot of Windows API Calls
Have five references to libraries
wininet.dll
kernel32
Outlook.Application
InternetExplorer.Application
I'm developing on Office 2007 but users with Office 2010 cant run the code. Not sure about users runnning other office versions.
I have also seen that one can create an Excel-Addin in Visual Studio but I dont have a lot of experience in that area.
Thx for any suggestions.
for different versions of Excel, you can just use Conditional Compilation such as #If Application.version>n then
However, for any users who have Win64 systems, you will have to provide different methods of calling the API functions.
Your best bet is to try and manipulate Excel using Automation either from .NET using Office.Interop, or VSTO.
An application currently in development has the requirements for using MS Word to perform spell check on certain textareas within the application.
I currently have Office 2007 (which is the Office 12 com objects).
My question is, if I add in the Office 12 objects what will happen on boxes which have Office 2003? This is in regards to both other development boxes as well as the end users.
Am I correct in believing that the end result will be that the spell capabilities will not be available for those users? And if I used an Office 11 object would that mean that the users would be unable to perform the spellchecks if they have Office 07 installed?
We gave up on trying to use a dependency on Word, as both have differing versions installed or no Office installation at all! Instead opting for NetSpell.
I am guessing here, but if it is as you can't use the 2007 PIA (Primary Interop Assembly) with a 2003 installation, you could try accessing the PIA via reflection as I would guess the calls you want won't change between the two, and then it won't matter - you'll use whichever is installed. If you are installing the PIA as well, you can then either get the user to tell you which they have, or be a little more clever and just try 2007 and if it fails, try 2003.
Like I said, I'm guessing here but it might be worth a try.
EDIT: I found this link about Office PIA's. This refers to Excel but actually covers Office in general. I don't envy the task you have. Looks like you'll need to detect the PIA (which may or may not be installed) and act accordingly. Sounds like a job for reflection to me.
Newer versions of Office will maintain most if not all compatibility with older versions of COM objects. Meaning if you want to program against Office 2003 and 2007 you will need to use Office 11 COM objects as a dependency as they were the newest available when 2003 was released. As long as you verify that the methods you need exist both versions of COM objects you should have no problems as long as you use the older COM objects.
Unfortunately, although I have used this solution for my own work, I have not tested it with Spell Check. In the end make sure that you test your code with all version of Office that you wish to integrate with.
My gut reaction to this question, is to simply suggest you go another route. Try using a 3rd party spell-check control. They are relatively inexpensive (and you may find some free controls). At least that way you can control the version of the control included with your app and be able to rely on it's functionality. Quite frankly, I'm surprised this library isn't built into Windows already. Sure it's complicated with all of the languages Windows supports, but these days it's similar to copy/paste in terms of user expectations.
You can actually package both the office11 and office12 interops needed to work in BOTH versions. It takes some minor work but I managed to do it. I do a check in the registry to see which interop to call and then executes the spell checking with the correct version. It even goes so far as to check if you have Word installed and throws an error alert that you can't spell check without having Word. We're tied to using Word due to the medical dictionary that's tied into Office we're required to use.
Do a search on interop or Com wrappers and I think you'll find you can use both fairly easily.