Operating system is Windows 7. Recently offered updates to Office 2016 would not install so I reinstalled Office 2016. Reinstall worked but procedures in MS Access no longer work. I.E when trying to open a docx or xlsx file nothing happens; no error messages. A procedure designed to create a word file creates rtf. If I change the file extension of the files to .doc or .xls, things work. Docx and xlsx files open normally if opened directly, i.e. not via an Access procedure. Have done a “Quick Repair” of Office. Have decompiled Access.
In Control Panel/Default Programs, there is:"Set default programs". In Access, Excel and Word I made sure that all extensions were selected.
Related
I'd like to include a "help" file in my Outlook VSTO addin. I'd like it to just be a word doc which is somehow embedded in the addin in such a way that it doesn't just open the file from a network drive, but rather the word doc itself is part of the installed VSTO and the user can just open it from the addin. I am working in VB.NET. Ideas??
You can achieve this by adding the file as resource. Using visual studio it's as easy as peeling a banana. I use it to store my manual (A Word file).
I have a project that creates a microsoft word document and puts results in it. It works correctly in my own computer but in other computers, this error will be reported:
Microsoft.interop.word not found
Or
Microsoft word can not read this file.
....
I have checked "microsoft office 2007 interop assemblies" in prerequisites at the moment of publishing application. But it didn't solve my problem.
I have developed a tool that will extract data from xml file and drop in formatted excel file.
For this I have 3 types of formatted excel files.
so my question is that whenever I m building .exe file, and try to install this file on another (user's) machine, it will not find that excel files.
and my code give me an error.
How can I include that excel files with .exe setup?
so that I do not need to give that files separately.
I m using Visual studio 2010 express
thanks in advanced.
try to compile your code with Advanced Installer
Here are a couple of options.
1) With respect to a setup tool, Microsoft depreciated their own Setup projects and started including Install Shield Limited Edition. This link should help if you want to check that out: InstallShield Limited Edition is available for download in Visual Studio 2010 I tried it for a few projects and found it ok. It does about as much as the prior Microsoft Setup projects.
2) A less conventional option may be to package the excel templates into your exe as a resource file and then write them to the file system when you run the first time. To do this...
In VS, open My Project and click the resources page on the left.
Click the Resources page and used the Add Resource item in the toolbar to add an existing item. Select your excel file and repeat this for each file.
In your code you can save the resource to disk with code like this:
My.Computer.FileSystem.WriteAllBytes("excel filename.xlsx", My.Resources.ExcelFile1, False)
This option will understandably make your exe larger.
An amateur programmer has made a nice little program that works through VBA on top of a MS-Access2010 database. We are asked to make an installer for this database+VBA project. The code runs fine on any computer with Office installed, but on computers without Office we get the error above. On computers without office we install the MS-Access2010 Runtime, which is free, in order to be able to open the .accde file at all. But this does not prevent the VBA error.
I did some research on the issue but did not find anything related to this specific scenario. How can this be troubleshooted?
The problem was a version mismatch between the .accde file (sp1) and the installed ms access 2010 runtime (original) After upgrading the runtime to sp1 all was fine.
I am currently supporting a Microsoft Access 2000 line of business application with a number of external dependencies, including Microsoft Word 2007 for mail merges. The application uses a batch script to keep external references up to date by copying and registering (if needed) each DLL on the user's computer, something like the script below:
COPY "\\fileshare\references\fileX.dll" "C:\WINDOWS\system32\fileX.dll"
regsvr32 "C:\WINDOWS\system32\fileX.dll"
Here are the DLL's affected:
comdlg32.ocx (registered)
mscomctl.ocx (registered)
stdole2.tlb
MS09.dll
MSACC9.OLB
msoutl.olb
MSWORD.OLB
VBE6.DLL (registered)
dao360.dll (registered)
msado21.tlb
More often than not the batch script simply replaces a user's DLL with the same version of the same DLL. However, for some reason after this batch script executes and a user tries to open a document in Office 2007, a configuration wizards pops up and steals focus from the document only to require a reboot to finish.
While this isn't really a critical work-stopping issue, it is certainly an annoyance. The obvious guess is that it is one of the Office 2007 DLL's, but I haven't been able to isolate which DLL is the culprit.
Any input is greatly appreciated!
It's my understanding that you should not be distributing the OLB files. They are included in the install of Office, and will already be present on any workstation that has office installed.
You also should not be installing any ADO, DAO, or any other MDAC/WDAC components manually.
For older OS's, you should run an installer (MDAC_TYP.EXE) that installs the entire set of Data Access Components; google for MDAC installer for more info. On newer OS's, WDAC is installed as part of Windows.
Of your list, these are the only files that I would consider safe to distribute:
comdlg32.ocx
mscomctl.ocx
stdole2.tlb (although, this REALLY shouldn't be necessary)
All of the other files are either part of Office, and should already be on the box, or are part of WDAC/MDAC.
If absolutely necessary, you can always install the Access 2000 Runtime. This would allow users that do not have Access 2000 installed to still be able to start your application.