I have this project that I need to automate opening of IE(64bit) in MS Access 2010(64bit) vba.
I have no problem automating ie in a 32bit environment but not on 64bit. Has anyone ever have this requirement? I would love to know how did you do it.
setup:
- windows 7 64 bit
- MS Access 2010 64 bit
- ie 64 bit
Are you sure you're running the 64bit browser?
The default browser on 64bit Windows 7 is the 32 bit browser (because most 3rd party plugins are 32bit).
There should be a link somewhere for Internet explorer 64bit (if you type Internet explorer 64bit into the start prompt you'll find it).
Use the FollowHyperlink method:
http://msdn.microsoft.com/en-us/library/bb237946(v=office.12).aspx
Or otherwise you can use ShellExecuteEx
Related
I have win7 64 bit on my desktop and win7 32 bit on my laptop. I recently upgraded my php to 5.6.2 and amfphp to 2.2.2. As a result I had to modify several ActionScript 3 scripts to access my data. I got the scripts working on my 32 bit laptop, but they looked "fractured" on win 7 64 bit.
I know that the 64 bit flash player installer now installs both a 32 bit version and a 64 bit version of flash player.
Is there a way to specify that these AS3 scripts are to use the 32 bit flash player when launching with 32 bit Firefox on a 64 bit system?
An Adobe Staff member provided the following info and upon loading Firefox 54.0b6 (beta) I found that he was right. Most of my animations run as expected, although some of the games run with significant lag time on keyboard nav.
"Just for clarity, the bitness of Flash Player is dependent on the bitness of the host browser. If you're running a 32-bit browser on a 64-bit OS, you're still going to get the 32-bit Flash Player. The only case where you'll get 64-bit Flash Player at runtime is when you're running a 64-bit browser on a 64-bit operating system."
"I was able to reproduce this on Win7 x64 with Firefox 54.0b4 (32-bit), but upgrading to the latest beta - Firefox 54.0b6 (32-bit) seems to resolve it. I'm using the latest publicly available Flash Player (25.0.0.171) to test. For completeness, I'm also unable to reproduce the problem on Chrome or IE on Win7 x64, or on Firefox with MacOS 10.12."
"Mozilla has been doing a lot of work on their rendering pipeline, and I suspect that the behavior you're seeing is fallout from that. Since it's already fixed, it's just a matter of waiting for the changes to propagate to the release builds. They're on a 6-week cycle, so assuming those fixes get promoted in the next release, you should see them land relatively soon."
In my manifest xml file I have this setting, does it mean that only 64bit Windows10 installations do accept my package? My app is native 32bit, which setting is recommended to this field to make it work with both 32 and 64 bit os?
ProcessorArchitecture="x64"
I think if you set ProcessorArchitecture="x64" in your manifest xml file, the package just only was installed on the x64 Windows 10. But you can set
ProcessorArchitecture="x86" in the manifest, because this x86 package can all work fine on x86 and x64 Windows 10.
This answer based on VS C++, but the context is basically the same for manifests. Surprised to see that W10 X86 only installations actually exist, but they do, (or did), because, as the free W10 upgrade did not provide an option to change architectures, only a clean install would.
However, from an old Tom's Hardware post:
All processors since the Opteron in 2003 and the intel Pentium 4 Prescott ( the latter editions ) has 64bit instruction set and will all run 64bit windows.
Thus as long a MSFT continues to support 32 bit architecture, X86 is the safer option, although X64 would probably still work.
processorArchitecture='*'
covers all bases as well.
Microsoft's documentation says to use processorArchitecture="ia64" for Windows 64-bit builds; however, they do not follow their own advice. Microsoft uses "amd64" for 64-bit builds of WordPad.exe and iexplore.exe (Internet Explorer 64-bit) according to the embedded app manifest of these EXEs on my Windows 10 computer.
I have a fresh installation of windows 8 and I have installed visual studio 2012 and Windows Phone 8 SDK. I can successfully create projects and run them in the emulator but my emulator doesn't have internet access. At the first time i ran the emulator the prompt was given whether i want internet access or not. I selected yes but in have no internet access. I connect to the internet using a dongle. It works fine and connection has no problems as well. I cant seem to understand the problem, What are the solutions to this problem.
How long are you waiting from launching the emulator to trying to access the net? The emulator takes a little while longer than you would expect to set up a connection - is that the issue?
I am new to Selenium and writing my test cases only for firefox. I wish to write it also for Chrome driver. But where should I download for Widows 8 64 bit.
Have you tried with 32-bit Windows ChromeDriver here? What's wrong with it? If there are any errors, post full exception please.
As far as I know, there isn't a 64-bit Chrome on Windows yet (see this ticket), as a result, there is no ChromeDriver for 64-bit Windows.
Here 32/64 bit are in term of the browsers' architecture, not the OS. Please check if your Chrome 32-bit or not, if it's 32-bit, download the 32-bit ChromeDriver.
I am in the process of migrating my Access97 FE to 2003. For a while now I've been compiling both a 97 front end and a 2003 front end (97 for my XP machines, 2003 for my Win7 machines). Just recently (in the last week?).. I start losing my MSCOMCTL.OCX reference when converting. However, the odd thing is it only happens on my Windows 7 (32 bit) machine running Office 2003 (SP3). If I convert it on another Win7 64 bit, Office 2003 (SP3) machine I don't lose the referenced file.
I've registered/unregistered C:\windows\system32\mscomctl.ocx several times now (making sure to run command prompt as administrator).. and restarting. I've uninstalled Office 2003 on the troubled machine and re-loaded it to no avail. I've made sure C:\windows\system32 is in the path.. (it is)
If I compile the FE on my Win7 64-bit machine, and distribute it to this trouble machine it will not start the app properly (gets an initializing bar at the bottom) indefinitely. If I re-reference the file on the trouble machine and re-create an MDE it works on both the 32bit version and the 64 bit version of Windows 7 (even though the 64 bit has mscomctl.ocx in C:\windows\syswow64)..
Is something wrong with my Win7 32bit setup? I can take an older version of my FE (I keep a repo as I make changes) and those seem to not lose the reference. The FE in question compiles fine on my Acc97 machines and my Win7 64-bit machines. I used to compile all my 2003 FE's on the "now" troubled Win7 32bit machine... ?
I've run decompile/repair/compile/compact on the MDB file several times as well.
Can anyone suggest something to try?
UPDATE
Well I blew the "problem" workstation away and reloaded with Win7 Pro 64-bit, this will make WSUS duty easier anyway. However the problem persists... so now I'm not sure what to think.
You should confirm the version of MSCOMCTL.OCX used by your Access app is the same version used on any machine you might compile it on. Check which file the reference is using by:
Function ListReferences()
Dim a As Long
Dim b As Long
a = References.count
For b = 1 To a
Debug.Print b & ": " & References(b).Name & vbTab & vbTab & References(b).FullPath
Next b
End Function
This will give you a list of file names and paths for all references in your Access FE.
Use Windows Explorer to locate the MSCOMCTL.OCX referenced by Access. Right-click the file and note the version. Confirm the MSCOMCTL.OCX you are using on all other computers is the same version.
Maybe the MSCOMCTL.OCX on your machine was replaced by a newer version by an automatic Windows update?
At work, we had problems on some machines with this last week after the automatic installation of a certain update.
Quote from the "Known issues with this security update" section of the above link:
Windows Common Control-based embedded ActiveX controls may fail to load within pre-existing office documents, within third-party applications, and when you insert new controls in developer mode.
Apparently we were not the only ones having problems:
After installing KB2687441 Access forms utilizing components from MSCOMCTL.ocx fail to open