What's the reason for comctl32.dll + comctl32.ocx in Win7 SysWOW64 folder?

[GS]

I see both subject components listed in the SysWOW64 folder on my Win7
machines. I assumed on my Win7 Pro machine that the ocx was there
because I installed VB6.

I also see this on my Win7 Home Premium machine but have no idea how
they got there. I thought MS excluded the ocx version as of Win6.0 and
so hope someone can explain why they exist on Win7. My guess is that
the SysWOW64 folder may persist these components for use by x86 apps.

I do not see the OCXs in System32 folder of either machine, but this
makes sense since x64 versions of the OCXs don't exist (AFAIK)!

Also, is it possible for VB6 apps to use the SysWOW64 DLL version and
if so, how to?

[MikeD]

Post by GS
I see both subject components listed in the SysWOW64 folder on my Win7
machines. I assumed on my Win7 Pro machine that the ocx was there because
I installed VB6.

Quite possibly. Or something else installed them.

Post by GS
I also see this on my Win7 Home Premium machine but have no idea how they
got there. I thought MS excluded the ocx version as of Win6.0 and so hope
someone can explain why they exist on Win7. My guess is that the SysWOW64
folder may persist these components for use by x86 apps.

Same as above. Some other application could have installed them. They do
not ship with, nor are installed by, Windows itself. But many applications
even from MS use them and therefore install them. I have no idea what you
mean by SysWow64 persisting them. They get installed by an application,
plain and simple.

Post by GS
I do not see the OCXs in System32 folder of either machine, but this makes
sense since x64 versions of the OCXs don't exist (AFAIK)!
Also, is it possible for VB6 apps to use the SysWOW64 DLL version and if
so, how to?

You mean call into the Common Controls DLL directly? Sure. I do that for
the MonthView and DTPicker controls since they're not included with the VB5
version of the Common Controls 2 OCX. I never use the VB6 versions of any
of the common controls OCXs. Basically, you use CreateWindow (or
CreateWindowEx) to create the control, set styles either when creating the
control or by using SetWindowLong or however documented in MSDN Library (for
example, extended styles are usually set by sending a message with
SendMessage), use SendMessage to send messages to the control, and subclass
either the control or its parent to receive messages and notifications such
as WM_NOTIFY. Typically, you'd raise events for these but not always. If you
do some searches, you should have no problem finding example code.

Mike

[GS]

Post by MikeD

Post by GS
I see both subject components listed in the SysWOW64 folder on my
Win7 machines. I assumed on my Win7 Pro machine that the ocx was
there because I installed VB6.

Quite possibly. Or something else installed them.

Post by GS
I also see this on my Win7 Home Premium machine but have no idea
how they got there. I thought MS excluded the ocx version as of
Win6.0 and so hope someone can explain why they exist on Win7. My
guess is that the SysWOW64 folder may persist these components for
use by x86 apps.

Same as above. Some other application could have installed them.
They do not ship with, nor are installed by, Windows itself. But
many applications even from MS use them and therefore install them. I
have no idea what you mean by SysWow64 persisting them. They get
installed by an application, plain and simple.

Post by GS
I do not see the OCXs in System32 folder of either machine, but
this makes sense since x64 versions of the OCXs don't exist
(AFAIK)!
Also, is it possible for VB6 apps to use the SysWOW64 DLL version
and if so, how to?

You mean call into the Common Controls DLL directly? Sure. I do
that for the MonthView and DTPicker controls since they're not
included with the VB5 version of the Common Controls 2 OCX. I never
use the VB6 versions of any of the common controls OCXs. Basically,
you use CreateWindow (or CreateWindowEx) to create the control, set
styles either when creating the control or by using SetWindowLong or
however documented in MSDN Library (for example, extended styles are
usually set by sending a message with SendMessage), use SendMessage
to send messages to the control, and subclass either the control or
its parent to receive messages and notifications such as WM_NOTIFY.
Typically, you'd raise events for these but not always. If you do
some searches, you should have no problem finding example code.
Mike

Thanks, Mike, for confirming use of the DLL version[s]! I'll followup
with your link as a start...

[GS]

Sorry, Mike! It was Ralph who provided a link. In respect of your
suggestion to search for example, I'll invest in that now that I know
it's doable!<g>

[ralph]

Post by GS
I see both subject components listed in the SysWOW64 folder on my Win7
machines. I assumed on my Win7 Pro machine that the ocx was there
because I installed VB6.
I also see this on my Win7 Home Premium machine but have no idea how
they got there. I thought MS excluded the ocx version as of Win6.0 and
so hope someone can explain why they exist on Win7. My guess is that
the SysWOW64 folder may persist these components for use by x86 apps.

The short answer to why the files are there is Microsoft's "It just
works" policy towards classic VB.

Post by GS
I do not see the OCXs in System32 folder of either machine, but this
makes sense since x64 versions of the OCXs don't exist (AFAIK)!
Also, is it possible for VB6 apps to use the SysWOW64 DLL version and
if so, how to?

Because when running a 32-bit application the SysWOW64 folder is
"system32" to the 32-bit application.

For a longer explaination take a look at
http://en.wikipedia.org/wiki/WoW64

