I have inherited an old VBP project that is ostensibly usable in Visual Basic 6.
It has two .ocx files which, research seems to indicate, need to be registered with regsvr32. Loading VB6 onto a Windows XP installation seems to allow me to successfully register them both.
However, VB6 still chokes on them. When I load the project, two errors are logged:
Line 228: Class CvsInSightDisplayOcx.CvsInSightDisplay of control Camera1 was not a loaded control class.
Line 5841: Class Xtimer01.Xtimer of control Xtimer1 was not a loaded control class.
And, naturally, the project will not compile. What steps can I take to get these .ocx files to play well?
#Bob77's comment led me to a two part resolution.
1) One of the components needed to be formally installed. (Thankfully it was still available.)
2) Both needed to be manually removed from the .vdp file using Notepad, and added via the VB6 UI, through Project -> Components... and 'Browse...'
Related
I have this old VB6 project that is composed of a few DLLs, OCXs, and GUIs.
There is a GUI component that includes this in it's VBP file:
Type=Exe
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#C:\Windows\SysWOW64\stdole2.tlb#OLE Automation
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
Object={3050F1C5-98B5-11CF-BB82-00AA00BDCE0B}#4.0#0; mshtml.tlb
Reference=*\G{64E54C86-D847-48F7-9AE5-D6C9B8E6A3A2}#3.0#0#..\..\bin\Crypt.dll#Crypt
Reference=*\G{B3E7F95C-B6D9-458E-B4D4-5272759B139A}#4.0#0#..\..\bin\SpeechMike.dll#SpeechMike_DLL
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; MSCOMCTL.OCX
Object={AB4F6C60-4898-11D2-9692-204C4F4F5020}#29.0#0; Ccrpsld.ocx
Object={48E59290-9880-11CF-9754-00AA00C00908}#1.0#0; msinet.ocx
Object={9C526969-AA6E-4D61-BAFA-117FD20C2B38}#3.0#0; SpeechMike.ocx
The Reference settings are a pain since they always change from one machine to the other. I mean, the GUID '9C526969-AA6E-4D61-BAFA-117FD20C2B38', for the last one as an example, will be something on my system, but something else on somebody else's machine.
For now, to make it work, I erase References to Crypt.dll and SpeechMike.dll. Also Object SpeechMike.ocx. Otherwise, Visual studio looks for something that does not exists. Then in "project > references" I check both Crypt and SpeechMike and the Reference goes back to the VBP with the proper GUID and version. Finally, in 'project > components' I add the OCX and I'm good to go.
Am I wrong about that? How can I share the project with some else without going through hoops and loops to start the project?
I'm using MS Visual Basic 6 (part of VS 6 enterprise).
This sounds like "failure to maintain binary compatibility." Normally you only do this to yourself, but of course it can be a bigger headache if multiple people are compiling your libraries from the source Project files.
When you create ActiveX EXEs, DLLs and OCXs you need to create a "base" version where type and class ID values (GUIDs) get assigned. The documentation even suggests that you do this leaving the procedures empty: just a comment line or something so the IDE does not remove the empty declarations.
You don't have to use an "empty" base reference library, it can be one with full code in it.
Once you have compiled this baseline library, you'd exit and save your Project. Then rename this "empty" library as something else and from there keep it along with your Project source files.
After this you re-open the Project and go into Project Properties and on the Component tab change the Compatibility setting to Binary Compatibility and in the box there enter the full path and name of your compiled baseline library. Save the Project. Now you can add code and compile the "real" library to be used by other programs.
When you distribute these libraries (DLLs, OCXs) to somebody else in source code form so that they can compile them you must provide this renamed compiled baseline library along with the source code files, VBP file, resource files, etc.
From there your GUIDs will be stable until you make a change to something that breaks binary compatibility (changing a method's argument list, etc.).
There is more detail on this in the online Help (MSDN Library). See:
Using Visual Basic|Component Tools Guide|Creating ActiveX Components|Debugging, Testing, and Deploying Components|Version Compatibility in ActiveX Components
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.
Running Excel 2010, I can assuredly always be running these sheets on this version, as it will only be accessed locally exclusively on my work's terminal computers.
I run a number of import process and large folder filtering/printing batch functions via excel. I am wanting to utilize the Windows 7 taskbar progress bar visual while my functions process, giving an idea of how far they are along. Considered going with other visual effects for showing the progress, but this(if possible) seems the most obvious and professional style to do so.
I've been looking thoroughly into trying to make this work, to no avail. My understanding thus far is that I need to impliment the ITaskbarList3 interface, commonly found within the Windows API. From the code I have found showing how to make it work, once implimented the rest seems fairly easy and self-explanatory.
I am completely restricted to using Excel as the basis for the code, no installation permission on the work computers. I can install at home to get any files necessary, and then transfer them. Happy to use any extensive or really backwards ways to get to the end, as the ends justify whatever means it takes.
It would be much easier to use the Excel Status Bar:
Application.StatusBar = "Show progress to user...";
For the Windows & Taskbar progress bar you need to download the
Windows 7 taskbar: Developer Resources.
You'll need to open the sample solution, right click on the Windows7.DesktopIntegration project > properties > Build > Tick Register for COM.
By checking the "Register for COM interop" option in the IDE during development, the IDE will call regasm on the target assembly together with the /codebase option.
This will cause regasm.exe to add the following registry entry for a COM-visible class exported from your assembly :
HKEY_CLASSES_ROOT\CLSID{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\InprocServer32\CodeBase=
This will enable the CLR to locate your assembly by following the path to your assembly.
Without the codebase path, the CLR will have to locate your assembly (and its dependencies) using the standard search algorithm.
Next Build the solution > goto the bin folder the Windows7.DesktopIntegration project and copy the Windows7.DesktopIntegration.DLL and Windows7.DesktopIntegration.TLB to the System32 folder or better yet Register to the GAC.
One related technique that helps the CLR to locate required assemblies is to copy all assemblies (and their dependencies) to the same folder as the client application itself. However, the client application in your case will be Excel. This means that you must copy the assemblies into the same folder as the Excel application (not a good idea).
Once you are able to instantiate the Windows7.DesktopIntegration DLL, you should be able to call the Windows7Taskbar.SetProgressValue method, eg VBA code:
Set Windows7Taskbar = CreateObject("Windows7.DesktopIntegration")
Windows7Taskbar.SetProgressState(form.Handle, Windows7Taskbar.ThumbnailProgressState.Normal)
Windows7Taskbar.SetProgressValue(form.Handle, progress, maximum)
I am working with Teklynx's Codesoft 9 using their automation controls. Codesoft is a label generation and printing program. I've used its sister product LabelView in the past to automate label printing, but as of LabelView 9 they dropped their automation servers.
You have to add two references: LabelManager2 and TkxRFTAG. LabelManager2 hides in the COM list as TK Labeling ActiveX 6.0 and installed just fine. The reference to the the other has the same name TkxRFTAG as the library.
When I selected it I received this error including the double back slashes.
"Unable to add reference "C:\Program Files (x86)\Teklynx\CODESOFT 9\\TkxRFTag.tlb"
I've had the same problem on several machines. How do you register the type library?
There was something odd with the backslashes, but the key was the registering the library manually.
To do that required the type library registration utility in the .Net folder.
C:\Users\Rich>C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12.exe "C:\Program
Files (x86)\Teklynx\CODESOFT 9\TkxRFTag.tlb"
Registration of TkxRFTAG.tlb successful.
Afterwards I had two TkxRFTAG entries the new one was 2.0 and it added easily to the project reference list. I don't know why there were two of them, I only installed Codesoft right before working with it and it was a new PC. The automation objects are installed with the base software.
We have a DLL which provides the data layer for several of our projects. Typically when debugging or adding a new feature to this library, I could run one of the projects and Step Into the function call and continue debugging code in the DLL project. For some reason, that is no longer working since we switched to Visual Studio 2008... It just treats the code from the other project as a DLL it has no visibility into, and reports an exception from whatever line it crashes on.
I can work around that by just testing in the DLL's project itself, but I'd really like to be able to step in and see how things are working with the "real" code like I used to be able to do.
Any thoughts on what might have happened?
Is the pdb file for the dll in the same directory as the dll? This should all work -- I do just this on a regular basis. Look in the Modules window which will show you whether it's managed to load symbols for the dll. If it hasn't then you won't be able to step into functions in that dll.
It sounds like you have "Just My Code" enabled and VS is considering the other projects to not be your code. Try the following
Tools -> Options -> Debugger
Uncheck "Just my Code"
Try again
I've gotten around this issue by opening a class that will be called in the project you need, placing a breakpoint, keep the file open, and run the debugger. The debugger will hit the breakpoint and the relative path that VS uses will be updated so that future classes will be opened automagically.