Are folks using the VB6 "Common Controls Replacement Project" controls? Any caveats or showstoppers?

views:

answers:

+1 Q:

Are folks using the VB6 "Common Controls Replacement Project" controls? Any caveats or showstoppers?

I'm considering using the VB6 Common Controls Replacement Project controls and would like to see what other's experiences with them are.

Specifically:

What do you need to distribute with them? (I assume just the .OCX file)
Do I need to register the .ocx file or just include in the app directory?
Do these controls depend on any other ocx's? (There is mention, for example in the Progress Bar replacement that it is using COMCTL32.DLL but the .DEP file does not list that DLL.
Are they at least as robust as the controls they replace?

1-3) The DLLs are presumed to be on every system -- you distribute (and register) the OCX only.

4) What controls do they replace?

Jim Mack 2010-05-13 17:34:28

+2 A:

I've used various of the CCRP components in various projects (specifically BrowseDialog, FileDialogs, FolderTreeview and High-Performance Timer) and have had no problems with them. To answer your questions:

1) Just the OCX or dll is required to distribute them. 2) Yes they need to be registered. 3) The controls they depend on will be on every system (comctl32.dll is all of the common windows controls and no GDI app without it). 4) The ones I have used I have never had an incident with. I haven't used all of them, so I can't speak for all of them, but they were always very robust for me.

Kris Erickson 2010-05-14 15:21:38

So, I'm assuming that an OCX is a interface wrapper around a .dll, correct? And that these CCRP components provide their own OCX instead of, say comctrl32.ocx).FYI, if you put <appname>.exe.LOCAL in the app directory (instructing Windows to look in the app directory) I haven't needed to register other OCXs (and presumably not the CCRP components)

Clay Nichols 2010-05-14 16:34:23

Unless you are using regfree com (http://msdn.microsoft.com/en-us/magazine/cc188708.aspx) you are going to have register the ocx. Dll's like comctl32.dll do not have to be registered since it is a not an acitvex dll, comctl32.ocx does not have to be registered since it is already registered. OCX may be an interface wrapper around a DLL, but basically is a control that VB6 knows how to show in its toolbox, rather than a DLL which has no visual representation.

Kris Erickson 2010-05-15 00:10:30

One sad and hazardous feature is that if you place an OCX file next to the EXE that uses it, the runtime will register it in place silently. This can break other applications using the same OCX installed later. Their installer sees the component registered already and uses it. Then the user deletes this first (rogue) application's folder and the OCX is gone though still registered. Nasty.

Bob Riemersma 2010-05-15 21:44:15

Wasn't aware of that feature of OCX's (auto registration). Good to know, and know to avoid it.

Kris Erickson 2010-05-16 05:43:19

Good answer but I think Clay should be aware that the controls are no longer being developed (since 2004 I believe). If Caly did find a problem on, say, Windows 7, he might have to fix it himself. He could appeal to the authors by email but that would be chancy. Unlike the Microsoft controls which are still supported by Microsoft.

MarkJ 2010-05-17 12:58:28

ansaurus

tags:

views:

answers:

Are folks using the VB6 "Common Controls Replacement Project" controls? Any caveats or showstoppers?

related questions