Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #2054 > unrolled thread

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

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-08 14:14 -0400
    Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "MikeD" <nobody@nowhere.edu> - 2014-05-08 15:38 -0400
      Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-08 17:08 -0400
        Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-08 17:19 -0400
    Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? ralph <nt_consulting@yahoo.com> - 2014-05-08 15:30 -0500
      Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? ralph <nt_consulting@yahoo.com> - 2014-05-08 15:49 -0500
      Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-08 17:17 -0400
        Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? ralph <nt_consulting@yahoo.com> - 2014-05-08 21:09 -0500
          Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 00:12 -0400
            Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 08:15 -0400
              Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? ralph <nt_consulting@yahoo.com> - 2014-05-09 16:00 -0500
                Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 18:06 -0400
                  Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 19:26 -0400
                  Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? Deanna Earley <dee.earley@icode.co.uk> - 2014-05-12 09:00 +0100
                    Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-12 18:51 -0400
                Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 19:55 -0400
              Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "MikeD" <nobody@nowhere.edu> - 2014-05-09 18:09 -0400
                Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 18:52 -0400
                  Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 19:48 -0400
                    Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? ralph <nt_consulting@yahoo.com> - 2014-05-09 20:34 -0500
                      Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 22:33 -0400
                        Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "CoderX" <coder@x.com> - 2014-05-12 15:40 -0400
                Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 20:44 -0400
    Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-09 22:47 -0400
      Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-10 19:55 -0400
        Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "Peter T" <askformy@gmail.com> - 2014-05-12 16:19 +0100
          Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-12 19:07 -0400
            Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "Peter T" <askformy@gmail.com> - 2014-05-13 12:38 +0100
              Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-13 15:40 -0400
                Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "Peter T" <askformy@gmail.com> - 2014-05-14 16:40 +0100
                  Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? Deanna Earley <dee.earley@icode.co.uk> - 2014-05-14 17:13 +0100
                    Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "Peter T" <askformy@gmail.com> - 2014-05-14 17:47 +0100
                      Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? Deanna Earley <dee.earley@icode.co.uk> - 2014-05-15 08:59 +0100
                        Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? "Peter T" <askformy@gmail.com> - 2014-05-15 12:55 +0100
                    Re: What's the reason for comctl32.dll + comctl32.ocx in Win7  SysWOW64 folder? GS <gs@somewhere.net> - 2014-05-14 13:00 -0400

Page 2 of 2 — ← Prev page 1 [2]

#2075

> On Fri, 09 May 2014 19:48:24 -0400, GS <gs@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

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

[toc] | [prev] | [next] | [standalone]

#2087

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


"GS" <gs@somewhere.net> wrote in message news:lkk366$eur$1@dont-email.me...
>> On Fri, 09 May 2014 19:48:24 -0400, GS <gs@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
>
> 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
>
> 

[toc] | [prev] | [next] | [standalone]

#2073

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

-- 
Garry

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

[toc] | [prev] | [next] | [standalone]

#2076

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!

-- 
Garry

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

[toc] | [prev] | [next] | [standalone]

#2077

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>

-- 
Garry

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

[toc] | [prev] | [next] | [standalone]

#2086

"GS" <gs@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 

[toc] | [prev] | [next] | [standalone]

#2089

> "GS" <gs@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.

-- 
Garry

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

[toc] | [prev] | [next] | [standalone]

#2093

"GS" <gs@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

[toc] | [prev] | [next] | [standalone]

#2100

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

-- 
Garry

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

[toc] | [prev] | [next] | [standalone]

#2107

"GS" <gs@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 

[toc] | [prev] | [next] | [standalone]

#2108

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

-- 
Deanna Earley (dee.earley@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.)

[toc] | [prev] | [next] | [standalone]

#2109

"Deanna Earley" <dee.earley@icode.co.uk> wrote in message 
news:ll04n4$9p3$1@speranza.aioe.org...
> On 14/05/2014 16:40, Peter T wrote:
>> "GS" <gs@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

[toc] | [prev] | [next] | [standalone]

#2111

On 14/05/2014 17:47, Peter T wrote:
> "Deanna Earley" <dee.earley@icode.co.uk> wrote in message
> news:ll04n4$9p3$1@speranza.aioe.org...
>> On 14/05/2014 16:40, Peter T wrote:
>>> 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".

-- 
Deanna Earley (dee.earley@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.)

[toc] | [prev] | [next] | [standalone]

#2113

"Deanna Earley" <dee.earley@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 

[toc] | [prev] | [next] | [standalone]

#2110

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

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!

-- 
Garry

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web