Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Class not registered ??????
Message
De
07/01/2005 09:19:56
Guy Pardoe
Pardoe Development Corporation
Peterborough, New Hampshire, États-Unis
 
 
À
06/01/2005 12:44:52
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Divers
Thread ID:
00974718
Message ID:
00975065
Vues:
23
Here is a copy of some information snipped from

http://www.vfug.org/Newsletters/Newsletters2.Afp?!_15O045OL4Date=01/01/2004

It discusses some problems related ActiveX controls. If you're using one of the controls in MSCOMCTL.OCX, this might help.

Guy

******************************

Errors with "Built In" Microsoft ActiveX Controls

Robert McNeal

Recently, I had a problem on some client computers where the MS ProgressBar control caused an error. The error message was "Class not registered for use." I included the mscomctl.ocx in my installation package and registered it properly, but the error persisted.

After several hours on the phone with MS Tech Support, the end result was that Visual FoxPro handles instantiation of ActiveX controls created through the CreateObject() Function differently than when the controls themselves are placed directly on the screen at design time. The error was the result of VFP attempting to create the "Developer’s Version" of the control rather than the run-time version.

This problem would disappear when the control was placed directly on the screen in the form designer at design time. While this is one approach to solving the problem, I prefer not to add ActiveX controls this way since, in my experience, the can become very "buggy" when any other version of the control is registered on the user’s computer. Instead, I prefer to use the version independent prog id (such as MsComCtlLib.ProgCtrl) to instantiate the control through CreateObject().

Since VFP tries to instantiate the "Developer’s Version" of the control and the license key(s) in the registry are not present, the control throws an exception. The only fix for this situation was to add the license key for the control to the user’s registry. License keys for most of the Microsoft ActiveX Controls are stored in HKEY_CLASSES_ROOT\Licenses. Microsoft tech support could not tell me which key was the one for the progress bar control, so we added all of the keys to the offending machine and deleted them one by one until the problem returned. I have 47 listed on my computer, but I have VFP 6, 7, and 8 installed, as well as VS 6 and .NET 2003. The ProgressBar control uses the registry key below, which you should be able to find on your development computer and export to a .reg file or include in an installation package.

[HKEY_CLASSES_ROOT\Licenses\ED4B87C4-9F76-11d1-8BF7-0000F8754DA1]

@="knlggnmntgggrninthpgmnngrhqhnnjnslsh"

This key appears to work for all of the controls in the mscomctl.ocx library, which include the ImageCombo, ImageList, ListView, ProgressBar, Slider, StatusBar, Toolbar and TreeView controls.

I finally built my own ProgressBar control in VFP using several shape controls in a container. The code should be available on the VFUG website in the file RMProgBar.zip, if anyone is interested.

Robert McNeal

**********************************







>I thought that the error message implied that also. The form does contain an ActiveX control. But I do install it when the app is installed (by Inno Setup). The control installs and registers propely on all other customer machines. Do you know of some reason why Win2K would not allow a control to register at intall time?
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform