How to stop VB creating .oca files
Keith Sheppard
would stop. I don't care about the extra efficiency this supposedly buys me
but I do care that it keeps getting it wrong. Specifically it keeps trying
to create a .oca for mscomctl.ocx. Whenever it does so, the next time I try
to compile my project the first occurrence of:
dim SomeVariable as ListItem
is flagged with the error "ListItem undefined". To fix the problem I have
to come out of Visual Basic, hand edit my .vbp file to remove the Reference=
line for the .oca file, delete the .oca file itself then go back into VB.
It's then fine until the next time.
At first it was creating mscomctl.oca in C:\Windows\System32 so I hit on the
idea of creating a folder called C:\Windows\System32\mscomctl.oca.
That stopped it for a while but then it started creating them in C:\Program
Files\Microsoft Visual Studio\VB98. So I created a folder called
mscomctl.oca there too and that stalled it for a bit longer. Then it
started making up file names in C:\Program Files\Microsoft Visual
Studio\VB98. So I made the whole darned folder read only. Next VB tried
creating mscomctl.oca in C:\Windows so I put my phantom folder in there too.
Now - you guessed it - it's started making up its own file names in
C:\Windows. I guessed I couldn't make that folder read only so at this
point I have run out of ideas.
This looks like another instance of Microsoft trying to be too clever for
their own good. Is there some way to stop VB creating .oca files or,
failing that, can someone explain why creating mscomctl.oca causes ListItem
to cease to be defined.
Yours in exasperation
Keith
Ralph
"Keith Sheppard" <keith.s...@tesco.net> wrote in message
news:uSP%23CjCU...@TK2MSFTNGP10.phx.gbl...
Frankly, I think we have a case of programmer trying to be too clever for
their own good. Stop wasting time with .oca files. VB likes them, uses them,
and as you have discovered will create them if they come up missing.
The ability to mess around with VB's head enough to get it to ignore a sane
warning is interesting - but not very useful for either your mental health,
or the health of your project.
Nevertheless I doubt a mscomctl.oca file has any effect on causing a
"ListItem" to be undefined - it is far more likely you are not including a
reference to anything that knows what a ListItem is?
Besides - What kind of object is a "ListItem"?
-ralph
MikeD
> would stop.
Nothing you can do, that I know of, to stop it. I *suppose* you might try
denying write permissions to the folder where the OCX file is located, but
no guarantees of anything. Anyway, I seriously doubt the OCA file is the
cause of your problem. What's more likely is that you're not doing
something "right".
> I don't care about the extra efficiency this supposedly buys me but I do
> care that it keeps getting it wrong. Specifically it keeps trying to
> create a .oca for mscomctl.ocx. Whenever it does so, the next time I try
> to compile my project the first occurrence of:
>
> dim SomeVariable as ListItem
>
> is flagged with the error "ListItem undefined". To fix the problem I have
> to come out of Visual Basic, hand edit my .vbp file to remove the
> Reference= line for the .oca file, delete the .oca file itself then go
> back into VB. It's then fine until the next time.
>
A control added via the Components dialog would appear in the .vbp as an
"object", not a "reference", and it should always be the ocx file and not
the oca. IOW, it'd look like this:
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; mscomctl.ocx
My guess is that you're referencing Windows Common Controls from the
References dialog box instead of adding it as a component to the Toolbox.
Add it to the Components dialog box so that it's part of your Toolbox in the
IDE. This doesn't require that you actually create an instance of the
control by placing it on a form (but make SURE that you've unchecked the
option for removing information about unused ActiveX controls in VB's
Options dialog box). Controls should always (and only) be added via the
Components dialog box. Libraries (be they DLLs or TLBs) are added via the
References dialog box.
FWIW, I've NEVER had a problem declaring any variables for common control
objects (such as ListItem), or any other objects exposed by controls.
> At first it was creating mscomctl.oca in C:\Windows\System32 so I hit on
> the idea of creating a folder called C:\Windows\System32\mscomctl.oca.
> That stopped it for a while but then it started creating them in
> C:\Program Files\Microsoft Visual Studio\VB98. So I created a folder
> called mscomctl.oca there too and that stalled it for a bit longer. Then
> it started making up file names in C:\Program Files\Microsoft Visual
> Studio\VB98. So I made the whole darned folder read only. Next VB tried
> creating mscomctl.oca in C:\Windows so I put my phantom folder in there
> too. Now - you guessed it - it's started making up its own file names in
> C:\Windows. I guessed I couldn't make that folder read only so at this
> point I have run out of ideas.
>
I suspect you'd run into similar problems if you tried denying write
permissions as I suggested above. FYI...setting a folder's read-only
attribute is NOT the same thing as denying write permission, but I doubt
even denying write permissions will help as VB's going to create the OCA
file *somewhere*.
> This looks like another instance of Microsoft trying to be too clever for
> their own good.
No, I don't think so. I think this is just another example of someone
trying to blame Microsoft because that person isn't doing things properly
and it's just easier to blame MS.
> Is there some way to stop VB creating .oca files or, failing that, can
> someone explain why creating mscomctl.oca causes ListItem to cease to be
> defined.
As stated, no, I don't think you can stop VB from creating OCA files. As
also stated, my suspicion is that you're doing things incorrectly. I suspect
you're adding the "control" via the References dialog box instead of the
Components dialog box. But without further information from you, that's only
a hypothesis.
--
Mike
Microsoft MVP Visual Basic
Randy Birch
You can't stop it, and it itself won't cause the problems you describe.
Check to ensure that for your existing and new projects that the first four
selected (in order) items under project>references are:
visual basic for applications
visual basic runtime objects and procedures
visual basic objects and procedures
OLE automation
... then any other ms, third party or your own usercontrols. If they appear
above these four items, and they contain a name similar to that in another
file, VB will flag the keyword as unidentified or ambiguous.
--
Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/
Please reply to the newsgroups so all can participate.
Keith Sheppard
>>"object", not a "reference", and it should always be the ocx file and not
>>the oca. IOW, it'd look like this:
>>
>>Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; mscomctl.ocx
>>
>>My guess is that you're referencing Windows Common Controls from the
>>References dialog box instead of adding it as a component to the Toolbox.
my project via the Project Components menu and I do, indeed, have an Object=
line for the ocx in my vbp file. It's identical to the one you quote except
that mscomctl.ocx is in upper case.
The problem is that VB seems to take it upon itself to add a Reference= line
for the .oca file and once it has done so ListItem ceases to be defined.
>>>> This looks like another instance of Microsoft trying to be too clever
>>>> for their own good.
>>
>>No, I don't think so. I think this is just another example of someone
>>trying to blame Microsoft because that person isn't doing things properly
>>and it's just easier to blame MS.
Once I have checked the .vbp file and removed any Reference= line for the
.oca file (and deleted the oca file) the project runs fine from within the
IDE and compiles OK - a couple of times. At some point, though (and I don't
know what it is), VB takes it upon itself to do something to the project
with the result that it no longer compiles. At that point I have to come
out and remove the Reference = line.
VB making unsolicited changes to my project file which prevent it from
subsequently compiling qualifies, in my simple mind, as being too clever for
its own good. Whatever VB thought it was achieving by making this change is
demonstrably unnecessary because it compiled to my satisfaction before. I
am perfectly willing to admit that there may be some error in my environment
but is is a mystery to me what that error might be.
I understand your defence of MS but I still consider it, at the very least,
to be a usability problem if a mistake on the user's part can lead to a
situation of the software making decisions, the reasons for which are not
obvious to the end user and the effects of which are disasterous for him.
On many occasions in the past I have been made aware of usability problems
with my own software and my instinct is to try to fix them, or add code to
detect and warn users making common errors, rather than telling my users
it's their own fault for trying to use it the way they do.
Sorry, that sounds more uppity than it was meant to, but your paragraph made
me feel slightly defensive (but no offence taken and, I hope, none given).
Keith
Randy Birch
I just did a check on 33 meg of vb projects and not one vbp file on my
system has any reference to an OCA file. OCX files, naturally, but never
references to OCA. And believe me, I have done some weird things in VB.
As I mentioned before, and as indicated below, OCA files are used internally
by VB, and VB does not write OCA file reference information to vbp files.
If there is a reference to an OCA file, then you must be manually opening
the References dialog, selecting Browse, typing in *.oca in the Filename box
then selecting an OCA file. This will cause a Reference= entry to be made to
the vbp file, but this is not the correct way to use custom controls.
From the MSDN:
SUMMARY
For every custom control file (.OCX) that Visual Basic uses, there is an
accompanying .OCA file of the same file name. For example, GRAPH16.OCX has
an accompanying .OCA file called GRAPH16.OCA. An .OCA file is a binary file
that functions as both an extended type library file and a cache for the
custom control file.
MORE INFORMATION
A type library is a file or component within another file that contains OLE
Automation standard descriptions of exposed objects, properties, and
methods. The actual working type library for a custom control used in Visual
Basic is a combination of the type library of the control itself and the
additional properties provided by the framework that wrap the control.
Some of the properties of the control are provided by the framework and some
by the control itself. Programmatically, the properties from the framework
and the control all appear as properties of the control.
In order for these properties to appear, Visual Basic creates an extended
type library when the control is loaded into the toolbox. Because the
process of reading the control's type library and creating the extended type
library is time consuming, Visual Basic caches the extended type library
information into an OCA file.
If you delete the OCA file for a control Visual Basic recognized, Visual
Basic will recreate the .OCA file when you load a project requiring the
control. This recreation process comes with a time penalty.
--------------------
You can - for all intents and purposes - forget about oca files. Ignore
them. In fact, you can totally delete all oca files on your system if you
want, as VB will recreate it when it is required.
There are a couple of KB articles regarding bugs with OCA files, such as
"BUG: User Defined Type Referenced by User Control Raises 'Class not
registered' Error Message", "FIX: VB IDE Improperly Changes Registry Entries
of ATL Object Interface When Generating OCA File " and "FIX: User Defined
Type in Public Function of a User Control Fails to Run", but these don't
sound anything like the problem you claim to be experiencing.
: VB making unsolicited changes to my project file which prevent it from
: subsequently compiling qualifies, in my simple mind, as being too clever
for
: its own good. Whatever VB thought it was achieving by making this change
is
Remember that the vbp file is owned by VB, so changes VB makes to the file
data to support activities you've requested it perform (ie. add controls or
references) can hardly be called an unsolicited change.
: I understand your defense of MS but I still consider it, at the very
least,
: to be a usability problem if a mistake on the user's part can lead to a
: situation of the software making decisions, the reasons for which are not
: obvious to the end user and the effects of which are disastrous for him.
I won't speak for MikeD, but I don't see his response as providing any
defense of MS in any way. MikeD and I are trying to educate you as to the
facts so you can better identify the real problem.
Ralph
"Randy Birch" <rgb_rem...@mvps.org> wrote in message
news:e%23I3org...@TK2MSFTNGP09.phx.gbl...
Randy,
An excellent summary of the simple fact - leave .oca files alone.
But I will take exception with one minor item. It is possible on some
occasions to find a reference to an .oca file in the .vbp. The more frequent
problem (.001% ???) is to find a registery entry pointing to an .oca file
instead of the constructed .dll. (Which is something VB actually does
internally.)
The two phenomena are likely related, with the 'bad' registry entry the
predecessor or cause for the erroneous entry in a .vbp. The 'bad' registry
entry can also cause an .oca file to appear when you query for "References"
or a "Component" (without having to specifically filter for it) - making it
very easy to select an .oca over a .dll if one is not careful. (This latter
situation may be the number one cause, as you noted, for an .oca reference
to appear in a .vbp.)
In any case, I agree, it is not a spontaneous or random phenomena and is
always proceeded by a series of unfortunate events. It is also related to
experience - while I can't remember it happening to me in recent memory - I
can guarantee that someone in any new class of 30, or one of the 3 or 4 new
guys on the team - will experience the problem.
-ralph
Ralph
reference to a .oca file in past .vbp files simply because having such a
reference (either in the project file, or in the registry) is a prelude to
disaster.
-ralph
Keith Sheppard
>>internally
>>by VB, and VB does not write OCA file reference information to vbp files.
>>If there is a reference to an OCA file, then you must be manually opening
>>the References dialog, selecting Browse, typing in *.oca in the Filename
>>box
>>then selecting an OCA file. This will cause a Reference= entry to be made
>>to
>>the vbp file, but this is not the correct way to use custom controls.
I vehemently deny doing this. It's hard to imagine a scenario in which one
might do such a thing once, by accident, but this is an almost daily
occurrence for me. Most times I don't go anywhere near the references. I
just change some code, recompile and bang. This in a VB session in which I
successfully compiled the project maybe 15 minutes earlier.
It's one of those situations that I keep telling myself "this can't be
happening" yet the evidence of my senses is that it does happen. Maybe it's
some wierd quantum effect.
Keith
Ralph
Check out the registry and see if you multiple entries and or references to
an .oca file. You might just go ahead and clean it up.
Forgetting the ".oca issue" for the moment. The most common cause for VB6 to
provide the bogus error "undefined" is a missing or errant reference, and it
doesn't necessarily (in fact, usually never does) have anything to do with
the library or variable the IDL is highlighting.
The solution lies there somewhere and most likely with one of your own
components or Interface modules. Check and make sure that any compatibility
is set to a concrete product in a separate folder. Make sure 'group' builds
are done in logical order. yadda, yadda...
-ralph
Randy Birch
post the contents of the actual vbp file with the oca reference you
describe?
--
Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/
Please reply to the newsgroups so all can participate.
"Keith Sheppard" <keith.s...@tesco.net> wrote in message
news:OBwilKkU...@TK2MSFTNGP09.phx.gbl...
: >>As I mentioned before, and as indicated below, OCA files are used
:
:
Ken Halter
> Weird. Can you reproduce this problem in another minimal project? Can you
> post the contents of the actual vbp file with the oca reference you
> describe?
fwiw, I get oca references too. CommonDialog and CommonControls give me the
most greif. A few of our 'custom' controls cause problems too. It sure seems
like some kind of hard-drive write buffering problem to me and it gets worse
as Windows Updates are released. Back in the NT4 days, it never happened.
Win2k started showing "signs" after about SP2. Long story short, the problem
just keeps getting worse.
> --
>
> Randy Birch
> MS MVP Visual Basic
> http://vbnet.mvps.org/
>
> Please reply to the newsgroups so all can participate.
--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
MikeD
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:uPIpWq0U...@TK2MSFTNGP14.phx.gbl...
> "Randy Birch" <rgb_rem...@mvps.org> wrote in message
> news:egvYEooU...@tk2msftngp13.phx.gbl...
>> Weird. Can you reproduce this problem in another minimal project? Can
>> you
>> post the contents of the actual vbp file with the oca reference you
>> describe?
>
> fwiw, I get oca references too. CommonDialog and CommonControls give me
> the most greif. A few of our 'custom' controls cause problems too. It sure
> seems like some kind of hard-drive write buffering problem to me and it
> gets worse as Windows Updates are released. Back in the NT4 days, it never
> happened. Win2k started showing "signs" after about SP2. Long story short,
> the problem just keeps getting worse.
>
I've never encountered or even heard of this problem before. This would be
under Win2000 (all service packs at one time or another) and WinXP (with SP1
and SP2). Of course, I never use the CommonDialog control (haven't for
years, but even when I did, I never had this problem), but I use the
CommonControls all the time.
Ken Halter
news:e416aa4U...@TK2MSFTNGP09.phx.gbl...
>
> I've never encountered or even heard of this problem before. This would
> be under Win2000 (all service packs at one time or another) and WinXP
> (with SP1 and SP2). Of course, I never use the CommonDialog control
> (haven't for years, but even when I did, I never had this problem), but I
> use the CommonControls all the time.
>
> --
> Mike
> Microsoft MVP Visual Basic
Since I seem to get the problem at work more than at home, it may have
something to do with McAfee or Networking. fwiw, it happens so often that,
when I finally get the time to go back to work on ComGuard, I'll be adding
functionality that will fix it.
Keith Sheppard
>>reference you describe?
since you posted this request the problem hasn't occurred - and I never kept
any of the old ones.
Actually this isn't as surprising as it might at first seem because I have
all but finished my current major enhancements programme, so I am not
editing and recompiling nearly as often. If and when I get another
instance, I will post the file.
Keith
Keith Sheppard
>>reference you describe?
identical, to my original problem. As I said, for the last few sessions
I've been able to edit and compile without problem. Then suddenly, this
morning, I loaded up my project and a whole bunch of forms reported object
errors when trying to load. The log files all contained lines of the form:
Line 57: Class MSFlexGridLib.MSFlexGrid of control NonMemberGrid was not a
loaded control class.
I came out of vb and looked at the .vbp file with a text editor. It
started:
Type=Exe
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\WINDOWS\system32\stdole2.tlb#OLE
Automation
Reference=*\G{1CB3062F-B67B-4E30-B12E-8C7D3F67B7CE}#f.0#0#..\..\..\..\Program
Files\Scorer\KRSTelephone.dll#KRSTelephone
Reference=*\G{42EE07BA-D195-4DDA-AF73-9F869CFA84DD}#1.0#0#..\..\..\..\WINDOWS\system32\BrowseForDirectory.dll#BrowseForDirectory
1.0 Type Library
Reference=*\G{EF53050B-882E-4776-B643-EDA472E8E3F2}#2.7#0#..\..\..\..\Program
Files\Common Files\System\ado\msado27.tlb#Microsoft ActiveX Data Objects 2.7
Library
Object={860BCAA4-B13A-4F19-97E4-DCA4FACF5FB0}#1.0#0; KRSBridgeControls.dll
Reference=*\G{D6A064BF-88B5-4007-9467-8AA88C0009DC}#1.0#0#..\..\..\Controls\KRSSockets\Debug\KRSSockets.dll#KRSSockets
1.0 Type Library
Reference=*\G{75FF277F-DEF3-40B3-ABF6-97F97B1305E5}#4.1#0#..\Club Option
Pack\Support\KRSMembership.dll#
Reference=*\A..\FlatFiles\KRSPlayers.vbp
Reference=*\G{591EEE4E-7022-4984-B999-9C78D9B99C8A}#1.0#0#..\..\..\..\WINDOWS\system32\MSFLXGRD.oca#Microsoft
FlexGrid Control 6.0 (SP6)
Object={5E9E78A0-531B-11CF-91F6-C2863C385E30}#1.0#0; MSFLXGRD.OCX
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; comdlg32.ocx
Object={6BBC8FD9-03A1-11D3-987D-00A0C99C39AA}#2.1#0; SelectorControl.ocx
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Based on previous experience, I deleted the Reference= line which refers to
MSFLXGRD.oca. Having done so, I went back into VB and was able to load up
the project without any problems. Yet again, VB has converted a working
project into a non working one by inserting what appears to be a totally
unnecessary a .oca reference. I did not make any changes to the components
or references of my project.
Keith
Ken Halter
> Reference=*\A..\FlatFiles\KRSPlayers.vbp
> Reference=*\G{591EEE4E-7022-4984-B999-9C78D9B99C8A}#1.0#0#..\..\..\..\WINDOWS\system32\MSFLXGRD.oca#Microsoft
> FlexGrid Control 6.0 (SP6)
>
> to MSFLXGRD.oca. Having done so, I went back into VB and was able to load
> up the project without any problems. Yet again, VB has converted a
> working project into a non working one by inserting what appears to be a
> totally unnecessary a .oca reference. I did not make any changes to the
> components or references of my project.
>
> Keith
Have you noticed this happening more often when you load a project group?
The reference to KRSPlayers.vbp makes it seem like a group project (it must
be). fwiw, about 80% of my coding is done while working on a project group
(a testbed exe and whatever dll I'm working on) so I'm wondering if that has
something to do with the problem.
Note that this is nothing new (if I could get to the group search right now
I'd post a few threads but google's blocked right now here.... arghhh) I've
just never noticed if it was a "project group only" problem.
Keith Sheppard
I normally open it as a project group. It's an application and two or three
related ocx projects so it makes sense to do it that way. In fact, I hardly
ever open the components separately.
So, to answer your question, yes I only ever observe this problem when
opening a project group but I seldom work any other way.
In fact, the only time I open individual projects is to recompile one of the
OCX components. I have found vb is a little reluctant, sometimes, to let go
of the .ocx file.
Perhaps I should try opening the application project separately. The
trouble is, with it being an intermittent problem anyway, how many times do
I have to observe it not happening to know that it's group related?
Keith
Ken Halter
It's supposed to replace the ocx reference with an oca while running in the
IDE. The problem is.... VB's retaining the reference to the OCA when you
(we) save. I still think it's due to some 'delayed write to disk' or
something. It happens (or at least seems to happen) more as time goes by. I
can't remember NT4 ever having the problem. Win2k started about SP2 and it's
gotten worse since. It's very unpredictable here too. SourceSafe is my
friend <g>.... unless I check in a project that contains the bad reference.
Even then, it's only an annoyance.... a "throw the PC out the window" type
annoyance when it happens several times in a row <g>
Keith Sheppard
I'm not alone. It doesn't somehow seem so bad now that I understand, to
some degree, what's causing it.
I think the thing which surprised me most of all was VB's resourcefulness at
finding ever more bizarre places to hide the .oca file. As I said in my
original posting, I kept blocking places (either by creating a directory
called xxx.oca, or making whole folder read only) and VB would just find
somewhere else to put it. It almost turned into a sort of game. Alright
you b****, where have you hidden it this time?
Keith
Tony Proctor
with groups that involve UserControls.
The OCA files are registered with a different Typelib ID in the registry.
You can see this by just searching HKEY_CLASSES_ROOT\Typelib for your
project name. It felt to me like the included project was referencing the
OCAs Typelib, and that was somehow getting inherited by the main project.
Hence, when it came for VB to update the VBP file for the main project, it
was fooled into thinking it needed an extra Reference line for the OCA
Typelib.
Tony Proctor
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:OviwKcQV...@TK2MSFTNGP10.phx.gbl...
Ken Halter
news:ehRXIkJW...@TK2MSFTNGP03.phx.gbl...
>I think you're on the right track there Ken. I get some odd things
>happening
> with groups that involve UserControls.
I wish the problem was limited to VB authored usercontrols. Mine are caused
mostly by the Common Dialog control. Following that, I'd say the SSTab
followed by MS Common Controls.... our VB authored controls cause problems
sometimes too but very rarely (especially when people find out they need to
close the usercontrols designer before looking at the form that contains
them <g>)
> The OCA files are registered with a different Typelib ID in the registry.
> You can see this by just searching HKEY_CLASSES_ROOT\Typelib for your
> project name. It felt to me like the included project was referencing the
> OCAs Typelib, and that was somehow getting inherited by the main project.
> Hence, when it came for VB to update the VBP file for the main project, it
> was fooled into thinking it needed an extra Reference line for the OCA
> Typelib.
>
> Tony Proctor
Sounds like a decent diagnosis. Too bad we'll just have to live with it at
this point <g>. fwiw, my ComGuard add-in "reverse engineers" any OCA
references it finds so the references list it generates actually contains an
ocx instead of a worthless oca. I'm in the middle of adding unrelated
functionality but when I'm done with that, I'm going to look into adding
functionality that would check and hopefully fix any 'rogue' references.