Say you have 10 users(numbers are arbitrary):
7 users use Windows 7 with Office 2013, both 32-bit
3 users use Windows 10 (64-bit) with Office 2013 (32-bit)
The Windows 10 users have 2 errors when trying to use a macro:
On opening the macro, they receive an error about a missing file on their system
When the form/controls begin to load, they receive a compile error message
The first error was fixed by removing a reference to Common Controls (mscomct2.ocx).
The second error is caused by ComboBoxes that are used as DatePickers. These ComboBoxes are not loaded at all on the Win10 systems.
cboFillerName = Date
The problem is that the macro works perfectly for the 7 users, but it doesn't work for any of the 3 users. The only difference between them is Windows 10.
So is there some API difference between the two operating systems that would cause this? Is it the mixture of Win10/Office 2013 (32-bit) that creates a convoluted scenario where ComboBoxes can't be used as Date Pickers?
I cannot provide any specific code, though I don't think that matters as this problem does not seem to be code related.
Related
I'm trying to do this in Excel VBA:
Cells(1, 2) = AscW(Cells(1, 1).Value)
It works fine in Excel 12 (2007) and 16 (2016) on one of my machines (Windows 7 laptop), but the machine (Windows thin client, not sure the version but looks a bit like Windows 7) that has Excel 14 (2010) gives "Compile error: Wrong number of arguments or invalid property assignment".
Any ideas? Is it the machine, a bug/feature in that version of Excel, or something else?
Update It seems to matter which machine the workbook was created on. They are both .xlsm files, but the one I created on the laptop works fine when I copy it onto the thin client. The workbook that I created on the thin client (actually, I received from someone else) has the problem. Both have the public sub in the worksheet's VBA code. Sadly I cannot transfer files in the other direction.
I have an Microsoft Access 2010 database application with split front end and backend which has started to behave oddly, and I've exhausted all the options I know for investigating and resolving the problem.
32-bit Access 2010 running on Windows 8.1... I have both Access 2010 and Access 2013 installed, but the problem also manifests itself on a Windows 8.1 system with a completely fresh install of Access 2010 and no Office 2013 present. The issue also exists if the application is run using Access 2010 Runtime. The front-end is running on my hard disk, not in a Dropbox or similar environment. The back-end is in Dropbox.
There are a couple of third-party elements in the application -- references are as shown -- example 1 on the system with both Access 2010 and 2013 present, example 2 on the system with just Access 2010 present.
There hasn't been a software update to the Treeview control since December 2013. I've checked that the versions of the third-party controls I'm using are compatible with Windows 8.1.
Symptoms:
The application (an unreleased development version) initially works perfectly, but if closed and reopened, one specific operation (right-click on a third party treeview ActiveX control on the main form) misbehaves -- the right-click event is triggered multiple times instead of just once (the number of times is unpredictable). There are two treeviews on the main form with identical settings (populated dynamically with different data sets). One treeview behaves, one doesn't. Even if I remove all code from the right-click event, it fires twice.
This main form configuration and code hasn't been changed in over one year, not has the treeview config or code. I don't use Compact on Close. The application isn't logging any errors.
What I've tried:
If I restore a previous version of the application, it works... and when reopened, doesn't work. (I've tried this with several previous versions of the database.)
I've tried importing a copy of the main form from an old working version of the database -- same problem.
I've tried deleting the malfunctioning treeview and creating a new one (copying the one that is working) -- same problem.
I've tried creating a new blank database and importing all the objects from the old one. Once I've restored the references manually, the same problem.
I've reviewed all the possibilities mentioned in Can't eliminate Access corruption -- one commonality I have with this question is that I've (last three months) started using the VBA Implements keyword, but I hadn't made any changes to this code immediately before the problem showed up, and neither the main form nor the treeview control utilise it.
I've emailed the support team for the treeview control, but they haven't anything to suggest that I haven't already tried.
I've repaired the installation of both Access 2010 and Office 365 in case the references were somehow messed up.
I've un-installed Office 365 and Access 2010, rebooted the machine and reinstalled Access 2010. The references are all Office 14 references and the problem still exists (in a compiled accde). As soon as I reinstall Office 365, the references become mixed 14 and 15. (This is also true for the working version which is two years old).
What I haven't tried yet:
Rolling back a two months' worth of Windows updates to see if it's a Windows issue (this system has only been in use since early September, so this wouldn't be hugely onerous to try).
Rolling back to a version of the app from December 2012 (the last production release) which doesn't seem to have suffered the corruption and manually reapply almost two years worth of development changes. This would be a mega undertaking....
Are there any other options for investigation or resolution that I can try?
Edited to add: What finally worked
I created a new empty database, imported everything from the old database except the main form, which I recreated from scratch to look identical and have the same code as the old one... And the problem has gone away. It not very satisfactory as a resolution, but it seems to confirm that there was a corruption somewhere.
One of the best ways to remove corruption in an Access database is to save the forms and reports to text using the undocumented SaveAsText function, delete the form and report objects, close the database, use the undocumented /decompile switch to decompile the database, compact/repair the database, then re-import all the objects using the undocumented LoadFromText function.
Usually the Access databases corruptions affect the VBA modules, less likely the table data. So hopefully you should be able to copy the data to a blank database, get the VBA code from a older backup (since the last source code update) and merging the two together. It should work!
It won't stay fixed unless you disable updates. And you can't disable updates because you will be compromising security.
I am having serious problems with the Microsoft Windows Common Controls 6.0 SP6 library in Access. I have a number of scripts which were working fine before the weekend, but which fail lately on multiple different computers when they encounter the StrConv function. Here's a low-down on what's been going on:
Previously, all was working fine. On the afternoon of Friday the 20th (4 days ago), I began encountering some odd messages when I moused over a progress bar ActiveX control I had on one of my forms. This happened on the MouseMove, MouseDown, MouseUp and MouseClick events at least; the message reported was "The expression [MouseMove] you entered as the event property setting produced the following error: There was an error loading an ActiveX control on one of your forms or reports." I had registered none of the events mentioned on this control. Scripts in general were still working at this point.
Yesterday (after the weekend), I found that scripts I had written no longer worked. When encountering the StrConv function (which I was using to convert a string to uppercase), the VBA editor brought up an error message saying "Compile error: Can't find project or library." This function I'd imagine is quite a core part of the VBA language, but the only missing library I could find under Tools->References was "Microsoft Windows Common Controls 6.0 (SP6)". The missing file was listed as C:\Windows\system32\MSCOMCTL.OCX but this was present on the machine anyway. Browsing to it in the references dialogue made no difference.
Since then I have tried installing various different Microsoft Visual Basic redistributions, have followed the instructions at http://www.fmsinc.com/MicrosoftAccess/controls/mscomctl/, have phoned our company's tech support and have tried a system restore to a point where the scripts functioned previously, but nothing has worked. The database I am using resides in a networked folder on a server but the MS Access applications are local to the workstations.
Is there any way to resolve this issue?
Simply open one of the forms giving you trouble in Design View. Insert a new ActiveX object control in the form and save. Load the forms again. Hopefully this solves the problem. You can then safely delete the added control.
I have an app in VBA consisting of many reports, queries, forms and tables. This .mdb file is linked to another .mdb file (the actual database for the app). This app was originally developed in Windows XP. But I have to move this app to run from a machine which has Windows 7. Now when I run a particular report in win 7 machine it throws an error.
The expression On Deactivate you entered as the event property setting produced the following error : A problem occurred while application was communicating with the OLE server or Active X component
When I comment out the Deactivate event from that particular report, the error is no more. But the interesting point is, when I use the same .mdb file to run from a XP machine, it works just fine.
I am very much confused. Any help will be highly appreciated.
Create a new report and, one by one, copy the controls from the previous report till the moment you get the error. The moment you got the error, discard that very control and recreate that very control again in the new report. After that copy the other remaining controls.
The idea is to pinpoint the control or controls which are causing the pain and then to discard those controls and recreate them again.
My configuration is windows server 2003 (i'm logged in with admin privileges), office 2003, vtso runtime 2005 se. After installing my addin, all registry keys are in the correct locations and I have given fulltrust to my assembly using caspol.exe. My addin is a application level addin.
When I run excel with regmon and filemon running I can see that excel reads the registry keys of my addin, but I do not see the AddinLoader.dll being loaded in filemon. I get no errors from vsto since it doesn't appear the runtime is even starting up. I've read almost all of the vsto doco on msdn particularly the application addin architecture and vsto runtime overview as well as various other articles and discussions on the topic. I still can't figure out why the runtime won't load on the terminal server.
When installing this on an XP machine it all works fine and my addin gets loaded every time.
Anyone have any idea what might be preventing the vsto runtime from loading?
I had a similar problem with Outlook 2007 on a 64 bit Windows.
I added this reg key and then it worked:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\Common\General]
"EnableLocalMachineVSTO"=dword:00000001
Keep in mind to update Office 2007 to the latest service pack ( 3 as of now )
Never Mind I found that I was missing some registry keys after all. Got it working now.
For anyone that is looking for an answer to a similar problem then the registry keys you need to make a 2003 VSTO addin load for all users should look something like this:
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}]
#="MyExcelAddin -- an addin created with VSTO technology"
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\InprocServer32]
#="Is vsdrvtEnvironmentString value type with "%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll" as its value"
"ManifestLocation"="C:\\Path\\To\\MyExcelAddin\\"
"ManifestName"="MyExcelAddin.dll.manifest"
"ThreadingModel"="Both"
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\ProgID]
#="MyExcelAddin"
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{MY-EXCEL-ADDIN-GUID}\VersionIndependentProgID]
#="MyExcelAddin"
[HKEY_CLASSES_ROOT\MyExcelAddin]
#=""
[HKEY_CLASSES_ROOT\MyExcelAddin\CLSID]
#="{MY-EXCEL-ADDIN-GUID}"
[HKEY_CURRENT_USER\Software\Classes\MyExcelAddin]
#=""
[HKEY_CURRENT_USER\Software\Classes\MyExcelAddin\CLSID]
#="{MY-EXCEL-ADDIN-GUID}"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}]
#="MyExcelAddin -- an addin created with VSTO technology"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\InprocServer32]
"ThreadingModel"="Both"
#="Is vsdrvtEnvironmentString value type with "%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\AddinLoader.dll" as its value"
"ManifestLocation"="C:\\Path\\To\\MyExcelAddin\\"
"ManifestName"="MyExcelAddin.dll.manifest"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\ProgID]
#="MyExcelAddin"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\Programmable]
[HKEY_CURRENT_USER\Software\Classes\CLSID\{MY-EXCEL-ADDIN-GUID}\VersionIndependentProgID]
#="MyExcelAddin"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Excel\Addins\MyExcelAddin]
"Description"="MyExcelAddin -- an addin created with VSTO technology"
"LoadBehavior"=dword:00000003
"FriendlyName"="MyExcelAddin"
"CommandLineSafe"=dword:00000001
Of course you will need to change GUIDs and paths to appropriate values. By Putting the addin keys under local machine instead of current user the addin will work for all users without having to repair the install after running excel for the first time. Also this only lets the office application know the addin is there and that it needs to attempt to load it, this does not give the assembly trust in the system, you need to use Caspol.exe to do that. Read the msdn article about SetSecurty to do this http://msdn.microsoft.com/en-us/library/bb332052.aspx.