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 1 of 2  [1] 2  Next page →

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

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

[toc] | [next] | [standalone]

#2056

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

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

#2059

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

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

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

#2061

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>

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

#2057

On Thu, 08 May 2014 14:14:46 -0400, GS <gs@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

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

#2058

On Thu, 08 May 2014 15:30:54 -0500, ralph <nt_consulting@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.

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

#2060

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

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

#2062

On Thu, 08 May 2014 17:17:19 -0400, GS <gs@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

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

#2063

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

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

#2065

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>

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

#2066

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

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

#2067

> On Fri, 09 May 2014 08:15:56 -0400, GS <gs@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!

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

#2070

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.

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

#2084

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

#2088

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

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

#2072

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

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

#2068

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

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

#2069

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

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!

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

#2071

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!

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

#2074

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web