Member Avatar for Eruditio
Eruditio 0 Newbie Poster

First of all, I realise there are a fair few related questions on many other sites, in addition to Microsoft Support pages. I have spent many hours on this issue, and this is where I stand and what I know/have been able to achieve:

  • I have an application written in Visual Basic Express 2010
  • There is an AxWebBrowser control in the main form
  • On computers with Excel 2010 installed (and running Windows XP), I've managed to get it working fine; I realised that I needed to change the registry so that the Excel documents would open within the AxWebBrowser instead of in a separate Excel window ()
  • On computers with Excel Viewer installed (and running Windows 7), the Excel documents continue to open in a separate Excel Viewer window
  • On the computers with Excel Viewer installed, there are eight additional registry subkeys with the names: ExcelViewer.Macrosheet.8, ExcelViewer.Sheet.12, ExcelViewer.Sheet.8, ExcelViewer.SheetBinaryMacroEnabled.12, ExcelViewer.SheetMacroEnabled.12, ExcelViewer.Template.12, ExcelViewer.Template.8, ExcelViewer.TemplateMacroEnabled.12
  • The fix given in on the aforementioned Windows Support page requires adding a new key in four subkeys (for Excel, not ExcelViewer) via "BrowserFlags"=dword:80000A00
  • I realise this value is a hexadecimal value. In regedit the Data value for these keys is 0x80000a00 (2147486208)
  • The hexadecimal value is different for Word, PowerPoint, and Excel in the aforementioned fix

I therefore assume there is a particular hexadecimal value I need in order to stop the Excel documents opening in a separate Excel Viewer window on those computers on which it is installed. I've tried using the Excel value 0x80000a00 in just .Sheet.8, .Sheet.12, .SheetMacroEnabled.12, and .SheetBinaryMacroEnabled.12, as per the fix for Excel. I've also tried putting it in all eight subkeys. None of this has worked, so I can only assume I need a different hexadecimal value.

I've scoured the net for a possible list of values that would help me with this, but to no avail. It seems this sort of information is kept under wraps. So now I'm appealing to all of you (and I hope this is the right section of the forum) in the hopes that somebody can provide a solution or at least point me in the right direction.

Many thanks for even reading this far - I realise that was quite a dense question. Any help would be greatly appreciated.

  • 1 Contributor
  • 0 Replies
  • 216 Views

Dani AI

Generated

— good, thorough troubleshooting so far. Short version: the registry “BrowserFlags” trick that forces full Excel to host inside an Internet Explorer/WebBrowser control is a compatibility workaround for older Office servers; newer Office/Viewer registrations use different ProgIDs and server registration patterns, and the viewer process often does not implement the in-place OLE interfaces the browser uses. Microsoft documents that 2007-era Office intentionally changed the default in‑browser behavior and that registry fixes are only a backward‑compatibility workaround (and affect all IE/WebBrowser instances). (learn.microsoft.com)

Practical diagnostic checklist (do these before editing anything):

  • Determine the actual ProgID your file extension maps to (assoc/ftype or check HKEY_CLASSES_ROOT.xls and follow its default). On 64‑bit Windows check both the 64‑bit and the 32‑bit registry views (the Wow6432Node/redirected view). (learn.microsoft.com)
  • From that ProgID, follow its CLSID into HKCR\CLSID{GUID} and inspect whether the class is registered as an in‑proc server (InprocServer32) or as a local EXE server (LocalServer32), and whether it exposes the usual “Insertable”/Active‑document entries. If it’s an EXE LocalServer or lacks Insertable/Active‑document registration, it very likely will not host in‑place and a BrowserFlags tweak won’t change that. (learn.microsoft.com)
  • If the class looks embeddable, apply the registry changes under the exact ProgID key in the correct hive (32‑ vs 64‑bit), back up the registry first, restart IE/your app, and test. Microsoft’s guidance explains that these registry edits are a compatibility workaround and require admin rights. (learn.microsoft.com)

If the Viewer process cannot host in‑place, practical alternatives are: deploy full Excel on the target machines; present documents as PDF/HTML previews inside the browser; or move to a modern host (for example embed web content with WebView2 and use Office for the web / an online viewer for interactive viewing). For historical embedding controls like DSOFramer note that Microsoft pulled/does not support those samples — they are brittle and not recommended for production. (docs.oracle.com)

Safety notes: always export the registry before changes, test on a non‑production machine, and use tools (assoc/ftype, Process Explorer/ProcMon, regedit) to confirm which binary is launched when a file is clicked. The root cause in almost every case is that the Viewer registers a different, non‑embeddable server — once that is confirmed, changing BrowserFlags alone will not make hosting work.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.