Excel form using DTPicker2 control is broken on single machine after moving to Win10 - excel

I have an Excel file that contains VBA code and user forms.
One machine has been migrated to Windows 10. The Excel major version hasn't changed though (16). One of the forms lost almost all the controls on it and the user is getting
Compile error: Method or data member not found
at the line Me.cmbWeek.ListCount.
It looks as if this control is not existent in the file on that machine. I wouldn't say it is Windows10 incompatibility as some other machines migrated to Windows 10 flawlessly.
How can I debug what's wrong? The file has worked for years on several machines including the machine of this user (until on Win10). Checked references and there's nothing missing.
The form on user's machine (broken).
The form on on all other users' machines (proper).
I cross-posted to other forums:
excelforum.com
mrexcel.com
ozgrid.com
We managed to trace the problem to the DTPicker2 control on the form. It is part of MSCOMCT2.OCX library. It is present on user's machine, the same as on mine. That machine is version SP4 of the file whereas all other machines have SP6.
I can see that Excel reference points to some other destination than C:\Windows\SYSWOW64 - it points to other app's install path. Probably other app changed something in the registry.
When trying to uncheck the SP4 reference and load SP6 reference I get error
"Can't change references, in use".
Reinstalling office and registering MSCOMCT2.OCX did not help. As it's only two controls causing the issue - or so it seems - I'm now into replacing them with other date picker controls if there are any. If not, I might even use plain textboxes, though it wouldn't be very good solution. Are there any other controls that could handle calendar?

Do check if the region settings on the PC with Win10 the same as on the older PC's.
Changes in date formats, dots vs comma's, etc. can hugely impact VBA's ability to tinker company processes together.

Related

microsoft.ace.oledb.12.0 provider is not registered even already install

