[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

win7 mscomctl.oca vbp problem

Jimekus

1/22/2012 11:16:00 PM

Hi,

Yesterday, I retired XP from my main development machine in favor of
Win7 Ultimate x86 and have run into a trap. After my first successful
compile I get an altered vbp file showing a new reference to this file
called mscomctl.oca and my project group subsequently fails to load
into the IDE, unless I remove this reference. Incidentally, the vbp
file doesn't reference the ocx file because it is a component. Should
it?

I can continue, by not saving my vbp file after a compile and manually
managing my version numbers, but I'd like a cleaner solution. I've
tried deleting the oca file but it gets recreated. Any ideas?

There are about seven major obstacles I will need to overcome to get
my system running well in Win7, so this is just a starter problem.

Thanks
10 Answers

ralph

1/23/2012 1:03:00 PM

0

On Sun, 22 Jan 2012 15:16:00 -0800 (PST), Jimekus <jimekus@gmail.com>
wrote:

>Hi,
>
>Yesterday, I retired XP from my main development machine in favor of
>Win7 Ultimate x86 and have run into a trap. After my first successful
>compile I get an altered vbp file showing a new reference to this file
>called mscomctl.oca and my project group subsequently fails to load
>into the IDE, unless I remove this reference. Incidentally, the vbp
>file doesn't reference the ocx file because it is a component. Should
>it?
>
>I can continue, by not saving my vbp file after a compile and manually
>managing my version numbers, but I'd like a cleaner solution. I've
>tried deleting the oca file but it gets recreated. Any ideas?
>
>There are about seven major obstacles I will need to overcome to get
>my system running well in Win7, so this is just a starter problem.
>

[First of all, IMHO, that is probably not a good idea. You may want to
investigate running some kind of virtual XP environment to develop
with VB. The VB application (the windows development platform) is NOT
supported on Windows 7. Period. Not aware of any specifc reason why it
couldn't be massaged to work. It is essentially just another 32-bit
application. So it should work. Others have. It is purely my
comfort-level that doesn't let me go there - But that's another story.
And all success in pulling it off.]

As for the .oca file. That is a cache used by VB to temporarily store
TypeLib information. That is to save time as vbdebug doesn't have to
re-reference the component every time it runs in the debugger (the
VBIDE). These cache files are always recreated if needed.

There has always been a minor *glitch* (for want of a better term) in
VB that caused the .OCA file to get referenced in Project References
instead of the component on occasion. Can't remember the specifics.
Came under the general heading of how "VB hijacks the Registry". (VB
plays a tad footloose with COM <g>). So look for a Registry problem.

Check to see there is only one copy of the .ocx on the machine, and
that it and any of its dependencies are properly registered in a hive
VB can see. (unregister, then re-register) The one and only correct
component should be in System32. Or whatever represents that folder on
your platform.

If this is a project you migrated over. You may need to make sure you
have "re-registered" all components your project is using. Especially
newer versions that might be included with Windows 7.

Also look at the CLSIDs stored under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual Basic\6.0
and make sure they match the Registered version.

hth
-ralph

Jimekus

1/23/2012 11:43:00 PM

0

On Jan 24, 2:02 am, ralph <nt_consultin...@yahoo.net> wrote:
> On Sun, 22 Jan 2012 15:16:00 -0800 (PST), Jimekus <jime...@gmail.com>
> wrote:
>
>
>
>
>
>
>
>
>
> >Hi,
>
> >Yesterday, I retired XP from my main development machine in favor of
> >Win7 Ultimate x86 and have run into a trap. After my first successful
> >compile I get an altered vbp file showing a new reference to this file
> >called mscomctl.oca and my project group subsequently fails to load
> >into the IDE, unless I remove this reference. Incidentally, the vbp
> >file doesn't reference the ocx file because it is a component. Should
> >it?
>
> >I can continue, by not saving my vbp file after a compile and manually
> >managing my version numbers, but I'd like a cleaner solution. I've
> >tried deleting the oca file but it gets recreated. Any ideas?
>
> >There are about seven major obstacles I will need to overcome to get
> >my system running well in Win7, so this is just a starter problem.
>
> [First of all, IMHO, that is probably not a good idea. You may want to
> investigate running some kind of virtual XP environment to develop
> with VB. The VB application (the windows development platform) is NOT
> supported on Windows 7. Period. Not aware of any specifc reason why it
> couldn't be massaged to work. It is essentially just another 32-bit
> application. So it should work. Others have. It is purely my
> comfort-level that doesn't let me go there - But that's another story.
> And all success in pulling it off.]
>
> As for the .oca file. That is a cache used by VB to temporarily store
> TypeLib information. That is to save time as vbdebug doesn't have to
> re-reference the component every time it runs in the debugger (the
> VBIDE). These cache files are always recreated if needed.
>
> There has always been a minor *glitch* (for want of a better term) in
> VB that caused the .OCA file to get referenced in Project References
> instead of the component on occasion. Can't remember the specifics.
> Came under the general heading of how "VB hijacks the Registry". (VB
> plays a tad footloose with COM <g>). So look for a Registry problem.
>
> Check to see there is only one copy of the .ocx on the machine, and
> that it and any of its dependencies are properly registered in a hive
> VB can see. (unregister, then re-register) The one and only correct
> component should be in System32. Or whatever represents that folder on
> your platform.
>
> If this is a project you migrated over. You may need to make sure you
> have "re-registered" all components your project is using. Especially
> newer versions that might be included with Windows 7.
>
> Also look at the CLSIDs stored under
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual Basic\6.0
> and make sure they match the Registered version.
>
> hth
> -ralph

Thanks for the help.

There is only one copy of the mscomctl.ocx and the CLSIDs match. The
version of both mscomctl.ocx and mscomct2.ocx is 6.01.9618, and
comctl32.ocx is 6.0.8106, however the dependency file for mscomctl.ocx
has a different version number. Here is the file. Should I just change
it to match the version numbers?

; Dependency file for setup wizards.

[Version]
Version=6.1.97.82

; Dependencies for MSComCtl.ocx

; Default Dependencies ----------------------------------------------

[MSComCtl.ocx]
Dest=$(WinSysPath)
Register=$(DLLSelfRegister)
Version=6.1.97.82
Uses1=ComCat.dll
Uses2=
CABFileName=MSComCtl.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSComCtl.inf

[ComCat.dll]
Dest=$(WinSysPathSysFile)
Register=$(DLLSelfRegister)
Uses1=

; Localized Dependencies --------------------------------------------

; ** German (DE) ***
; (0007 = German)
;
[MSComCtl.ocx <0007>]
Uses1=MSCmCDE.dll
Uses2=

[MSCmCDE.dll <0007>]
Uses1=
CABFileName=MSCmCDE.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCDE.inf

; ** French (FR) ***
; (000C = French)
;
[MSComCtl.ocx <000C>]
Uses1=MSCmCFR.dll
Uses2=

[MSCmCFR.dll <000C>]
Uses1=
CABFileName=MSCmCFR.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCFR.inf

; ** Italian (IT) ***
; (0010 = Italian)
;
[MSComCtl.ocx <0010>]
Uses1=MSCmCIT.dll
Uses2=

[MSCmCIT.dll <0010>]
Uses1=
CABFileName=MSCmCIT.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCIT.inf

; ** Spanish (ES) ***
; (000A = Spanish)
;
[MSComCtl.ocx <000A>]
Uses1=MSCmCES.dll
Uses2=

[MSCmCES.dll <000A>]
Uses1=
CABFileName=MSCmCES.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCES.inf

; ** Japanese (JP) ***
; (0011 = Japanese)
;
[MSComCtl.ocx <0011>]
Uses1=MSCmCJP.dll
Uses2=

[MSCmCJP.dll <0011>]
Uses1=
CABFileName=MSCmCJP.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCJP.inf

; ** Korean (KO) ***
; (0012 = Korean)
;
[MSComCtl.ocx <0012>]
Uses1=MSCmCKO.dll
Uses2=

[MSCmCKO.dll <0012>]
Uses1=
CABFileName=MSCmCKO.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCKO.inf

; ** Chinese Traditional (CHT) ***
; (0404 = Chinese Traditional)
;
[MSComCtl.ocx <0404>]
Uses1=MSCmCCHT.dll
Uses2=

[MSCmCCHT.dll <0404>]
Uses1=
CABFileName=MSCmCCHT.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCCHT.inf

; ** Chinese Simplified (CHS) ***
; (0804 = Chinese Simplified)
;
[MSComCtl.ocx <0804>]
Uses1=MSCmCCHS.dll
Uses2=

[MSCmCCHS.dll <0804>]
Uses1=
CABFileName=MSCmCCHS.cab
CABDefaultURL=http://activex.microsoft.com/co...
CABINFFile=MSCmCCHS.inf

ralph

1/24/2012 12:29:00 AM

0

On Mon, 23 Jan 2012 15:43:06 -0800 (PST), Jimekus <jimekus@gmail.com>
wrote:


>There is only one copy of the mscomctl.ocx and the CLSIDs match. The
>version of both mscomctl.ocx and mscomct2.ocx is 6.01.9618, and
>comctl32.ocx is 6.0.8106, however the dependency file for mscomctl.ocx
>has a different version number. Here is the file. Should I just change
>it to match the version numbers?
>

IIRC the .DEP files are only used by P&D (Package & Deployment
Wizard). So shouldn't matter in this case. However, it never hurts to
have 'everyone' on the same page. <g>

Ok... trying to remember... If I were debugging this it might go
something like this. (With added comments.) Note: it might be a tad
disjointed as my thinking usually is. <g>

The VBIDE (vbDebug) finds components listed in Project References by
the path given.
It opens the component and extracts the type information.
It adds this information to "type info" supplied by the VB Forms
engine for 'controls', and then creates an .OCA file with this
extended information.
Note it doesn't use the COMLib as will a compiled executable.
(Something to check does the compiled program run without errors?)
(The created .oca should be located in the same folder as the
component. If it shows up locally VB doesn't have permissions for that
folder. So the .OCA does show up in the System32 folder?)

For controls I think the .OCA (if not present) will be created when it
is added to the Toolbox. Now most controls have two 'parts' an
Interface which shows up in Project References and the information
recorded for items in the toolbox.
( For grins I might remove the component from the Toolbox and then add
it back. Not sure what that might accomplish, but it is something to
do. <g>)
Making sure the Toolbox and VBDebug are chewing on the same animal.

(If this is a migrated project, that is you just copied the files onto
the new platform, you might consider rebuilding it from scratch. Don't
delete any files, just open a blank project and add stuff.)

(The .VBP file contains most of the reference information, but you
might have a look at the individual .FRM files with an outside editor
and see what they might have in them.)

That's all that comes to mind atm. It has to be related to the
Registery and Permissions. And if it is of any help *there* will be a
simple solution.

-ralph

ralph

1/24/2012 12:57:00 AM

0

On Mon, 23 Jan 2012 18:29:00 -0600, ralph <nt_consulting64@yahoo.net>
wrote:

Just thought of something obscure.

In the .VBP file, just after the GUID there will be some number
delimited by nanograms... eg.
Object = (...GUID...) }#1.3#0; <name>

