how to add ocx files in vb4.0 (I am migrating from vb4 to vb6 - vb6

I am migrating vb4 application to vb6.0 app. I am using windows xp. I want to add ocx controls to the application. Any simple steps to do add ocx controls/files to the application. What are .frm files
Object = "{bla-lablabla-lablabla}#2.0#0"; "THREED20.OCX"
Object = "{blabla-bla-bla-blabla-blablabla}#2.0#0"; "vsview2.ocx"
I want to add these two ocx controls in vb6 ( 16 bit to 32 bit)

You don't state if you already have the OCX files.
To address your first question on how to add OCX controls to your VB6 project. You need to go to Projects -->Components( CtrlT ) then click the Browse button and navigate to where the OCX is located and select it.
As far as the actual OCX Files are concerned there is a Threed20.ocx that is included on the VB6 install media, I believe it is on Disk 2. There is also a registry file that you will need to run to enable design time use of the control. As far as the vsview2.ocx file is concerned if it is not a 32 bit OCX you will need to contact the vendor, who I believe is ComponentSource to get the proper version if you don't currently have it.
And as far is what is a .frm file it is according to this article
A form holds the description of all objects and their properties for each form, as well as the basic code that you have written to respond to the events.

Related

debugging vb6 form inside 3rd party application

I have to travel back in time and debug a VB6 form. It is used inside an application (not ours, Esri ArcMap.exe). I see VB6 has some debug capabilities, but nowhere do I see, like in .NET, the ability to "launch another app" or "attach" to a running application.
How can I debug my VB6 code while running inside a 3rd party application?
It's right there; you just didn't see it.
If your form is hosted inside a DLL (most likely from your description), you have two options, both of which can be set from the "Project"-> "Projectname Properties" dialog box, Debugging tab.
"Wait for components to be created"
When click on Run (F5), VB6 will alter the registry entries for your DLL so that they point to the VB6 debugger.
Launch your third-party program as usual.
When any program tries to create objects and forms hosted by your DLL, it will do so through the debugger.
"Start a program"
Same as before, plus VB6 will execute the command line entered in the dialog box.
It should be noted that VB6 must be run in full "As Administrator" mode, because it needs to write to normally-protected areas of the registry.
Don't worry about the third option. Let's just say that some things are better forgotten.
My first-hand knowledge is a little hazy (I've inherited a PC with all of this stuff configured, and I have no intention of ever setting it up again from scratch...), but here goes:
There is an ESRI VB6 add-in called ESRI Compile and Register, which is supposed to make this whole process a lot easier.
There's a lot of instructions on that link, but one of the key things is under Options->Support Visual Basic Debugger, which creates a file ESRIVBDebugHelper.exe.
In Project -> Properties -> Debugging tab, under Start Program, you enter the full path to this ESRIVBDebugHelper.exe. Then when you debug the VB6 application, it should spawn ArcMap and allow you to debug on the fly within the VB6 IDE.

Why does my DLL not seem to be called?

I have a COM DLL, coded in Delphi. It should be invoked via an Active X control when a web page loads in MS IE (via soem JavaScript on the page).
Btw, this all works fine with an existing serial port interface, but I am recoding teh DLL to read from USB; all else is unchaged.
It works fine in the Delphi IDE, but not "in the field". The active X control should request it to read some input from a USB port and should then send that to the web page.
Reading from the USB device works, as I can open Notepad and see the value being written there.
The DLL will display a form, and a dialog box, and will write to the system debug trace. Since I am seeing none of these when loading the web page in MS IE, I think we can assume that Aective X control is not calling into the DLL.
In MS IE I have enabled all Active X options.
in c:\Windows\System32 (which is equivalent to c:\Windows\SysWOW64), I have regsvr32.exe -u my_dll.dll and then regsvr32.exe my_dll.dll both of which the system announced to be successful
I searched, and there is only one copy of my_dll.dll under c:\Windows
and it has the correct size and date/time
my %path% is %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem; for system and empty for user
Any idea what I am doing wrong? Or how I can go about tracking it down?
If you are loading the ActiveX control in webpage through javascript, you will have to package the control for web deployment. See this example for how to do this in your javascript and check whether you have done properly it or not:
Calling Activex Control 's Functions from javascript
Once you do the above thing correctly and open your website in IE, the web-page will at least "load" the ActiveX control. Beyond that, you can display message-boxes or write logs in your Delphi code to track down the actual coding issues.

Properties of richtextbox control cannot be set

On one computer 'A' (win vista 32 bit) if I run my program in debug mode all the richtextbox controls throw 'property cannot be set' errors.
I can go on to build the exe (without error ) and the full application OK
But when I then install and run the application on this computer or on computer 'B' (win xp) the same problems occur on both.
However if I run the exact same code in debug mode on computer 'B' there are no errors.
If I build and install the application on computer 'B' it works fine. If I then install this application on computer 'A' it also works fine.
When putting together the application for distribution, both computers use identical copies of richtx32.ocx (it, like the code, is checked out from the same repository).
If I check out previous copies of the code on computer'A' (that used to previously behave OK) they also now exhibit the same problems as the latest version of the code.
I don't have a clue what's going on, please help!
I'm seeing multiple references to the Property cannot be set message being resolved in the version of the Rich Text Control that is distributed in Visual Studio 6.0 Service Pack 4, and another Property cannot be set message fixed in SP5.
First and foremost, make sure that a minimum of SP5 is installed; I'd just go with SP6.
For reference, my Microsoft Rich Textbox Control 6.0 (SP6) is at C:\Windows\System32\RICHTX32.OCX, and is version 6.1.97.82.
I know you said that both machines have the same copy of the control installed; for the sake of completeness, you may want to double-check that the new control was registered after installation.
EDIT:
I exported the HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402} reg key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}]
#="Microsoft Rich Textbox Control 6.0 (SP6)"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Control]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A52-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A53-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A57-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED4-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\InprocServer32]
#="C:\\Windows\\system32\\RICHTX32.OCX"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus]
#="0"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus\1]
#="131473"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ProgID]
#="RICHTEXT.RichtextCtrl.1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ToolboxBitmap32]
#="C:\\Windows\\system32\\RICHTX32.OCX, 1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\TypeLib]
#="{3B7C8863-D78F-101B-B9B5-04021C009402}"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Version]
#="1.2"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\VersionIndependentProgID]
#="RICHTEXT.RichtextCtrl"
A bad richtx32.oca file in the system32 directory seems to have been the cause of this.
Here's what an .oca file does:
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.
So it seems that having a bad .oca file in existence can mean that the properties of the control both in the IDE and in the compiled .exe will be affected.
The solution is to delete the .oca file in the system32 folder and then load the project again.

