At this moment I'm working on a MS Access database, and I have difficulties with the library MSCOMCTL.OCX.
The problem is the following: given Windows 7 x64, Microsoft Office 2010 x64 and MSCOMCTL.OCX v6.1.98.34 (which was registered with the help of regsvr32 in the folder SysWOW64), I can't use the TreeView (MsComCtlLib.TreeCtrl.2 class) present in some forms of the database. Every time the code approaches any TreeView's (read, Node's) property, I receive the following message:
"Object doesn't support this property or method" (Error 438)
while in Windows 7 x32 the database works fine.
Trying to understand what's wrong, I discovered that the library Microsoft Windows Common Controls 6.0 (SP6) exists in the list seen in the 'References...' dialog and is checked, but I don't see Microsoft TreeView Control 6.0 in the list of available ActiveX Objects when I'm in the Constructor mode.
Following some solutions found in the Internet, I executed regedit.exe and saw that there are two "folders" in the path HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}, "2.0" and "2.1". Besides, the path to the file MSCOMCTL.OCX is in "2.1", while "2.0" is not also empty - it contains PrimaryInteropAssemblyName property for example, which isn't present in "2.1".
So, what should I do to make TreeViews in my database work? As I've mentioned before, I saw some solutions, but I'm afraid to use them because the computer, where the database is in, is not mine and it's undesirable to make the changes, which can affect security of the system.
The version of MSCOMCTL that is installed by default is not 64-bit compatible. You're unfortunately out of luck. No amount of modifying the registry is going to make a 32-bit only control work in 64-bit office.
However, MS apparently includes a 64-bit compatible version of MSCOMCTL with Office 365 ProPlus installations (source). You can consider buying that, or obtaining it through other means.
Related
Lately I am having some very weird problems and I can't exactly pin out what is causing it.
I've got an Access frontend application which uses SQL Server linked tables. A few days ago I deployed a new ACCDE version which caused some very weird problems.
At one computer I was unable to open a form from the Ribbon (some 21~ ish error can't exactly remember but it was a default open-form error). After some investigation I found out that the problem is caused by an allow additions = false line on the on-open event of the form. This however is very strange since it has always been there. Besides that, at almost every other computer, including mine, it just works fine while the code (and forms, queries, etc.) are exactly the same..
When trying to open the same access file in accdb at that specific computer it does seem to work (opening being done with runtime version).
So as workaround (for the time being) we made sure that that this computer opened the file as accdb while the others (where it did work) opened it as accdde.
Today however it went wrong again but on a different computer and a different issue. Now a completely other form doesn't load it's data (it's empty). Testing it locally it works fine however and testing it yet again on another computer (with also a runtime version) it also opens fine with data in it...
The weird thing is when using an older file (a few application versions back) just works fine but the current one doesn't, at least not on all computers. This makes me believe that the file is corrupted but the weird thing is, why DOES it work on some other computers? If the file would be corrupted you would say that it is causing the issues on all the computers?
So the next thing I thought of was different Access runtime versions. I tested 4 computers (two where everything works fine) and the other 2 have issues.
Computer one (which works fine) is a 32 bit system with Access runtime version 15.0.4841
Computer two (with issues) is a 64 bit system with Access runtime version 15.0.4569
Computer three (also with issues) is a 32 bit system with Access runtime version 15.0.4833
Computer four (my own computer tested against a local db) is a 64 bit system with Access runtime version 15.0.4849
So the computers where the Access file doesn't work all have a lower version than the ones that do work, is it possible that this is causing the problem?? If it is, I still wonder why the older Access application file works on all computers but the current one doesn't..
On a side note:
Also tried to repair the access runtime version on one of the computer where it didn't worked but this had no effect
Doing a Compact & repair on the Access file itself also doesn't have any effect
Well, you plain and simple cannot run an x32 accDE database with the x64 bit runtime – it simply will not work.
And if the runtime versions are different on those target machines then you want to un-install the runtime, and download the latest version. Windows update will NOT update the runtime. With runtime 2010, you had to download + install runtime, and then ALSO download an update to the runtime.
With 2013, then the latest download of the runtime will always include the latest SP updates.
Attempting to run Access with different runtimes will in general be a disaster. And in the case of attempting to use the x64 bit runtime on an application compiled to x32 will not work at all.
I would also before you compile to an accDE check and remove any and all references not required. So references to word, excel or anything else should be removed and late binding should be used.
Regardless, you want to ensure that all computers are using the same runtime version, and this includes the bit size. So in all cases you want to ensure and use the x32 bit runtime, and then ensure that all machines are running the same version/revision of the runtime.
In my Windows Store Application, I am getting the error:
Cannot find type System.Windows.Media.AudioSink in module System.Windows.dll
I tried to add a reference to it, but I can't find an assembly list in my project's references.
My system:
OS - Windows 8.1
IDE - Visual studio 2013
The .NET Core for Windows Store Applications does not include all of .NET 4.5 (nor 4.5.1). It is a subset of it, meaning that not all classes are included. It also has some classes specific to it.
If you want to do audio, you should look into the Getting Started with Audio and Video tutorial that Microsoft created for this very purpose.
Also, in the future you should probably include what language you are using. There are multiple languages that Windows Store Apps can be created in (C#,C++/XAML, Javascript/HTML), and it helps to know that.
I'm trying to hash a password in ms access (preferably MD5 or SHA-1). I found Capicom, which worked great at school on windows XP. However, at home Access doesn't seem to want to recognize it. Is there any alternatives that I can use which will work on both XP and Windows 7 that doesn't involve adding external library?
And if an external library is required, how can I add this into the VB code for my database.
Thanks.
e: anything that needs to be installed, eg a .dll file, is out of the question as I wont be able to use it at school (My issue is finding something which will work at home and at school so I can effectively work on my project)
CAPICOM redistributable; http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=25281 - Note that its 32bit only
I am maintaining a legacy Microsoft Access application that is using the Microsoft Flexgrid 6.0. It recently started causing the following error:
Run-time error '438' Object doesn't
support this property or method
People say that this error can be caused by the KB960715 security update being applied, which sets killbits on various ActiveX control methods which were deemed a security risk. But this or no other security update has been applied recently.
Others say that installing Microsoft Visual Basic 6.0 Service Pack 6 Cumulative Update will update the flex grid. This requires VB6 to be installed as a prerequisite so I installed that on my PC and then the update, and retrieved the updated MsFlxGrd.ocx file(Version: 6.1.98.12) and copied to the application machine, but the error still prevails.
Someone here says you can disable the killbit in the registry. But there are afew hundred nodes in the location they suggest, none of which has the same guid as the one they point out.
Any ideas?
I'm using the Crystal Reports Viewer 11 ActiveX control in an Access form (version 2007, 2003 format). Everything works well on my development machine, where I have CRXI installed. I copied the referenced DLL to the client's machine, but when I try to register it, it says "Can't find module" (I double- and triple-checked my spelling) and when I try to open the form it tells me "ActiveX component can't create object" when the code tries to create a new instance of the report object. I suspect there are more dependency files required by the DLL, but I'm a little at a loss as to what ones and how I go about finding out. Although I'm using the CR control, I assume this would apply to any ActiveX control throwing this error. Thanks.
There should be a runtime distribution document in your Crystal Help files - from past experience (Crystal 8.5) there are multiple files that you have to distribute and register.
I'm answering my own question in case someone finds this via a search in the future. I don't have the Access Package & Deploy wizard David mentioned above (okay, I probably have it but couldn't find it readily) but I image it would probably do what I needed, so I recommend anyone try that first. Instead, I was able to create a setup to install tghe needed files using the Visual Studio Installer and the Crystal merge modules; note that while it wasn't difficult, nor was it pleasant.
I downloaded and installed Visual Studio Installer 1.1 from MSDN. This creates a new project type in Visual Studio 6.0 (in particular, I used InterDev 6.0) that creates a Windows Installer (*.msi) setup file. Because one of the Crystal merge modules requires the Crystal license key and VSI doesn't support merge module parameters, I also had to use Orca, a merge module editor, available from the Microsoft Windows SDK (also available on the Microsoft download site). I recommend reading through the SDK and Orca pages on MSDN for more info. Using Orca, I was able to put my key code and recompile the merge module, so I don't have to deploy my key to my users, and my users don't have to enter one.
Again, the Package & Deployment Wizard is probably a better option, but when faced with using merge modules, as with Crystal, this method will get the job done.