Re: test whether ocx is registered from VB, possible?

Microsoft doesn't follow the KISS standard. <g>

For instance...
An ActiveX dll may NOT register itself simply by doing:

regsvr32.exe AnyAxFile.dll

Change the AnyAxFile.dll name to an appropriate filename.

Certain Microsoft DLLs seem to have dependencies upon
other DLLs, and those other DLLs may have dependencies
upon other DLLs. I believe I might have run across an .OCX
that worked in the same manner. Also, Microsoft seems to
sometimes rename .DLLs with another extension. I found
that on some old installation routines. If anyone is interested
in a Word 97 Viewer installation fix... to prevent it from
searching through 2KGB of hard disk to find a previous
install... 2KGB meaning 2000GB.

I think the Microsoft VBE DLLs work in this manner. I also,
think I've seen such things with some Microsoft Access DLLs
due to a recent problem with Access whereby every time I
started up Access, it started to automatically reinstall itself.
For instance, I created a Test.mdb, and then double-clicked
upon it. Access started itself up but also started showing a
dialog everytime it started up, stating that it was reinstalling
itself. That continued for about a week. I'm pretty sure that
moving Access out of the default install location caused the
problem. In fact it runs fine right now, and it's not installed
the %ProgramFiles% area.

Does anyone know if there is a tool out there that will
track down ALL the dependencies, register all the
dependencies and then finally register the last DLL?

Sounds like that would be a really cool tool to have, heh?

--
Jim Carlock
Please post replies to newsgroup.

"mayayana" <mayaXXyana1a@xxxxxxxxxxxxxxxx> wrote:
--
--
Some Fred <bla@xxxxxxx> wrote:
> On Mon, 18 Jul 2005 16:36:40 -0700, "Sam Hobbs"
> <samuel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >I thought that ActiveX components are supposed to support clients using
> >prior versions. Also, if version is a possible problem, we are supposed
to
> >specify a version when we create the object, right? Finally, multiple
> >versions of components are supported.
>
> I'm not a COM/ActiveX expert, but at any rate, some installers don't
> check whether a previous, newer version of an OCX is installed, and
> will replace it with its own. If the two files have the same name (eg.
> COMCTL32.OCX), it will effectively break all the apps that dependend
> on the newer version.
>
> As to why no one at Microsoft seems to have foreseen the problem, and
> didn't provide a way to let different versions of an OCX coexist is
> beyond me... Did they really expect all installers to be nice to each
> other?

Why not? It doesn't seem too much to expect that
an installer should check for a prior installation. That's
not Microsoft's or COMs fault. (Though the only installer
I know of that's ever acted that way was Microsoft's!. I've
seen them install older Win95 files on my Win98 system.)

And a COM object is *supposed* to be designed compatible
with former versions. That's a basic premise of COM, not
a best-case scenario. If the newer version is not compatible
that's just a bug. If it's not compatible it should be given a new
file name with new ProgIDs and CLSIDs.

I'm not familiar with the new "side-by-side" feature mentioned,
but in general an ActiveX control will have a CLSID for any
creatable class in it, and may have a ProgID. On my system
I can't find any cases of multiples. I find keys like:
HKCR\MSComDlg.CommonDialog.1 and
HKCR\MSComDlg.CommonDialog
The latter has a CurVer subkey. Both have a CLSID
subkey that points to the same HKCR\CLSID\[CLSID-number]
key. The file location is under the InProcServer32 key.

There is no HKCR\MSComDlg.CommonDialog.2 or
anything like that. In other words, there seems to be no
provision for multiple versions, with different CLSIDs,
being referred to from the same ProgID. I don't see any reason
why later control versions can't have a different CLSID, and the
HKCR\Typelib key is already designed to accomodate
different versions, but I don't think it's possible (at least on
Win9x) for two versions to share the same ProgID.




.

Relevant Pages

  • Re: From VC6 to .NET 2 questions
    ... This is because Microsoft rather carefully ... >> specifies what DLLs ... >the resulting installation issues and deployment size, ... lots of people get away with blatant violations of the installation guidelines. ...
    (microsoft.public.vc.mfc)
  • Re: SBS 2003, lost companyweb
    ... Microsoft CSS Online Newsgroup Support ... This newsgroup only focuses on SBS technical issues. ... The original Windows SBS installation was preinstalled by an OEM. ... Important You must change this registry entry on all domain controllers. ...
    (microsoft.public.windows.server.sbs)
  • Re: needs automated clean-up tool [Re: Office 2007 beta uninstall]
    ... for both us and the customers. ... to get rid of every trace of Office 2007 beta, but that wastes a great deal ... We really have to wonder if any of those representing the Microsoft line on ... Why is it so hard to understand that we expect the Microsoft installation ...
    (microsoft.public.office.setup)
  • RE: Fatal Error Installing XPsv2 Deployment for SBS sv1 Upgrade
    ... 825763 How to configure Internet access in Windows Small Business Server ... Microsoft CSS Online Newsgroup Support ... >> 325.547: Fatal error during installation. ...
    (microsoft.public.windows.server.sbs)
  • RE: Installation problem with companyweb
    ... Microsoft CSS Online Newsgroup Support ... | Thread-Topic: Installation problem with companyweb ... you need to send him a copy of the folder from your ...
    (microsoft.public.windows.server.sbs)
Quantcast