View Full Version : ComponentOne's TrueDBGrid and InstallShield

Brad Barker
07-27-2004, 09:35 PM
Does anyone know what steps are necessary to have Installshield successfully build an install program that incorporates ComponentOne's TrueDBGrid and TrueDBList in a Visual Basic program?

I just upgraded from ComponentOne's TrueDBGrid Pro 7 to Installshield TrueDBGrid Pro 8. To test it, I built a test program called vbTest using Visual Studio 6's VB Application Wizard and a small access database. The only programming change I made was to replace the Microsoft grid control with ComponentOne's True DBGrid Pro 8 (OLEDB) and renamed the grid.

I then let Installshield build an installation program using InstallShield's wizardand & installed it on the development machine. At the end of the install, I received an "Component todg8.ocx or one of its dependencies not correctly registered: a file is missing or invalid" error. At the advice of InstallShield, I made tdbgpp8.dll, todg8.ocx & todgub8.dll self-registering. Rebuilt in InstallShield & reinstalled. While the installshield program was removing backup files, I got an "Error 1904 Module c:\..\tdbgpp8.dll failed to register..." message. I changed tdbgpp8.dll & todgub8.dll to "Extract COM info". Rebuilt and tried again - same error.

In DOS, went to sys32 folder, typed "Regsvr32 tdbgpp8.dll", got "tdbgpp8.dll was loaded, but the DllRegisterServer entry point was not found. This file can not be registered." When I open the project in Visual Basic, it tells me that TrueDBGrid is no longer available.

I reinstalled ComponentOne. When I try to reopen vbTest, I get "Class not registered. Looking for object with CLSID:{" and a long number. Rebooted, uninstalled C1, rebooted, reinstalled C1, rebooted. When I pulled up vbTest, the data form had disappeared.

Rebuilt vbTest from scratch. When I went to insert the grid, ComponentOne's True DBGrid Pro 8 (OLEDB) was no longer in the Components field. I then added todg8.ocx by browsing. The program now works in Visual Basic again, but I am leery of using InstallShield with it for obvious reasons.

Microsoft's Package and Deploy wizard creates an installation program that works with no problems.

I had a similar problem when I first bought TDBGrid 7 over two years ago, but I hadn't had the problem again until recently. I bought the latest versions of both ComponentOne and Installshield hoping the problem was resolved.

We purchased support from InstallShield and ComponentOne - both have been remarkably nonresponsive on this issue, though I've had excellent help from them in the past. I can see where other people in other forums have also had problems.

If no one knows how to do this, can anyone recommend any alternatives to either product?

Mike Marino
07-27-2004, 10:02 PM
Try setting:


to use the Self Register option instead of COM EXTRACT. COM EXTRACT is the preferred method with MSI based setups, however it can sometimes miss an entry.

Next, I would run the Static scanner to see if tdbgpp8.dll &
todgub8.dll have any dependencies that may also be required for the installation.

If you still have problems, let me know.

Brad Barker
07-28-2004, 08:58 AM
In terms of making the dll's self-registering, please re-read the post. That's exactly what I did. I did repeat the experiment again using Static Scanning with the same results (see below).

I tried duplicating the above experiment using VSFlexGrid Pro. I had no problems with either P&D or InstallShield.
Unfortunately, VSFlexGrid Pro is not a viable solution for the product.

Here's the method and results:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Rebuilt vbTest using procedure described earlier. Again, I had to add todg8.ocx by browsing, but once done so, I was able to build and test an executable. I then successfully built & tested an installation package using P&D.

I then let Installshield build an installation program using InstallShield's wizard and & installed it on the development machine. The only change in procedure was to include static scanning (no new dependencies were found). Again, I made sure that tdbgpp8.dll & todgub8.dll were self-registering.

Built and installed on development PC. At the end of the install (the screen said "Removing Backup Files"), I got an "Error 1904 Module c:\..\tdbgpp8.dll failed to register..." message.

When I ran the program after installation, I got the message "Component todg8.ocx or one of its dependencies not correctly registered: a file is missing or invalid" error.

