In the system32 directory I saw an .OCX file with a corresponding .OCA file.
I had thought .OCA files are used only by Visual Basic. Are they therefore unnecessary for program execution and could be removed?
If they are unnecessary, why would there be an .OCA in the system32 folder in the first place?
.OCA files serve as a cache of the extended type library information for its corresponding .OCX file.
If you delete an .OCA file for a control VB recognizes and uses, VB will recreate the .OCA file when you load a project requiring the control. The recreation process takes a little time but comes with no penalty otherwise.
Last reviewed: April 4, 1996
Article ID: Q149429
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 re-create the .OCA file when you load a project
requiring the control. This re-creation process comes with a time
penalty.
(http://support.microsoft.com/kb/149429)
So, don't worry about including them when you deploy your application.
Sorry to resurrect a zombie thread, but I want to summarize to make sure I understand this.
An OCA file is only needed during compilation of a program and if it is missing, VB will create what it needs so all that is lost is time during compiling. Unless you have really sloppy programming and another homemade dll or ocx needs a particular oca.
If an oca is shipped with a product, it should be able to be safely deleted.
No, they are not necessary for it to execute but they are necessary for the program to run properly (if the program required the file in the first place).
They never need to be deployed with a finished program for it to run.
This could be a dumb attempt to answer, but you could simply rename the file and see if the application quits working. If so, those files are necessairy.
DNA-science is about the same:
Remove a gene and see what stopped "working". De facto, this gene is related to / necessairy for that body-part or whatever.
Re: No, they are not necessary for it to execute but they are necessary for the program to run properly (if the program required the file in the first place).
Since execute and run mean the same thing - what you are saying is that:
it's not required for it to run but it's required for it to run properly??
or alternately
it's not required for it to execute but it's required for it to execute properly??
I am suspecting that the *.OCA files are not required EXCEPT for compiling a program using VB and if they don't exist when you load a project then VB will create any missing OCA files automatically in order to speed up future load or compile operations in VB.
I just deleted EVERY OCA file off my system (I'm a brave man when I'm using a cloned virtual machine to do this).
I then rebooted and ran my software and it worked just fine without ANY OCA files on my entire system. Now it might take a bit longer to load/compile my programs next time as vb will regenerate the OCA files but I'm using an i7 with 16Gb of RAM and an SSD so who cares!
Related
I have an old program that was made for us a looong time ago. It consists of a large MDB (Access) file with all the data (no encryption, I can manually open the file and browse all the data) and an EXE file (probably VB?) that was custom made to easily manage the data in the file.
I'm trying to move this program for another user, to run in his own laptop.
First I tried just copying all the files, but I had MSCOM, GRD, LST, and ocx missing file errors. I tracked them all down and regsvr32'd them, and the program seemed to go a little further.
Then I got an ODBC connector error. Playing with ODBC sources manager and I added an entry with the name of the program that points to the specific MBD file. This helped too.
Now program starts and shows all menus, buttons and everything. However, the default record that should be onscreen is empty and as soon as I hit any control (next record, list, etc...) it crashes with a VB error 91:
Run-time Error '91': Object variable or With block variable not set
So it looks like the program can open the database file itself but it cant really access the data inside.
What else can I try to see what I need to set it all up correctly? Is there anything that "spies" inside and VB program to see how it's trying to access the MDB file?
Any help would be appreciated!
Probable cause of your problem is some missing dll/ocx file referenced in your application. Open your exe file with notepad (or notepad++) and find all occurrences of .dll and .ocx files and check if those
files exist at user's laptop. If not, just copy them from your working machine and regsvr32 them.
I will go with #smith suggestion.
While looking at the error message on microsoft's website, below is the solution that applies to your scenerio
"The object is a valid object, but it wasn't set because the object library in which it is described hasn't been selected in the Add References dialog box."
So ensure all files are correctly copied to new system.
So the images below were originally a vb files. I have just opened it and it looks like this and the compiler won't run it. I am unsure whether this is a compiler error or whether it may have become corrupt because the project is stored on an external drive. It is just these two forms that have broken like this; I have one other form and a module in the same project that are okay but the project can't run because of the two that are broke.
Broken Login Form
Broken Diary Form
If it changes anything, the designer files for the forms are intact it is just the scripting for the forms elements that is broken.
Also, if I can't identify the cause, is there a way to revert it back to the last working version in visual studio to get my code back? Just because I put a lot of time into it.
The data in those files is most likely gone.
IMPORTANT: Do not write anything to that disk drive unless you find that you cannot recover those files.
If you are using a version control system then you can revert to an earlier version.
If you are using Windows 10 and you happen to have stored those files in a location included in what File History saves, you can recover them from that.
If you use some other form of backup, retrieve the files from that.
If you have a separate disk drive with at least as much free space as the one with the corrupted files, you could try running file recovery software as it might be that the zeroed-out file was written to a different place on the HDD.
TinTnMn pointed out in a comment that if you previously compiled the code, you should have executable files in the "obj" and "bin" folders that can be decompiled to recover most of your work
It could be quicker to re-write the code while it is still fresh in your mind.
I'm in the process of building a program that has several external libraries and extensions outside of the main program files. My projects total size is 134.2 MB. I would like to make a portable version of it with Turbo Studio, but I face one glaring problem; After capturing the files and building the project I'm left with a 138.9MB executable. The program does run, but I don't want it to be so bloated.
I would like to bundle the bulk of the data as a separate .dat payload (or equivalent) but I can't seem to find any means of doing this with Turbo Studio. VMware ThinApp and Cameyo both do this automatically after the project exceeds a certain size, but it would appear that Turbo Studio doesn't.
Any help with is greatly appreciated.
There was a hack I had discovered some time ago that did exactly what you were asking.
It appears that the site that described it is not online anymore so read on.
Install your application while monitoring with TurboStudio.
If there are multiple entry points (e.g., a suite like office may have
shortcuts for excel, word etc) then make sure there are shortcuts for those entry points in the Start Menu. If there are not, then click Start, right click on All Programs, then Open All Users. Make sure you create in that folder shortcuts for all your desired entry points (e.g., one shortcut for word, one for excel etc.)
Capture and Diff with TurboStudio. Set your virtualization settings as desired.
Click Output File-->Browse, and select "All files(.)" in the Save as type list. Then enter a filename with the extension .dat
Build your app. You will now get a .dat file instead of an .exe
In the next step you must use ExeBuilder.exe. This file was originally hosted in csgotwisted.com. Do a google search for "2 utilities for spoon studio exebuilder" and it will most likely be the first result. Unfortunately, the link is dead now when I click it. So I uploaded the file to NitroFlare. You can find it here. Put it in the same folder as the .dat file and run it. It will create a shortcut with your executable. Sometimes it misses the icon, but it gives you the option to locate it manually.
I use TurboStudio often and I have found this way to be the most quick and reliable in allowing me to generate small executables and storing the virtual filesystem and registry in a .dat file. In addition, it has the advantage that it can get you multiple entry points and not only one, just like Thinapp does.
I'm maintaining a VB6 application with many COM components (DLLs and OCXs). In order to streamline development and deployment I'd like to use reg-free com. The problem with development is that the application runs within the VB6.EXE instance. How can I trick VB6 to use my (unregistered) components? It is very important for me to not have to go through registering/unregistering components when switching between branches. Generating a .manifest file for VB6 is not out of the question but is there some other, more optimal way, to specify a .manifest file when launching VB6.EXE?
Note: The Activation Context API doesn't seem to help, even if used from within the development environment.
Solutions I've thought:
A utility application that activates a context from a manifest and launches VB6 as a child process (doesn't work; processes don't inherit activation context)
Injecting context activation into the VB6 process at startup (too complicated; must hack the executable to do this)
Hosting VB6 in my own process after activating the right context (can't even find out if this is possible)
Using a VB6 Add-In or other utility that runs within VB6 to activate a context (tried that but it doesn't seem to work)
Update Jan. 16
As suggested by wqw, I did some testing with a VB.exe.manifest. The VB6.exe.manifest worked, with some caveats:
The SxS dll specified in the manifest would not appear in the references window on projects that didn't actually reference the component
On projects that did reference the component it would be shown to reside in the directory according to the following order:
The pathname recorded in the project file (if the file was still present)
A pathname as if it resided in the same folder as the project (vbp)
If the file was not in any of these folders, the project would not compile (just running the code causes an internal compile in VB6) with the message "Can't find project or library".
Obviously, VB6 actualy scans the registry to find COM components and verifies, during compilation, that they exist where they say they exist. I'm not sure what that might mean if I actually want to use VB6.exe.manifest to redirect COM component instantiation. Perhaps having dummy component files at some predefined location might trick VB6 into believing that everything is as it should be, although an entirely different set of components got loaded for use.
Further update:
I did a test on that last assumption and it proved to be false. The component has to actually be there in order for the project to compile. It must even properly load (no dummy, zero-length files accepted!). Now I'm not even sure if the manifest works. That's a more time-consuming test (requires a component with two versions that produce different results, one with the project, and one for the manifest).
Our approach to this problem was to write a build assist program that registered and unregistered components, run the VB6 compiler, and would even rewrite project files with updated GUIDs when interfaces changed. You would hand it a VBG project group and it would do the rest.
I suppose we could also have added a mode that unregistered components when you switched branches.
Are you following the practice of using "compatibility" binaries? You shouldn't use the binary at your build location for compatibility references - you should commit a separate copy to version control and configure your project to consider that the "compatible" version - only change this file when you break interfaces.
Are there any VC++ settings I should know about to generate better PDB files that contain more information?
I have a crash dump analysis system in place based on the project crashrpt.
Also, my production build server has the source code installed on the D:\, but my development machine has the source code on the C:\. I entered the source path in the VC++ settings, but when looking through the call stack of a crash, it doesn't automatically jump to my source code. I believe if I had my dev machine's source code on the D:\ it would work.
"Are there any VC++ settings I should know about"
Make sure you turn off Frame pointer ommision. Larry osterman's blog has the historical details about fpo and the issues it causes with debugging.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code.
What version of VS are you using? (Or are you using Windbg?) ... in VS it should defintely prompt for source the first time if it doesn't find the location. However it also keeps a list of source that was 'not found' so it doesn't ask you for it every time. Sometimes the don't look list is a pain ... to get the prompt back up you need to go to solution explorer/solution node/properties/debug properties and edit the file list in the lower pane.
Finally you might be using 'stripped symbols'. These are pdb files generated to provide debug info for walking the callstack past FPO, but with source locations stripped out (along with other data). The public symbols for windows OS components are stripped pdbs. For your own code these simply cause pain and are not worth it unless you are providing your pdbs to externals. How would you have one of these horrible stripped pdbs? You might have them if you use "binplace" with the -a command.
Good luck! A proper mini dump story is a godsend for production debugging.
If your build directly from your sourcecode management system, you should annotate your pdb files with the file origins. This allows you to automatically fetch the exact source files while debugging. (This is the same proces as used for retrieving the .Net framework sourcecode).
See http://msdn.microsoft.com/en-us/magazine/cc163563.aspx for more information. If you use subversion as your SCM you can check out the SourceServerSharp project.
You could trying using the MS-DOS subst command to assign your source code directory to the D: drive.
This is the procedure I used after some trouble similar to yours:
a) Copied to the production server all the EXE & DLL files that were built, each with its corresponding PDB to the same directory, started the system, and waited for the crash to happen.
b) Copied back all the EXE, DLL & PDB files to the development machine (to a temporary folder) along with the minidump (in the same folder). Used Visual Studio to load the minidump from that folder.
Since VS found the source files where they were originally compiled, it was always able to identify them and load them correctly. As with you, in the production machine the drive used was not C:, but in the development machine it was.
Two more tips:
One thing I did often was to copy an EXE/DLL rebuilt and forget to copy the new PDB. This ruined the debug cycle, VS would not be able to show me the call stack.
Sometimes, I got a call stack that didn't make sense in VS. After some headache, I discovered that windbg would always show me the correct stack, but VS often wouldn't. Don't know why.
In case anyone is interested, a co-worker replied to this question to me via email:
Artem wrote:
There is a flag to MiniDumpWriteDump()
that can do better crash dumps that
will allow seeing full program state,
with all global variables, etc. As for
call stacks, I doubt they can be
better because of optimizations...
unless you turn (maybe some)
optimizations off.
Also, I think disabling inline
functions and whole program
optimization will help quite a lot.
In fact, there are many dump types,
maybe you could choose one small
enough but still having more info
http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
Those types won't help with call stack
though, they only affect the amount of
variables you'll be able to see.
I noticed some of those dump types
aren't supported in dbghelp.dll
version 5.1 that we use. We could
update it to the newest, 6.9 version
though, I've just checked the EULA for
MS Debugging Tools -- the newest
dbghelp.dll is still ok to
redistribute.
Is Visual Studio prompting you for the path to the source file? If it isn't then it doesn't think it has symbols for the callstack. Setting the source path should work without having to map the exact original location.
You can tell if symbols are loaded by looking at the 'modules' window in Visual Studio.
Assuming you are building a PDB then I don't think there are any options that control the amount of information in the PDB directly. You can change the type of optimizations performed by the compiler to improve debuggabilty, but this will cost performance -- as your co-worker points out, disabling inline will help make things more obvious in the crash file, but will cost at runtime.
Depending on the nature of your application I would recommend working with full dump files if you can, they are bigger, but give you all the information about the process ... and how often does it crash anyway :)
Is Visual Studio prompting you for the
path to the source file?
No.
If it isn't then it doesn't think it has symbols
for the callstack. Setting the source
path should work without having to map
the exact original location.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code. I can of course search in files for the line in question, but this is hard work :)