That is the TypeLib version number.
Reset it to Version 1 ...
#1.0#

If that doesn't work try changing versions up to 1.3.

Note: Type library versions are often different from component/file
versions.

-ralph

Bob Butler

1/24/2012 1:08:00 AM

0


"ralph" <nt_consulting64@yahoo.net> wrote in message
news:tovrh796dmn01ag6jacu4keq46ui0okge9@4ax.com...
> On Mon, 23 Jan 2012 18:29:00 -0600, ralph <nt_consulting64@yahoo.net>
> wrote:
>
> Just thought of something obscure.
>
> In the .VBP file, just after the GUID there will be some number
> delimited by nanograms... eg.
> Object = (...GUID...) }#1.3#0; <name>

I've heard them called hash marks and pound signs and probably a few others
but never heard them called billionths of a gram before... <g>

Jimekus

1/24/2012 1:15:00 AM

0


>
> IIRC the .DEP files are only used by P&D (Package & Deployment
> Wizard). So shouldn't matter in this case. However, it never hurts to
> have 'everyone' on the same page. <g>

Fixing the DEP files didn't help and the compiled code runs without
errors.


> (If this is a migrated project, that is you just copied the files onto
> the new platform, you might consider rebuilding it from scratch. Don't
> delete any files, just open a blank project and add stuff.)
>