I uninstalled the program. When I try to reopen vbTest in Visual Basic, I get "Class not registered. Looking for object with CLSID:{" and a long number. That's where I am currently.

What's the next step?

Mike Marino
07-28-2004, 11:49 AM
Any way you can send me those DLLs so I can try a test with them on my side? I assume I can simply include them in a simple VB project as you describe to reproduce the problem, correct?

email: michaelm@installshield.com

Brad Barker
07-28-2004, 12:40 PM
ComponentOne actually allows you to download a trial version of True DBGrid Pro 8. You get a splash screen, but other than that, they should be identical.

Mike Marino
07-29-2004, 02:32 PM
I was able to reproduced the problem, and I was able to figure out what the problem is. The file tdbg8.ocx needs to be set for "Self-Registration".

I was able to install a VB project that used the grid, installing 3 files:

My Application.exe
tdbgpp8.dll (Registration Type set to None)
tdbg8.ocx (Registration Type set to Self-Registration).

Hope the helps.

Brad Barker
08-03-2004, 08:36 PM
This fixed the problem.

>>> "Michael Marino [InstallShield mySupport SR ID 1599814]" <159-9814-yea@installshield.epeople.com> 7/29/2004 2:24:21 PM >>>
From: Michael Marino
Sent: 07/29/04 @ 12:20 PM PDT

Yes, I reproduced the problem, and I was able to figure out what the problem is. The file tdbg8.ocx needs to be set for "Self-register". I was able to install a VB projetc that used the grid installing 3 files -- My Application.exe, tdbgpp8.dll (No Extraction, and No Self Registration) , and tdbg8.ocx (marked for Self Registration). I looked at the project you sent me and tdbg8.ocx was set for Com Extraction.

08-11-2004, 09:59 AM
We tried the suggested solution with TrueDBGrid 7 in InstallShield X Professional SP1 and it still didn't work :(

Finally we solved our problem as follows:
- run the original ComponentOne setup on a clean machine while having a registry monitor active
- export all keys/values that the proper setup added to a text file
- replace all occurrances of the string "c:\\windows\\system32\\" by "[SystemFolder]"
- neither do com extract nor self registration on the true dbgrid components, but instead include our registry file in the build

This fixed it, but it cost us almost 2 mandays to work around the bug in our brand new InstallShield version (stupid old InstallShield Express released in previous century worked fine!!). Tomorrow we'll make a merge module so that we not have to redo everything on the next setup that includes TrueDbGrid.

Brad Barker
08-11-2004, 10:44 AM
If you can, please post the merge module so others won't have to go through the same experience. Thanks.

Mike Marino
08-11-2004, 12:23 PM
Self Registration should work fine. The problem with COM Extraction is that keys can be missed, or interpreted incorrectly. Our COM Extraction basicially monitors the registry similarly to the method of using a registry monitor.

I would be curious to know what key we are actually missing during this process. If you could upload that text file it might be helpful.

Either way, when I ran tests with the TrueDBGrid 8, marking the file as "Self Registering" did make an application using the grid install correctly on a clean Windows 95 computer.

08-11-2004, 12:27 PM
We used Windows XP Pro SP1 and tdbg7 (OLE version). We only did the registry thing, because it never worked, no matter what combination of self registration/com extract we tried.

Very simple test was to make a VB6 application with a single form hosting an empty grid, that would not load on the clean test machine after our installshield setup was applied.

Mike Marino
08-11-2004, 12:30 PM
Can you send me that DLL. I would like to look into this. I only tried 8.

08-11-2004, 12:39 PM
I am not in the office tomorrow (and it is already long after office hours now in Holland), but I have asked my collegue who worked with me on the setup to prepare two versions of the truedbgrid test program setup:

1. using registry export (the hard way), that worked in our test environment
2. using self-registration. I have sent him an e-mail stating that this should work according to you, but i am sure we saw it failing.

I hope we can get to the root of this, we really would prefer a simpler solution than the one I describe above. The test program will include the relevant TrueDbgrid 7 components and -if they correctly register- you should be able to use it as a trial version in VB6 after running our setup.