Windows 7: Property Handler works in Explorer but Not FileOpenDialog?

Working on writing a custom property Handler for our custom file type in windows 7. I have installed the Windows 7 SDK and built the sample Property Handler. After registering the handler, it works great in Windows Explorer, but in the common file open dialog the custom values do not appear. Does anyone know if there is something special I need to do to get the properties to appear in common dialogs?
Explorer:
File Open Dialog:
OK, figured it out. Here is the deal. My app is 32 bit and I am on a x64 system. Because the PropertyHandler is written in x64 to support the shell out of process. But for the file open dialog it needs to run inprocess, so the x64 dll can not run. I confirmed this by creating a quick x64 app and the fileopen dialog works the same as the OS. Hope this helps someone else in my shoes later on, hate answering my own question, but don't want people wasting NRG on this one as I found the solution.

MSRDP.OCX is not registered as component in vb6

Can Anyone guide me how can add MSRDP.OCX in my VB6 Project. I tried to add MSRDP.OCX as ActiveX Component. MSRDP.OCX is not registerable as an ActiveX Control. How ever I registered it using regsvr32 command.
If the file is already registered, just look through the components list to find it. If it's not, or to help you find it, run Visual Basic as an admin (of on Vista/Windows 7) and use the browse on the components dialog.

Resources