Download Activex For Windows 7 32 Bit

[Marketta Filipovich]

Ihave been running ArcGIS 10.5 on my PC (Windows 10 Home) since December with no issues. This past week I have started to get ActiveX Security Warnings when I click into a parameter field in any ArcToolbox tool.

I am working through the answers to Why do ArcToolbox tools give ActiveX error?, although there doesn't appear to be an actual answer on that Q&A. Additionally it's back in the Windows XP/7 days with IE 7/8, and I'm running Win 10 with IE 11 (although that's never used). If it matters, the browsers we use are Firefox 53.0 (64-bit) and Chrome 58.0.3029.81 (64-bit).

The issue I am having sounds different as it's happening only when I click on the parameter field - not when I open the tool or, as I read elsewhere, ArcMap. The warning messages on that Q&A also have different text so it may be a completely different problem.

I have opened Internet Explorer (for the first time since getting this PC!) and looked at the Local Zone settings and everything for ActiveX is marked Enabled, including one about running without prompting:

I went through the suggested ActiveX settings from Problem: Issues with ActiveX controls when launching ArcMap, updated all my settings to match (the only one I had to change was the "Automatic Prompting for ActiveX Controls" one I changed in my testing above).

I found a fix for this on ESRI's web site - axtiveX error warning. A staff member came into the thread and confirmed it is a bug in current versions of ArcGIS (at time of writing, 10.5.1 was the latest).

So far we have only seen it affect our 1703 users. Haven't tested on 1709, but I'm going to imagine it also affects them too. At my org we are not allowed to change security zone's as the other answer's states (policy for this setting is controlled far higher up the chain), but the link above has a workaround (or possibly actual fix?). I hear they are supposed to have this in 10.6.

Some of our users reported this issue to Esri Support a few weeks ago. We have reported this issue as a defect to our development teams. They are well aware and are investigating this issue at their end.

They link to their knowledge base article on how to fix it: Bug: Internet Explorer script errors are generated when running any geoprocessing tool from ArcToolbox on some systems that implement folder redirection

Essentially you need to copy their .xsl files into your arctoolbox folder, which for 10.5 (by default) is located at C:\Program Files (x86)\ArcGIS\Desktop10.5\ArcToolbox\Stylesheets. While the link to this page shows an error that looks very different from the one you describe it seems to be the same issue, just an old version of internet explorer. I confirmed it was working for a few of our users.

The one important difference that most suggestions omit, and very possibly this is all that's needed to fix this, is that in Zone 0 a new DWORD 1201 MUST be created if it doesn't already exist. In other words changing all the other DWORD values to "0" will not work unless 1201 is also added.

I see that a few posts were deleted from here; one that correctly identifies the problem as a recent windows update which it was, the other which states that adding the DWORD solves the problem. Perhaps, leaving correcting these posts to sound more like answer and not deleting them would have been a better approach since the actual accepted answer here is incomplete.

I've had to move a classic ASP application from windows server 2008 to Windows Server 2012R2 and the app uses a com object called (aspmail 4.0) from a company called ServerObjects - which is no longer in business (at least there's no way to contact them).

So I've actually come across this issue myself while migrating some old sites to Windows Server 2012 server and it appeared to be because of a dependency on cdonts.dll which was also known as Collaboration Data Objects for NTS (CDONTS) and was superseded sometime ago by Collaboration Data objects for Windows 2000 (CDOSYS).

Instead of writing the code, after a little research found it would be easier to just migrate the 32-bit DLL cdonts.dll from the old server to the new one and see if I can register it with the system, here are the steps.

I am having the infamous activeX warning appearing again with all my toolboxes in ArcMap 10.5, but only when I click in an empty field. This started only recently, and I think it may be linked with the recent Windows 10 Creators Update. I've tried the traditional solution of adjusting the Internet Options, but with no success. Is anyone else having this difficulty?

I haven't tried this registry edit, but I have to admit, I'm hesitant to edit the security settings just to get ArcMap to work 100%. I don't have the expertise to evaluate what that hack actually does and what risks it opens up.

well if you don't feel comfortable, that is reasonable. I am surprised that esri hasn't commented on this or had a flood of calls after the last windows roll out. Perhaps they are still investigating. It is annoying to say the least but not a game stopper.

The App is developed using PB 2022 R2. Installed as a service in the same machine.

Chilkat installed in the same machine using the batch file provided. Since the app is 32 bit, I installed the activex using the register_x64.bat. Since it failed, I tried with register_win32.bat. Both failed. I used nssm to install and run the service application.

Found the issue. Actually when I tried to run the batch file in Administrator mode, it got executed with no error message. With no error message, I thought the registration has succeeded, seems that's not the case.

Then I typed out the contents of the batch file in the DOS prompt, as an administrator, it got registered and everything is working fine.

While I never tried to use an active-x inside a service, I have used com objects inside a service. The service was created in c#... At the time I used a com object (providing some sync functionality for ftp), and a PB.NET assembly used to process data received from ftp. Active-x and com isn't the same but have similarities so I guess it should work. I remember that after some upgrade I had issues with the com object I was using, and I had to change some settings using mmc and it's component services snap-in. Also, my service was running under a specific user and this may be an important point.

If your active-x doesn't use gui, it should work. Actually, since you are using nssm to create your service, your pb exe has nothing specific or different than when executed as a normal executable. What changes is the environment where it's called, and the fact that a service won't show you any information (windows, messagebox's etc). That said, you should implement good error handling and logging to be able to see what's happening.

3a8082e126