Rebuilding sounds like a last resort for sometime in the future, but
there are 191 files. Below is a summary of my system. In the meantime
I'll just make my InGridX1.vbp read only and manually set the version
control. Thanks again.


File File Type Code Lines Comment Lines Total Lines Procedures
Controls
Ingridx.vbg Project Group 90,179 (85%) 14,818 (14%) 104,997 5,353
1,116
inGridoo Project 73,622 (85%) 12,520 (14%) 86,142 4,335 1,043
SavinGridoo Project 92 (88%) 12 (11%) 104 5 1
Install Project 229 (82%) 48 (17%) 277 7 0
WebDiary Project 211 (94%) 12 (5%) 223 12 13
inGridXppv2 Project 5,390 (81%) 1,242 (18%) 6,632 343 17
inGridX409 Project 8 (100%) 0 (0%) 8 1 0
Monoton_DS Project 9,719 (91%) 893 (8%) 10,612 609 0
inGrid Project 818 (91%) 80 (8%) 898 38 42



Filename: InGridX1.vbp
Type: ActiveX Dll
BuildFilename: InGridX.dll

References:Name Filename Description Type Version
VBA msvbvm60.dll Visual Basic For Applications TypeLib 6.0
VBRUN msvbvm60.dll\3 Visual Basic runtime objects and procedures
TypeLib 6.0
VB vb6.olb Visual Basic objects and procedures TypeLib 6.0
stdole stdole2.tlb OLE Automation TypeLib 2.0
MSXML2 msxml4.dll Microsoft XML, v4.0 TypeLib 4.0
VBHelper VBHlp32/Zlib/CopyMemory TypeLib TypeLib 1.0
GIF89LibCtl gif89.oca Gif89 1.0 TypeLib 1.0
SHDocVwCtl ieframe.oca Microsoft Internet Controls TypeLib 1.1
DAO dao360.dll Microsoft DAO 3.6 Object Library TypeLib 5.0
AgentObjectsCtl agentctl.oca Microsoft Agent Control 2.0 TypeLib 2.0
SpeechLib sapi.dll Microsoft Speech Object Library TypeLib 5.0
DxVBLibA dx8vb.dll DirectX 8 for Visual Basic Type Library TypeLib
1.0
Shell32 shell32.dll Microsoft Shell Controls And Automation TypeLib
1.0
Monoton_DS monoton_ds_en.vbp Project 0.0
MSComctlLib mscomctl.ocx Microsoft Windows Common Controls 6.0 (SP6)
TypeLib 2.0
MSComCtl2 mscomct2.ocx Microsoft Windows Common Controls-2 6.0 (SP6)
TypeLib 2.0
VolumeCtrl volumectrl.oca VolumeCtrl TypeLib 2.0
SplitterX splitterx.oca SplitterX TypeLib 2.0
HyperLinkLbl hyperlinklbl.oca HyperLinkLbl TypeLib 2.0
PicClip picclp32.ocx Microsoft PictureClip Control 6.0 (SP6) TypeLib
1.1
RichTextLib richtx32.ocx Microsoft Rich Textbox Control 6.0 (SP6)
TypeLib 1.2
MSFlexGridLib msflxgrd.ocx Microsoft FlexGrid Control 6.0 (SP6)
TypeLib 1.0
MSWinsockLib mswinsck.ocx Microsoft Winsock Control 6.0 (SP6) TypeLib
1.0
MsghookLib msghoo32.oca Msghook OLE Custom Control module TypeLib 1.0