-ralph

[ralph]

On Thu, 08 May 2014 15:30:54 -0500, ralph <***@yahoo.com>
wrote:

What I should have said ...

Post by GS
Also, is it possible for VB6 apps to use the SysWOW64 DLL version and

Yes, because when running a 32-bit application the SysWOW64 folder is
"system32" to the 32-bit application.

Post by GS
if so, how to?

By basically ignoring the folder name and use them exactly as you did
when developing on a 32-bit platform. Let the O/S do its magic. <g>

For example:

If an install package for a 32-bit application (running on a 64-bit
platform) attempts to install a component in the "System32" folder it
will actually be installed in the SysWOW64 folder.

If you install and register a 32-bit component in the SysWOW64 folder
when you open up Project References in the VBIDE you'll "see" the
component as available.

If you create a Function Directive in VB and provide the library's
location as in "System32" it will be found.

etc, etc.

[GS]

Post by ralph

Post by GS
I see both subject components listed in the SysWOW64 folder on my
Win7 machines. I assumed on my Win7 Pro machine that the ocx was
there because I installed VB6.
I also see this on my Win7 Home Premium machine but have no idea how
they got there. I thought MS excluded the ocx version as of Win6.0
and so hope someone can explain why they exist on Win7. My guess is
that the SysWOW64 folder may persist these components for use by
x86 apps.

The short answer to why the files are there is Microsoft's "It just
works" policy towards classic VB.

I was thinking it has to do with the fact MS still includes the VB
runtime DLL, but Mike D's explanation makes sense.

Post by ralph

Post by GS
I do not see the OCXs in System32 folder of either machine, but this
makes sense since x64 versions of the OCXs don't exist (AFAIK)!
Also, is it possible for VB6 apps to use the SysWOW64 DLL version
and if so, how to?

Because when running a 32-bit application the SysWOW64 folder is
"system32" to the 32-bit application.
For a longer explaination take a look at
http://en.wikipedia.org/wiki/WoW64

I'll followup this link...

[ralph]

Post by GS

For a longer explanation take a look at
http://en.wikipedia.org/wiki/WoW64

I'll followup this link...

Also be sure to follow up with the URL's under "External Links". Lots
of additional interesting (or not <g>) information, but in reality
once you get your head around the fact that "WOW64" is actually
"32-bit Stuff" - it's all pretty much business as usual. <g>

-ralph

[GS]

Post by ralph
Also be sure to follow up with the URL's under "External Links". Lots
of additional interesting (or not <g>) information, but in reality
once you get your head around the fact that "WOW64" is actually
"32-bit Stuff" - it's all pretty much business as usual. <g>
-ralph

That's pretty much been my understand in general, though your link does
make for interesting reading!<> My object here is to primarily find out
the diffs between using the ocx/dll versions.

Also, this isn't for my VB6 apps since I use a manifest and ship the
controls (download, actually) with my installer. It's for use with my
Excel VBA apps that use a listview control. I like to keep the code as
near as possible such that it's useable in both VBA/VB6 but that's a
minor consideration with particular control.

I looked into using the dll version on Mike D's suggestion, but find
going that route not feasible for VBA projects. That concludes, then,
that I may as well download the control at startup if/when needed and
do a silent reg for runtime, silent unreg at shutdown. I've found
different ways of doing that back before I started using a manifest. I
don't know, though, which is the better way to go and so would
appreciate any advice/suggestions! Here's what I'm doing now...

