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?

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

[MikeD]

"GS" <g...@somewhere.net> wrote in message news:lkghip$n9s$1...@dont-email.me...

> 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.

>
> 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.

>
> 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

[ralph]

On Thu, 08 May 2014 14:14:46 -0400, GS <g...@somewhere.net> wrote:

>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 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 <nt_con...@yahoo.com>
wrote:

What I should have said ...

>>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.

>>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]

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

[GS]

> On Thu, 08 May 2014 14:14:46 -0400, GS <g...@somewhere.net> wrote:
>
>> 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.

>
>> 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...

[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]

On Thu, 08 May 2014 17:17:19 -0400, GS <g...@somewhere.net> wrote:

>>
>> 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]

>
> 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]

On Fri, 09 May 2014 08:15:56 -0400, GS <g...@somewhere.net> wrote:

>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)?

>..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>

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]

> On Fri, 09 May 2014 08:15:56 -0400, GS <g...@somewhere.net> wrote:
>
>> 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.

>
>> ..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>
>
> 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.

>
> 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!

[MikeD]

"GS" <g...@somewhere.net> wrote in message news:lkigu0$kfp$1...@dont-email.me...

> 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>

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]

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!

>
> 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!

>
> 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]

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.

[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!

[GS]

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

[GS]

> 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!!!

[ralph]

On Fri, 09 May 2014 19:48:24 -0400, GS <g...@somewhere.net> wrote:

>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]

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>

[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>

[Deanna Earley]

On 09/05/2014 23:06, GS wrote:
> 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 Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be printed, shredded then fed
to the rats. Please reply to the group.)

[Peter T]

"GS" <g...@somewhere.net> wrote in message

> 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

[CoderX]

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


"GS" <g...@somewhere.net> wrote in message news:lkk366$eur$1...@dont-email.me...

[GS]

> On 09/05/2014 23:06, GS wrote:
>> 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]

> "GS" <g...@somewhere.net> wrote in message
>
>> 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.

>
> 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]

"GS" <g...@somewhere.net> wrote in message >>
>>> 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.

>> 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]

> 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.

>
> 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'!

>
> 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]

"GS" <g...@somewhere.net> wrote in message
>>

>> 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]

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]

"Deanna Earley" <dee.e...@icode.co.uk> wrote in message
news:ll04n4$9p3$1...@speranza.aioe.org...

> On 14/05/2014 16:40, Peter T wrote:
>> "GS" <g...@somewhere.net> wrote in message
>>>>
>>>> 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

[GS]

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!

[Deanna Earley]

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]

"Deanna Earley" <dee.e...@icode.co.uk> wrote in message
> On 14/05/2014 17:47, Peter T wrote:

[snip]

>>> 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