i just want to ask about Visual studio doesn't detect my microsoft.ace.oledb.12.0..
last month i write a code to import from excel into database using VB.NET and it worked..
but after a month i open back my coding and try the system but it said that "microsoft.ace.oledb.12.0 provider is not registered" even though i already install microsoft access database engine 2010 before..
i never change a little bit of my coding..i just left it but now it doesn't work like before
is there any particular update or something that make it doesn't work??
thank you
Try changing your target cpu in your project properties. go to solution explorer<properties<Compile uncheck the prefer 32-bit or change to x64. It works for me, if it doesn`t work try searching a bit more iirc that question is already answered but i cant remember if it is in stackoverflow or other website, which has many suggestions
The Access engine can be installed as either 32-bit or 64-bit. As the other answer notes, it is important to make sure that your application matches the bitness of Access. You can check on installed OleDB providers by checking the Windows registry; you would need to search on all of the keys in HKCR/CLSID (under Wow6432Node for 32-bit), looking for entries with a value named OLEDB_SERVICES. Keys with this value will have the provider name as the default value. This (obviously) isn't practical to do manually, but it should be fairly straightforward to do programmatically.

Excel TFS Add-In Crashes Connecting to TFS

We frequently use Excel to perform bulk updates of data in TFS. Up until very recently, the Team Foundation Add-In has worked very well. However, it has started failing in several ways:
It will connect to the server, but attempting to connect to any
project causes Excel to crash, producing a Watson report in the
Windows Application Event Log.
If I restart Excel, it reports that it is running into problems with
both the shim and the add-in, and offers to disable it. If I do not
disable it, I still can't connect to a project.
Eventually, the add-in refuses to load at all, until I use the
Options dialog to manually add the COM add-in back into the
application. Doing so produces the same results (Excel crashes when
attempting to load a project).
I have taken the following steps in an attempt to resolve the issue:
Removed and completely reinstalled Office.
Re-registered the add-in component.
Uninstalled and reinstalled Team Foundation Office Integration.
None of these have produced a fix to the issue.
Does anyone know how to resolve this issue?
P.S. If this is not the correct "stack" for this question, kindly point me to the correct one on the exchange. Thank you.
If you are reading the accepted answer and it still isn't working, here's an additional tip. I had the EXACT same problem and saw that same link to clear the cache from numerous sites, bit it didn't work.
Here's the thing. I don't think that article lists ALL of the places that cache can be hiding on your machine. I deleted the cache folder in two different places on my machine and had given up on that as a solution.
Then I searched my entire hard drive for any folder with "Team Foundation" in the name and found a couple more buried in other hierarchies. Deleting these FINALLY solved the problem.
Here are some folders to look for, but like I said, check the entire drive
c:\users\yourlogin\AppData\Local\Microsoft\Team Foundation
c:\Program Files\Common Files\Microsoft shared\Team Foundation Server\
c:\users\yourlogin\AppData\Local\Temp\Microsoft\Team Foundation
The actual cache folder will be nested another level deep under a numbered folder named with something like "7.0" or "8.0" delete the cache folder from every one you find under every number.
In general cleaning the caches on your client machine will resolve such problems, including the TFS and VS caches...
To clean the caches, please see How to clear the TFS cache on client machines

IManage Filesite 9.3.1 throws 'The system cannot find the file specified error' when checking documents out in Windows 10

I have a newly built windows 10 machine. We have a ActiveX control that hooks into Imanage and opens a requested document. On my old machine this ActiveX control worked as expected but on the new PC I am getting a Imanage error dialog.
One or more documents could not be checked out. The operation could not be performed on these document(s). The document XXX could not be checked out. The system cannot find the file specified.
I am using IE 11 with the same security settings. As I am getting an Imanage error, that implies that the ActiveX control is working thus Imanage is the issue?
I am using Filesite 9.3.1 on both machines. I am not an expert on Imanage and how it works so I could be missing something simple.
There are two reasons that this could be happening:
As already mentioned by Yevgeny, the NRT locations may be invalid, the locations are stored in the registry at:
NRTEcho:
HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\Common\General\Echo
NRPortbl:
HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\Common\General\Portable
though this may be different based on your individual iManage implementation.
If this issue is only occurring on certain documents, one's that are created via a script for example. It may be that the files are zero kilobyte. Have seen this happen before when documents are being dynamically created from sharepoint templates.

FileSystemWatcher no longer has old filename in some Windows 7 machines

This one is too bizarre for me. In my Framework 4.0 WinForms app, FileSystemWatcher recently started giving me a null for OldName and only the parent folder for OldFullPath, not the full path of the old filename. However, some of the Windows 7 computers do this while others do not. I tried uninstalling our company anti-virus program temporarily but that didn't make any difference. I rolled back my code but it didn't make any difference.
I tried switching my application from Framework 4.0 to 4.5.2 but the problem persisted. In fact, I believe the problem is at a lower level than .NET because I wrote a test C++ program that uses ReadDirectoryChangesW() and a similar problem occurs: the problem computer never receives the FILE_ACTION_RENAMED_OLD_NAME notification, only the FILE_ACTION_RENAMED_NEW_NAME one.
I compared running processes and ended ones that are running on the problem computer but not on the non-problem one. Both computers are up to date with Windows Updates; I am hoping not to have to start uninstalling them.
I have one Windows 8 computer and the problem is not there; however, upgrading from 7 to 8 is not an option for several other deployments.
It just occurred to me to look at kernel32.dll on the respective machines, since that is where ReadDirectoryChangesW() lives. It's different.
Worky: v6.1.7601.18798
No worky: v6.1.7601.18869
Was there a recent change to the API that I need to accommodate?
Update: I found a non-working machine with v6.1.7601.18409 so that's not the problem.
In a word, Kaspersky.
To elaborate, I thought I had already tested removing KAS but maybe I didn't reboot after or something, and it's odd because it is also installed on a computer at work that does not present the problem--same version of KAS.
Note that this version is a corporate version, which installs:
Kaspersky Endpoint Security 10 for Windows
and
Kaspersky Security Center Network Agent
A central policy is pushed out to each client computer and enforced. It has control over settings, like trusted applications (a whitelist). When IT pushed out a whitelist entry for my specific application, it fixed the problem.
Note that there are several checkboxes to select for each trusted application entry. This fix only needed one of them.
Under Settings | Anti-Virus protected | Exclusions and trusted applications | Settings, there is a list that can be added to.
Do not scan opened files
X Do not monitor application activity
Do not inherit restrictions of the parent process (application)
Do not monitor child application activity
Allow interaction with application interface
Do not scan network traffic
Honourable mention must go to my co-worker, Arti Chauhan, who suggested more than once that KAS might be the problem. I thought I had fully tested when I guess I hadn't.

Can't add a picklist to a form

I've created a field picky but when I try to actually put in onto the form of my entity, I can't. I'm pulling it out hovering over a place to set it but the red line marking the drop-off spot doesn't show.
I remember very clearly it did in my last Project. In fact, I went back to the previous customer's GUI and tried the same and it worked there. I suspect it might have to do with the different versions. The customer runs on-premise (4.0 or 2011), the new project is on-line (2011) and I wonder how it's going to be in the next version (2013).
What can be causing it?
What can I do about it?
Incompatibility in IE 10.
(a) Run IE9/IE8 (works always).
(b) Try to run IE10 in backwards compatibility mode (works often).
(c) Wait for an update for CRM/IE10 (works slowly and seldom).
As a side note, I can tell that when I was having that issue, I noticed that by using a remote desktop to our development environment (or at least a virtual machine, e.g. VirtualBox, wouldn't you have access to an external environment), one could omit the whole issue sans having to degrade to an earlier version of IE.

Resources