Shell "regedit /s- """ & gsAppPath & "DsoFile.dll"""""

OR

Shell "regsvr32 /s- C:\Windows\System32\dwProp.dll"

..depending on where the lib was installed to. But these are DLLs and
so I believe my only choice for OCXs is regsvr32. Currently, I install
all libs to the "Deps" folder of my app's main folder. Before using
manifests I was letting the installer handle reg so it's included in
uninstall (which IMO is a bad idea anyway)

To unregister I'm having to enum the registry key's subkeys, delete the
entries, then delete the reg key. Surely there's a way to silently
unreg as easy as what I used to reg! A bit of googling revealed the /u
switch and so I'm thinking to go with...

Shell "regsvr32 /s- """ & gsAppPath & "comctl32.ocx"""""

Shell "regsvr32 /u """ & gsAppPath & "comctl32.ocx /s"""""

..because it doesn't require much code. I've seen the unreg line with
and without the silent switch but not sure why it's at the end. I also
have no idea why the reg line silent switch has a hyphen. I'm hoping
someone can educate me on this or point me towards some good
documentation on Shell cmd line syntax.

I haven't ruled out using DllRegisterServer/DllUnregisterServer...

[GS]

After much googling I'm probably going to go with...

Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /s"
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /u /s"

..if/when an attempt to 'Load' the userform throws an error. This will
also obviate screwing things up if someone else has registered the
control. (My intent is that it only be available during runtime of the
VBA project if not existing on the host machine)...

loadDF:
On Error GoTo instOCX
Set DF = New fDataFormLV
If Not DF Is Nothing Then DF.Show vbModeless: Exit Sub

instOCX:
Call RegOCX
'Just do once
If iNum = 0 Then iNum = iNum + 1: Resume loadDF _
Else MsgBox sMsg, vbCritical

..and on shutdown...

Call RegOCX(False)

..where RegOCX(Optional LoadOCX As Boolean = True) uses Dir() to see if
the ocx exists in the path and if not found it returns False. It
returns True on success.

Just trying to keep it simple...<g>

[ralph]

Post by GS
After much googling I'm probably going to go with...
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /s"
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /u /s"

The location "gsAppPath" is a tad disturbing. Is this a placeholder or
an actual new location (copy)?

Post by GS
..if/when an attempt to 'Load' the userform throws an error. This will
also obviate screwing things up if someone else has registered the
control. (My intent is that it only be available during runtime of the
VBA project if not existing on the host machine)...
On Error GoTo instOCX
Set DF = New fDataFormLV
If Not DF Is Nothing Then DF.Show vbModeless: Exit Sub
Call RegOCX
'Just do once
If iNum = 0 Then iNum = iNum + 1: Resume loadDF _
Else MsgBox sMsg, vbCritical
..and on shutdown...
Call RegOCX(False)
..where RegOCX(Optional LoadOCX As Boolean = True) uses Dir() to see if
the ocx exists in the path and if not found it returns False. It
returns True on success.
Just trying to keep it simple...<g>

It sounds like you are developing a shrink-wrap App for release into
the wild. If so, while I can appreciate this may seem simpler, you
might want to reconsider and use a proven Side-by-Side technology
(Manifest, Reg-Free). It will actually be 'simpler' in the long run.

Of course these particular components are not a typical case, since if
the target is using Office and mostly Microsoft solutions one is
practically guaranteed they will be there and registered - thus extra
finagling need ever be done. The downside is if they are already
present then it is likely they are heavily shared. Your hijacking the
'global' registration may work well on your test box and for the
single-tasking user, but is likely to fail at the most inopportune
time on a busy box.

[GS]

Post by ralph

Post by GS
After much googling I'm probably going to go with...
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /s"
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /u /s"

The location "gsAppPath" is a tad disturbing. Is this a placeholder
or an actual new location (copy)?

Yes, it's a global string variable that contains the path to the app's
install folder, including the trailing backslash. I use it because I
like my code portable between VBA/VB6 projects and so its value is set
at startup along with any other globals in the InitGlobals procedure.

Post by ralph

Post by GS
..if/when an attempt to 'Load' the userform throws an error. This
will also obviate screwing things up if someone else has registered
the control. (My intent is that it only be available during runtime
of the VBA project if not existing on the host machine)...
On Error GoTo instOCX
Set DF = New fDataFormLV
If Not DF Is Nothing Then DF.Show vbModeless: Exit Sub
Call RegOCX
'Just do once
If iNum = 0 Then iNum = iNum + 1: Resume loadDF _
Else MsgBox sMsg, vbCritical
..and on shutdown...
Call RegOCX(False)
..where RegOCX(Optional LoadOCX As Boolean = True) uses Dir() to see
if the ocx exists in the path and if not found it returns False. It
returns True on success.
Just trying to keep it simple...<g>

It sounds like you are developing a shrink-wrap App for release into
the wild. If so, while I can appreciate this may seem simpler, you
might want to reconsider and use a proven Side-by-Side technology
(Manifest, Reg-Free). It will actually be 'simpler' in the long run.

As stated in numerous other threads, I use a manifest for all my VB6
apps so they are 100% portable. This means they do not change the host
machine in any way, including not using the Registry, and they cleanup
after themselves at shutdown.

I persist 100% portability with my VBA projects as well. Since OCXs
can't be used reg-free in MS Office VBA projects a manifest just won't
work (as I'm sure you know).

My resolve for this issue is this...

my VBA project will register mscomctl.ocx at startup ONLY IF it does
not pre-exist on the host machine. Otherwise it uses existing
'registered' ocx.

IF registered at startup, the ocx is unregistered at shutdown.

The ocx 'lives' in the project's install folder.

This will persist my 100% portability policy AND (as mentioned above)
will not screw up anyone else's registered ocx. The only caveat I see
here is I obviously use v6 SP6 and so if someone else
installs/registers a previous version things get messy. To resolve this
I store the location so it can be re-registered at shutdown. (I just
have to hope user doesn't run its using app during my app's runtime!) I
provide all information/cautions in a readme, which displays 1st
runtime (per user) before the userform using the ocx displays.

Post by ralph
Of course these particular components are not a typical case, since
if the target is using Office and mostly Microsoft solutions one is
practically guaranteed they will be there and registered - thus extra
finagling need ever be done. The downside is if they are already
present then it is likely they are heavily shared. Your hijacking the
'global' registration may work well on your test box and for the
single-tasking user, but is likely to fail at the most inopportune
time on a busy box.

As you can see by my earlier comments, I think I have a decent resolve
in place. If, as you state, this situation will most likely be that the
ocx already exists then all is good, right?

The VBA version is for the casual user. The VB6 version runs reg-free
and is what I recommend over the MS Office version because (I have
FarPoint's Spread.ocx and so can duplicate what Excel does so far as my
apps are concerned) In cases where the user needs to work further with
things in Excel, the Spread.ocx converts/exports/imports its workbooks
to/from Excel format. Also, I include data output (no formulas) to CSV
format as an option.

Not saying it's all 'perfect', but I do go the distance with effort to
make it as right as possible!<g>

As always, your sage advice is most appreciated. Thank you for
investing your time/energy!

[GS]

Looking deeper I see that an existing earlier VB version isn't going to
be an issue since they are completely different libs
(mscomctl.ocx/comctl32.ocx). I have both on all my machines!

The issue is what version of mscomctl.ocx is installed (I'm using SP6).
That makes my only concern being to check the VBA project References to
see if it lists as 'MISSING'. Mike D cited a caution about having good
error handling in place in his last message. I had already anticipated
(not my 1st VBA project<g>) there can be any number of reasons why
loading the userform might fail. My intent is to register the ocx on
condition that the cause of the error is because it's LISTED AS
MISSING.

Checking if it exists in Windows\SysWOW64 doesn't suffice if someone
else has it stored in another location where the registration points
to. I can trace it, though, in HKCR\CLSID using RegOpenKeyEx followed
by RegQueryValueEx to get its path.

[Deanna Earley]

Post by GS
I persist 100% portability with my VBA projects as well. Since OCXs
can't be used reg-free in MS Office VBA projects a manifest just won't
work (as I'm sure you know).
My resolve for this issue is this...
my VBA project will register mscomctl.ocx at startup ONLY IF it does
not pre-exist on the host machine. Otherwise it uses existing
'registered' ocx.
IF registered at startup, the ocx is unregistered at shutdown.
The ocx 'lives' in the project's install folder.

You do realise that this requires admin access and implies (to the user)
"not truly portable", even if you undo it afterwards?
Especially as the elevation prompt says ""Do you want to all the
following program to make changes to this computer?"

Also, what happens when the office application crashes?
They get left registered in your application folder, causing collateral
confusion to anything else that may want to use it.

[GS]

Post by Deanna Earley

Post by GS
I persist 100% portability with my VBA projects as well. Since OCXs
can't be used reg-free in MS Office VBA projects a manifest just won't
work (as I'm sure you know).
My resolve for this issue is this...
my VBA project will register mscomctl.ocx at startup ONLY IF it does
not pre-exist on the host machine. Otherwise it uses existing
'registered' ocx.
IF registered at startup, the ocx is unregistered at shutdown.
The ocx 'lives' in the project's install folder.

You do realise that this requires admin access and implies (to the
user) "not truly portable", even if you undo it afterwards?
Especially as the elevation prompt says ""Do you want to all the
following program to make changes to this computer?"
Also, what happens when the office application crashes?
They get left registered in your application folder, causing
collateral confusion to anything else that may want to use it.

Deanna,
Thanks for your comments. Further developments/discoveries have been
made concerning the 'Common' controls install with MS Office. Turns out
if they're missing at startup, Excel reinstalls them during its startup
initialization. Thus doing anything with MSO files is abandoned,
leaving only my 3rd party dependancies to handle if missing.

[GS]

Ralph,
Mike D has inspired some 'looking deeper' which has returned beneficial
results. See my latest reply to him for details...

[MikeD]

Post by GS
After much googling I'm probably going to go with...
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /s"
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /u /s"
..if/when an attempt to 'Load' the userform throws an error. This will
also obviate screwing things up if someone else has registered the
control. (My intent is that it only be available during runtime of the VBA
project if not existing on the host machine)...
On Error GoTo instOCX
Set DF = New fDataFormLV
If Not DF Is Nothing Then DF.Show vbModeless: Exit Sub
Call RegOCX
'Just do once
If iNum = 0 Then iNum = iNum + 1: Resume loadDF _
Else MsgBox sMsg, vbCritical
..and on shutdown...
Call RegOCX(False)
..where RegOCX(Optional LoadOCX As Boolean = True) uses Dir() to see if
the ocx exists in the path and if not found it returns False. It returns
True on success.
Just trying to keep it simple...<g>

This is just bad in every aspect. You're eventually going to hose somebody's
system. There are just SO many different ways that something could go wrong
because you didn't take one little thing into account, such as apparently
downloading and registering the ocx for any error "the userform throws".
Have you got sufficient error handling to ONLY download and register the ocx
IF the error is specific to instantiating a control from THAT ocx? You'd
have to at least do that for this to be viable in any respect. Depending on
how long you've done things this way, I'd be surprised if you haven't
screwed up a system yet. Then again, maybe you have and that's why you're
asking about it now. :)

And you should have stated at the onset this was more for VBA than VB6, and
also that you weren't actually doing a "proper" installation. If you post
in this newsgroup, VB6 is assumed. IMHO, this "on-demand" downloading,
registering, and unregistering is an absolutely terrible idea. Let me put it
another way: if I were a user of your "Excel VBA app" (as you referred to it
in your preceding message) and I found out you were doing this, you'd get a
pretty nasty email from me, even if it didn't cause any problems.

I get that what you're trying to do is come up with a "no fuss" way of your
VBA userform/code working with a ListView control and that you really don't
want a user to have to "install" it. But you're really just asking for
problems with what you're doing. Unfortunately, I really don't have any
suggestions for you.

Mike

[GS]

Post by MikeD

Post by GS
After much googling I'm probably going to go with...
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /s"
Shell "regsvr32 " & gsAppPath & "mscomctl.ocx /u /s"
..if/when an attempt to 'Load' the userform throws an error. This
will also obviate screwing things up if someone else has registered
the control. (My intent is that it only be available during runtime
of the VBA project if not existing on the host machine)...
On Error GoTo instOCX
Set DF = New fDataFormLV
If Not DF Is Nothing Then DF.Show vbModeless: Exit Sub
Call RegOCX
'Just do once
If iNum = 0 Then iNum = iNum + 1: Resume loadDF _
Else MsgBox sMsg, vbCritical
..and on shutdown...
Call RegOCX(False)
..where RegOCX(Optional LoadOCX As Boolean = True) uses Dir() to
see if the ocx exists in the path and if not found it returns
False. It returns True on success.
Just trying to keep it simple...<g>

This is just bad in every aspect. You're eventually going to hose
somebody's system. There are just SO many different ways that
something could go wrong because you didn't take one little thing
into account, such as apparently downloading and registering the ocx
for any error "the userform throws". Have you got sufficient error
handling to ONLY download and register the ocx IF the error is
specific to instantiating a control from THAT ocx? You'd have to at
least do that for this to be viable in any respect. Depending on how
long you've done things this way, I'd be surprised if you haven't
screwed up a system yet. Then again, maybe you have and that's why
you're asking about it now. :)

Yes, I have ample error handling in place to determine what action to
take. First check is to see if the ocx is listed as 'MISSING' in the
VBA project. If so then implement my resolve!

Post by MikeD
And you should have stated at the onset this was more for VBA than
VB6, and also that you weren't actually doing a "proper"
installation. If you post in this newsgroup, VB6 is assumed. IMHO,
this "on-demand" downloading, registering, and unregistering is an
absolutely terrible idea. Let me put it another way: if I were a user
of your "Excel VBA app" (as you referred to it in your preceding
message) and I found out you were doing this, you'd get a pretty
nasty email from me, even if it didn't cause any problems.

I have changed this to include the ocx in the installer as the download
aspect at runtime didn't sit well with me either!

Post by MikeD
I get that what you're trying to do is come up with a "no fuss" way
of your VBA userform/code working with a ListView control and that
you really don't want a user to have to "install" it. But you're
really just asking for problems with what you're doing.

I disagree on the basis that which version of the app the user installs
is 'their choice'. (see my latest reply to Ralph about that) Pros/cons
are fully documented.

I could give the user the option to have the ocx left registered since
that's what other apps do anyway, but this would only happen if it's
not already installed.

<FWIW>
While you may think you very well don't have any suggestions for me..,
your input has had some influence in the outcome of my resolve. I
appreciate your comments and thank you for the time/energy you feel
you've 'spent' on this!

[GS]

For clarity...

After looking deeper (encouraged by your comments<g>)...

Since this is for MS Office VBA projects, that precludes that the
'Microsoft Windows Common Controls 6.0'(SP6) lib *will exist* until
such time that M$ no longer installs it with MS Office. My only intent
here is to have a backup strategy in place *if it's missing*. In this
case, my version of mscomctl.ocx IS SP6 and so there's no reason why I
can't/shouldn't put it in the SysWOW64 folder and leave it registered
there if need be!

[ralph]

Post by GS
For clarity...
After looking deeper (encouraged by your comments<g>)...
Since this is for MS Office VBA projects, that precludes that the
'Microsoft Windows Common Controls 6.0'(SP6) lib *will exist* until
such time that M$ no longer installs it with MS Office. My only intent
here is to have a backup strategy in place *if it's missing*. In this
case, my version of mscomctl.ocx IS SP6 and so there's no reason why I
can't/shouldn't put it in the SysWOW64 folder and leave it registered
there if need be!

Personally I would avoid going into the business of updating ms
'common' (pun intended <g>) components.

Microsoft provides an update package:
http://www.microsoft.com/en-us/download/details.aspx?id=10019

I would simply check for "missing" or error then either supply the URL
or include the package in your install package. (Didn't see a
non-distribute notice - but didn't look all that hard.)

-ralph

[GS]

Post by ralph

Post by GS
For clarity...
After looking deeper (encouraged by your comments<g>)...
Since this is for MS Office VBA projects, that precludes that the
'Microsoft Windows Common Controls 6.0'(SP6) lib *will exist* until
such time that M$ no longer installs it with MS Office. My only
intent here is to have a backup strategy in place *if it's
missing*. In this case, my version of mscomctl.ocx IS SP6 and so
there's no reason why I can't/shouldn't put it in the SysWOW64
folder and leave it registered there if need be!

Personally I would avoid going into the business of updating ms
'common' (pun intended <g>) components.
http://www.microsoft.com/en-us/download/details.aspx?id=10019
I would simply check for "missing" or error then either supply the
URL or include the package in your install package. (Didn't see a
non-distribute notice - but didn't look all that hard.)
-ralph

Thanks, Ralph. That's good advice!

As discussion continues with my Excel app dev piers.., we collectively
have arrived at a similar solution;

Even though my version of mscomctl.ocx IS what installs with MS
Office, it's (as Mike suggests) a bad idea to do this for one ocx
since it's likely not the only component missing from the user's
MS Office install.

What I do with my VB6 apps (including the VBA frontloader.EXEs) is
check for all necessary runtime files/deps and notify user of
'Startup Failure!' with recommendation to reinstall, then shutdown
or abort startup. This is how I should handle this particular project
even though it's only an addin utility (no VB6 frontloader).

I normally write startup failures to a 'log' file with the info about
the failure. This is not the usual type of project for me. My apps
use their own automated instance of Excel and so the use of the VB6
frontloader.EXEs. This project will be opened directly in the user's
instance of Excel and so no pre-startup checks happen. In this case
I'll use the normal frontloader code to check if the other deps exist
along with the VBA Project References for it 'MISSING'. The user is
notified of the findings (if any) along with suggested remedies. In
the case of the ocx missing I can simply redirect the user to the
link you posted. Do you think it would be prudent to offer to do the
update 'on the spot'?

This saves me from messing with reg/unreg and that just suits me fine
since that's the main reason I started using manifests.

In summary, since this is a MSO project AND since it uses controls
installed by MSO, it's not my place to fix a user's MSO install
regardless of why it's 'broken'.

I downloaded the update and will put a copy in my URL/downloads folder!

Thanks again!<g>

[CoderX]

Who are you attempting to cinvice? Us, or yourself?

Post by GS

Post by ralph

Post by GS
For clarity...
After looking deeper (encouraged by your comments<g>)...
Since this is for MS Office VBA projects, that precludes that the
'Microsoft Windows Common Controls 6.0'(SP6) lib *will exist* until such
time that M$ no longer installs it with MS Office. My only intent here
is to have a backup strategy in place *if it's missing*. In this case,
my version of mscomctl.ocx IS SP6 and so there's no reason why I
can't/shouldn't put it in the SysWOW64 folder and leave it registered
there if need be!

Personally I would avoid going into the business of updating ms
'common' (pun intended <g>) components.
http://www.microsoft.com/en-us/download/details.aspx?id=10019
I would simply check for "missing" or error then either supply the URL or
include the package in your install package. (Didn't see a
non-distribute notice - but didn't look all that hard.)
-ralph

Thanks, Ralph. That's good advice!
As discussion continues with my Excel app dev piers.., we collectively
have arrived at a similar solution;
Even though my version of mscomctl.ocx IS what installs with MS
Office, it's (as Mike suggests) a bad idea to do this for one ocx
since it's likely not the only component missing from the user's
MS Office install.
What I do with my VB6 apps (including the VBA frontloader.EXEs) is
check for all necessary runtime files/deps and notify user of
'Startup Failure!' with recommendation to reinstall, then shutdown
or abort startup. This is how I should handle this particular project
even though it's only an addin utility (no VB6 frontloader).
I normally write startup failures to a 'log' file with the info about
the failure. This is not the usual type of project for me. My apps
use their own automated instance of Excel and so the use of the VB6
frontloader.EXEs. This project will be opened directly in the user's
instance of Excel and so no pre-startup checks happen. In this case
I'll use the normal frontloader code to check if the other deps exist
along with the VBA Project References for it 'MISSING'. The user is
notified of the findings (if any) along with suggested remedies. In
the case of the ocx missing I can simply redirect the user to the
link you posted. Do you think it would be prudent to offer to do the
update 'on the spot'?
This saves me from messing with reg/unreg and that just suits me fine
since that's the main reason I started using manifests.
In summary, since this is a MSO project AND since it uses controls
installed by MSO, it's not my place to fix a user's MSO install regardless
of why it's 'broken'.
I downloaded the update and will put a copy in my URL/downloads folder!
Thanks again!<g>
--
Garry
Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

[GS]

Post by MikeD
And you should have stated at the onset this was more for VBA than
VB6, and also that you weren't actually doing a "proper"
installation. If you post in this newsgroup, VB6 is assumed.

Uh.., since the topic IS VB6 controls AND the context of the discussion
is about the best VB syntax or code to use for reg/unreg, then (as Karl
might put it)...

WTF!!!

[GS]

Thank you Mike and Ralph, for talking me through this issue to result a
really good solution (IMO).

Note that this discussion has preceded initial release of this VBA
utility and so the only machines it's been run on are my XP dev machine
and this Win7 Pro machine. Since I have multiple versions of MS Office
on all machines, the ocx exists on all.

Your time/effort/energy has been well invested, and most appreciated!

[GS]

Well aren't I the fool of the day! I just tried testing my VBA project
by deleting mscomctl.ocx and starting Excel to open my utility. To my
astonishment, Excel automagically reinstalled the ocx during startup
initialization! This suggests that MSO apps also make sure their
runtime components are in place, and reinstalls if not.

I'm happy about that because it means that I now have a similar
solution for any 3rd party components I also use!<bg>

[Peter T]

Well aren't I the fool of the day! I just tried testing my VBA project by
deleting mscomctl.ocx and starting Excel to open my utility. To my
astonishment, Excel automagically reinstalled the ocx during startup
initialization! This suggests that MSO apps also make sure their runtime
components are in place, and reinstalls if not.

The reference might appear to still exist, ie not MISSING, but did you try
to use it. I'd be surprised if you didn't get a "failed to load object"
warning if you had one of the controls on a form. Try this (Excel)

For Each rf In ActiveWorkbook.VBProject.references
Debug.Print rf.Name
Debug.Print , rf.fullpath
Next

It might return the Name (simply stored with the ref in the file) but what
about the path?

Reading through this thread perhaps I'm wrong but I thought the more common
VB6 dll's & ocx's were bundled with W64 and installed in SysWOW64. That said
issues about them not being properly installed seem to crop up regularly.

Regards,
Peter T

[GS]

Post by Peter T

Post by GS
Well aren't I the fool of the day! I just tried testing my VBA
project by deleting mscomctl.ocx and starting Excel to open my
utility. To my astonishment, Excel automagically reinstalled the
ocx during startup initialization! This suggests that MSO apps also
make sure their runtime components are in place, and reinstalls if
not.

The reference might appear to still exist, ie not MISSING, but did
you try to use it. I'd be surprised if you didn't get a "failed to
load object" warning if you had one of the controls on a form. Try
this (Excel)
For Each rf In ActiveWorkbook.VBProject.references
Debug.Print rf.Name
Debug.Print , rf.fullpath
Next
It might return the Name (simply stored with the ref in the file) but
what about the path?

I was using the 'Description' property to check as listed in the
References dialog.

Post by Peter T
Reading through this thread perhaps I'm wrong but I thought the more
common VB6 dll's & ocx's were bundled with W64 and installed in
SysWOW64. That said issues about them not being properly installed
seem to crop up regularly.

My understanding from Stephen Bullen's chapter in PED is that these
controls are shipped/installed with MS Office. Given that Excel will
reinstall them if missing at startup suggests MSO apps require them.

That leaves only any missing 3rd party dependancies I use a concern.
This is already handled in my VBA app frontloader VB6.EXEs, and a
non-issue in VB6 apps because I use a manifest.

[Peter T]

Post by GS

Post by Peter T

Post by GS
Well aren't I the fool of the day! I just tried testing my VBA project
by deleting mscomctl.ocx and starting Excel to open my utility. To my
astonishment, Excel automagically reinstalled the ocx during startup
initialization! This suggests that MSO apps also make sure their runtime
components are in place, and reinstalls if not.

The reference might appear to still exist, ie not MISSING, but did you
try to use it. I'd be surprised if you didn't get a "failed to load
object" warning if you had one of the controls on a form. Try this
(Excel)
For Each rf In ActiveWorkbook.VBProject.references
Debug.Print rf.Name
Debug.Print , rf.fullpath
Next
It might return the Name (simply stored with the ref in the file) but
what about the path?

I was using the 'Description' property to check as listed in the
References dialog.

Like the Name the Description seems to be stored in the workbook, it doesn't
prove anything, try returning the path.

Post by GS

Post by Peter T
Reading through this thread perhaps I'm wrong but I thought the more
common VB6 dll's & ocx's were bundled with W64 and installed in SysWOW64.
That said issues about them not being properly installed seem to crop up
regularly.

My understanding from Stephen Bullen's chapter in PED is that these
controls are shipped/installed with MS Office. Given that Excel will
reinstall them if missing at startup suggests MSO apps require them.

Possibly in versions that potentially might have installed in Win9x, but
with 2000 the VB6 runtime was included by default, and most of the typical
controls ever since.

However I don't think Excel or Office will do anything to re-install an ocx
or dll if missing or not registered for some reason, even if the file is
asking for them.

Keep in mind too things can blow up if transferring a workbook with a
reference to an ocx saved in say Win64 to a user with Win32 even if the W64
user's Office is installed as default 32bit.

Regards,
Peter T

[GS]

Post by Peter T
Like the Name the Description seems to be stored in the workbook, it
doesn't prove anything, try returning the path.

Not sure that's the case when my code is reading from the
VBIDE.References, NOT the workbook.

In this case the path should be the SysWOW64 folder.

Post by Peter T
Possibly in versions that potentially might have installed in Win9x,
but with 2000 the VB6 runtime was included by default, and most of
the typical controls ever since.
However I don't think Excel or Office will do anything to re-install
an ocx or dll if missing or not registered for some reason, even if
the file is asking for them.

I did a Shift+Delete on MSCOMCTL.OCX followed by starting Excel and it
reinstalled the OCX during startup initialization BEFORE displaying
'Book1'!

Post by Peter T
Keep in mind too things can blow up if transferring a workbook with a
reference to an ocx saved in say Win64 to a user with Win32 even if
the W64 user's Office is installed as default 32bit.

I don't do x64 projects as yet, but I will likely use separate versions
when I do. Otherwise, conditional declares are required?

[Peter T]

Post by GS

Post by Peter T
However I don't think Excel or Office will do anything to re-install an
ocx or dll if missing or not registered for some reason, even if the file
is asking for them.

I did a Shift+Delete on MSCOMCTL.OCX followed by starting Excel and it
reinstalled the OCX during startup initialization BEFORE displaying
'Book1'!

Yes you're right, interesting. I renamed the file and when Office restarted
it went through a reinstallation process of a few minutes and added an
identical mscomctl.ocx along side the renamed file.

However if the ocx is unregistered for some reason Office will not
re-register it, at least not for me.

Regards,
Peter T

[Deanna Earley]

Post by Peter T

Post by GS

Post by Peter T
However I don't think Excel or Office will do anything to re-install an
ocx or dll if missing or not registered for some reason, even if the file
is asking for them.

I did a Shift+Delete on MSCOMCTL.OCX followed by starting Excel and it
reinstalled the OCX during startup initialization BEFORE displaying
'Book1'!

Yes you're right, interesting. I renamed the file and when Office restarted
it went through a reinstallation process of a few minutes and added an
identical mscomctl.ocx along side the renamed file.
However if the ocx is unregistered for some reason Office will not
re-register it, at least not for me.

The reinstallation is done as part of MSI/Windows Installer, not Office
itself.
The Office install claims ownership of those files so will always try
and return them to its expected versions.
It only checks file existence so may not pick up on them being unregistered.

[Peter T]

Post by Deanna Earley

Post by Peter T

Post by GS

Post by Peter T
However I don't think Excel or Office will do anything to re-install an
ocx or dll if missing or not registered for some reason, even if the file
is asking for them.

I did a Shift+Delete on MSCOMCTL.OCX followed by starting Excel and it
reinstalled the OCX during startup initialization BEFORE displaying
'Book1'!

Yes you're right, interesting. I renamed the file and when Office restarted
it went through a reinstallation process of a few minutes and added an
identical mscomctl.ocx along side the renamed file.
However if the ocx is unregistered for some reason Office will not
re-register it, at least not for me.

The reinstallation is done as part of MSI/Windows Installer, not Office
itself.
The Office install claims ownership of those files so will always try and
return them to its expected versions.
It only checks file existence so may not pick up on them being
unregistered.

Well I never knew that, thanks. But in effect it's still Office even if
indirectly, right? In my test the file was replaced when Office restarted,
not when Windows rebooted, and appeared to do a lot of work apparently
reinstalling itself just to replace that little file!

Regards,
Peter T

[Deanna Earley]

Post by Peter T

Post by Deanna Earley

Post by Peter T
Yes you're right, interesting. I renamed the file and when Office restarted
it went through a reinstallation process of a few minutes and added an
identical mscomctl.ocx along side the renamed file.
However if the ocx is unregistered for some reason Office will not
re-register it, at least not for me.

The reinstallation is done as part of MSI/Windows Installer, not Office
itself.
The Office install claims ownership of those files so will always try and
return them to its expected versions.
It only checks file existence so may not pick up on them being unregistered.

Well I never knew that, thanks. But in effect it's still Office even if
indirectly, right? In my test the file was replaced when Office restarted,
not when Windows rebooted, and appeared to do a lot of work apparently
reinstalling itself just to replace that little file!

Effectively, but it's not unique to Office.
Any VB app installing that control from an MSI would have the same effect.
The "lot of work" is doing a full verification of everything it "owns".

[Peter T]

[snip]

Post by Deanna Earley

Post by Peter T

Post by Deanna Earley
The reinstallation is done as part of MSI/Windows Installer, not Office
itself.
The Office install claims ownership of those files so will always try and
return them to its expected versions.
It only checks file existence so may not pick up on them being unregistered.

Well I never knew that, thanks. But in effect it's still Office even if
indirectly, right? In my test the file was replaced when Office restarted,
not when Windows rebooted, and appeared to do a lot of work apparently
reinstalling itself just to replace that little file!

Effectively, but it's not unique to Office.
Any VB app installing that control from an MSI would have the same effect.
The "lot of work" is doing a full verification of everything it "owns".

Explains several things, thanks again.

Regards,
Peter T

[GS]

Post by Deanna Earley

Post by Peter T

Post by GS

Post by Peter T
However I don't think Excel or Office will do anything to
re-install an
ocx or dll if missing or not registered for some reason, even if the file
is asking for them.

I did a Shift+Delete on MSCOMCTL.OCX followed by starting Excel and it
reinstalled the OCX during startup initialization BEFORE
displaying
'Book1'!

Yes you're right, interesting. I renamed the file and when Office restarted
it went through a reinstallation process of a few minutes and added an
identical mscomctl.ocx along side the renamed file.
However if the ocx is unregistered for some reason Office will not
re-register it, at least not for me.

The reinstallation is done as part of MSI/Windows Installer, not
Office itself.
The Office install claims ownership of those files so will always try
and return them to its expected versions.
It only checks file existence so may not pick up on them being
unregistered.

I'm not expecting anyone to deliberately unreg these controls so much
as them get wrongfully deleted by some uninstaller. I'll use the M$
updater file I downloaded from Ralph's link to handle things if
listview's not found in HKCR\CLSID.

Note that I was not able to locate the ID for mscomctl.ocx there, but
did find the individual OCX IDs (as listed in my vb6.exe.manifest)
there. I would have thought the mscomctl.ocx ID would be there too!