Jimekus

1/24/2012 1:39:00 AM

0

On Jan 24, 1:57 pm, ralph <nt_consultin...@yahoo.net> wrote:
> On Mon, 23 Jan 2012 18:29:00 -0600, ralph <nt_consultin...@yahoo.net>
> wrote:
>
> Just thought of something obscure.
>
> In the .VBP file, just after the GUID there will be some number
> delimited by nanograms... eg.
>     Object =  (...GUID...) }#1.3#0; <name>
>
> That is the TypeLib version number.
> Reset it to Version 1 ...
>      #1.0#
>
> If that doesn't work try changing versions up to 1.3.
>
> Note: Type library versions are often different from component/file
> versions.
>
> -ralph

I tried up to version 1.3 but VB6 loaded the project saying, "Version
1.3 of C:\Ingrid\mscomctl.ocx is not registered. The control will be
upgraded to version 2.0". It only loads when the version in the vbp
file is 2.0

Jimekus

1/24/2012 2:12:00 AM

0

On Jan 24, 2:38 pm, Jimekus <jime...@gmail.com> wrote:
> On Jan 24, 1:57 pm, ralph <nt_consultin...@yahoo.net> wrote:
>
>
>
>
>
>
>
>
>
> > On Mon, 23 Jan 2012 18:29:00 -0600, ralph <nt_consultin...@yahoo.net>
> > wrote:
>
> > Just thought of something obscure.
>
> > In the .VBP file, just after the GUID there will be some number
> > delimited by nanograms... eg.
> >     Object =  (...GUID...) }#1.3#0; <name>
>
> > That is the TypeLib version number.
> > Reset it to Version 1 ...
> >      #1.0#
>
> > If that doesn't work try changing versions up to 1.3.
>
> > Note: Type library versions are often different from component/file
> > versions.
>
> > -ralph
>
> I tried up to version 1.3 but VB6 loaded the project saying, "Version
> 1.3 of C:\Ingrid\mscomctl.ocx is not registered. The control will be
> upgraded to version 2.0". It only loads when the version in the vbp
> file is 2.0