Best regards,


08-12-2004, 01:58 AM
My collegue made and compiled two setup projects:
A. SetupManuallyRegister, using our registry export for the TrueDBGrid 7 OLE core module todg7.ocx
B. SetupSelfRegister, using the self register feature of IS X for the TrueDBGrid 7 components

The projects including msi output can be downloaded here:

After installing on a clean machine, please execute test.exe to test a bound TrueDBGrid 7 OLE grid. Our results on Windows XP Professional ENU with SP1:
A. test.exe works, shows an empty grid
B. test.exe fails to load with an error message

I found that the TrueDbGrid 7 evaluation version can still be downloaded from ComponentOne, here (http://download.componentone.com/pub/ActiveX/tdbgrid7/Evaluations/TDBGrid7.0.0285_Eval.exe)

Christopher Painter
08-12-2004, 08:52 AM
Good thread about registration and self-reg vs com tables. Its good to see IShield tring to make the sniffing process better.

A year ago I would have been all over Self Registration as an acceptable workaround, but now I've been taken over to the dark side. I would use a program like Advanced Registry Tracer on a clean machine to snapshot the changes made to a DLL during the self registration process and then manually put those into the COM tables for your component. This way you get all of the COM data, and you can leverage MSI's resilency.

Mike Marino
08-12-2004, 01:42 PM
The problem is that even the best registry tracer may fail. Consider the following:

In a DLL's DllRegisterServer funtion, the DLL does writes different registry keys based on the Operating system.

Now, really does anyone actually do this? I would hope not. However since DLLRegisterServer is simply an entry point Anything can technically be done. So capturing this would be very difficult, unless you monitored the DLL on multpile OS's.

And if companies are handling licensing info in these methods? It can get even tougher.

08-12-2004, 01:49 PM
Hello Mike,

I hope you are not losing focus here... Chris is right from a theoretical viewpoint, but we still would like to see a method, any method, that allows us to properly install TrueDbGrid 7 without doing the complicated work ourselves.

It really surprised us that selfregistering also didn't work, that always worked fine in simple products like InstallShield Express 2.0 and Microsoft PDW. For us it would be good enough if that was fixed. I believe we provided ample testing material to trace down the problem, but please let me know if you need anything more.



Mike Marino
08-12-2004, 02:05 PM
I am just waiting on the DLL.

Christopher Painter
08-12-2004, 02:28 PM
Originally posted by Mike Marino
Consider the following

In a DLL's DllRegisterServer funtion, the DLL does writes different registry keys based on the Operating system.

I used to used InCtrl3 later InstallShield Application Repackager, Advanced Registry Tracer, AdminStudio so on so on ...

I agree with you, and I'll remind everyone that any method you use to snapshot an existing install ( in this case an existing COM server ) can only capture 1 of many possible business scenarios contained in the original install. When reverse engineering an install you must attempt to capture every possible use of the original install and recreate that.

08-12-2004, 02:41 PM
Originally posted by Mike Marino
I am just waiting on the DLL.
I gave an url where you can download the DLL in my post of this morning (ComponentOne evaluation software link, same version that we use, download it here (http://download.componentone.com/pub/ActiveX/tdbgrid7/Evaluations/TDBGrid7.0.0285_Eval.exe)). Also, we have provided 2 sample setup projects that will both install the DLL in question, you can download those here (http://support.decos.nl/SetupSelfRegisterTest.zip). Please re-read my post of this morning, everything already was there before you started your working day.


Brad Barker
08-12-2004, 03:05 PM
Hi, I'm the one who started this post. Just wanted to let you know that Mike Marino is one of the good guys - he was the only one to solve the problem for me in the first place. Please be patient with him.

Christopher Painter
08-12-2004, 03:06 PM
For sure, I'm very impressed to see him asking for a DLL to test the COM extraction with.

Mike Marino
08-12-2004, 03:47 PM
OK, sorry I missed the post with your setup...not sure how, but I did. However I opened the project under "SetupSelfRegister" and was a little confused.

None of the files in this project are marked as Self Registering.

(To set a file to self regsiter, go to the Applications files view, right click on the File and check Self-Register. You can do this from a number of other places in the IDE as well.)

Is this the actual project you tested with?

08-12-2004, 03:49 PM
I'll check with my collegue in the morning, he prepared it (sorry, not much I can do from home at 10:40 pm). It would be so nice to have a simple explanation, even if it means that we were stupid :)

08-13-2004, 01:42 AM
You were right and we owe you an apology. Although my collegue was quite sure he also tried with self registration, the project was in fact using com extract. When we retested with self registration, it worked fine. As far as I am concerned there is no issue. Your explanation of the limitations of com extract are acceptable to me.

Joe Chung
04-29-2005, 01:58 PM
I tried the "Self-registering" property fix, but it didn't fix the problem here. My users get the same "tdbg8.ocx not properly registered or file(s) are missing" error even though I included tdbg8.ocx, tdbgpp8.dll, and xadb8.ocx with the distribution.

Manually registering the OCXs with REGSVR32 after the installation also doesn't correct the problem -- not that I expected it would since setting it to self-registering should essentially be doing the same thing.

Mike Marino
04-29-2005, 03:52 PM
Where are you installing tdbg8.ocx, tdbgpp8.dll, and xadb8.ocx to. Im my experience with these, they needed to go to the Windows\System folder. Registering them anywhere else would cause them not ot work.

Joe Chung
05-04-2005, 01:27 PM
I am putting them in [SystemFolder], usually WINDOWS\SYSTEM32 (sometimes WINNT\SYSTEM32). Do they have to go in the WINDOWS\SYSTEM folder?

I did a little research on this problem at the ComponentONE Web forums. It turns out that they use a custom REGSVR32.EXE (C1REGSVR.EXE) to register tdbg8.ocx and xadb8.ocx. I wound up adding Custom actions to my Express X project to run C1REGSVR.EXE on these files after they were copied onto the destination machines by Express.

Mike Marino
05-04-2005, 04:00 PM
WINDOWS\SYSTEM32 is where they should go. Did the custom registration custom action fix the problem? If so could you post the custom action properties you used. I could get a KB created for this then.


Bernd Sandner
07-21-2005, 07:36 AM
There's a Merge Module TDBGrid8.msm which works fine:

03-02-2006, 03:57 PM
ComponentOne made a program to register their stuff for you.

I added the following lines to my MSI/IS Script project to get it to work.

InstallSoftware("DBGrid Registration", SystemFolder ^ "C1REGSVR.EXE", SystemFolder ^ "TODG7.OCX");
InstallSoftware("DBGrid Registration", SystemFolder ^ "C1REGSVR.EXE", SystemFolder ^ "TODGUB7.DLL");
InstallSoftware("DBGrid Registration", SystemFolder ^ "C1REGSVR.EXE", SystemFolder ^ "XADB7.OCX");


Here is my InstallSoftware Function..

function InstallSoftware(sProgName, sProgram, sParameters)
NUMBER nResult;
LongPathToQuote(sProgram, FALSE);

SdShowMsg(sProgName + " Please Wait...", TRUE);
SprintfMsiLog("*DEK* Calling %s %s", sProgram, sParameters );

if Is(FILE_EXISTS, sProgram) then
nResult = LaunchAppAndWait(sProgram, sParameters, LAAW_OPTION_WAIT);
SprintfMsiLog("*DEK* LOG | %s | %s | %s ", sProgName, sProgram, sParameters);
SprintfMsiLog("*DEK* Unable to find %s\n%s", sProgram, sParameters );
SdShowMsg("The installation file was not found. Please make sure the Updates folder exists. Skipping Installation of " + sProgName, TRUE);

SdShowMsg("", FALSE);

Make sure you bundle C1RegSvr.exe with your app. check the net for the source of this file. Make sure you copy the DLL's w/o COM extraction, etc...

08-05-2008, 03:06 AM
I am new to IS and using IS2008. I just wanna know when to use Self Registration.and when can we use a COM Extraction in BASIC MSI project.

I also wanna know if there is any Self Registration of Com Components in BASIC MSI Proj.