Monoton_DS monoton_ds_en.vbp Project 0.0

This turned out to be the problem. It was a reference in my vbp to a
compiled vb6 dll that was also a project. Fortunately, it only had a
small form that pointed to it and it was an unused stub anyway as I
had decided not to attempt an on the fly FFT for my harmonic
beatmixing section and instead had used Rapid Evolution 3 to precode
the Camelot Key Signatures into all my MP3s.

Thanks for all the help.

ralph

1/24/2012 12:40:00 PM

0

On Mon, 23 Jan 2012 17:08:11 -0800, "Bob Butler"
<bob_butler@cox.invalid> wrote:

>
>"ralph" <nt_consulting64@yahoo.net> wrote in message
>news:tovrh796dmn01ag6jacu4keq46ui0okge9@4ax.com...
>> On Mon, 23 Jan 2012 18:29:00 -0600, ralph <nt_consulting64@yahoo.net>
>> wrote:
>>
>> Just thought of something obscure.
>>
>> In the .VBP file, just after the GUID there will be some number
>> delimited by nanograms... eg.
>> Object = (...GUID...) }#1.3#0; <name>
>
>I've heard them called hash marks and pound signs and probably a few others
>but never heard them called billionths of a gram before... <g>

Picked that up from Joe Campbell (of serial communications fame) back
in the mid-eighties, who enjoyed pointing out that of all the symbols
in the ASCII table the "#" had no name. I've no doubt it is a totally
made-up word, likely by him and him along, and carries with it a bit
of tongue in cheek.

nano = nine
-gram = is a suffix meaning drawn or written
Therefore nanogram = nine boxes/spaces

Mr. Campbell had a big impact on my career and I guess I just kept the
word going all these years out of respect.

Later while working for a telecommunications company in the late
ninties I ran across "octothorpe", as the "official AT&T name" for the
keyboard character, which seems to show up more often now days. But I
keep forgetting to use it. (Probably for the best. <g>)

-ralph

ralph

1/24/2012 12:46:00 PM

0

On Mon, 23 Jan 2012 18:11:57 -0800 (PST), Jimekus <jimekus@gmail.com>
wrote:

>
>Monoton_DS monoton_ds_en.vbp Project 0.0
>
>This turned out to be the problem. It was a reference in my vbp to a
>compiled vb6 dll that was also a project. Fortunately, it only had a
>small form that pointed to it and it was an unused stub anyway as I
>had decided not to attempt an on the fly FFT for my harmonic
>beatmixing section and instead had used Rapid Evolution 3 to precode
>the Camelot Key Signatures into all my MP3s.
>

Thanks for coming back and letting us know the solution.

-ralph