>>>I've had the same problem ("Property VALUE not found") with MSACAL70.OCX (included in setup) on one machine. I had the user run REGSVR32 'just in case', and that solved the problem.
>>>Should have thought that you'd get an error when the object was instantiated, if the class wasn't registered, so I don't know what exactly caused this...
>>>This has happened only on one machine, running a norwegian Windows 98.
>
>>It's likely that the control was there and registered, but a different version than the one you had him register, that didn't support the property that you were trying to access. With a little luck, the version you have will be a superset of the original one's functionality, and everything will continue to function; unfortunately, I've run into situations where I've placed different versions of a control on two different VFP forms (so far, only in different apps), and I now run into the problem of only being able to have one of them registered at a given time...
>
>You mean that if a control exists from before (in another version), the new version might just be copied to the system directory without actually being registered? Is this a known issue? If so, this would introduce another headache when distributing an application with activeX components...
It's even worse than that. When you bind an ActiveX control to a form, the version that's used to design the form is tightly bound to the form. If you install the form on a system with a later version of the control (something that's bitten me more than once) already present, the Setup Wizard install often won't even copy the version of the control that I distributed with the file, or in some cases, copies it to the system, but doesn't register it, finding a later version already registered.
Run-time binding of a control to a form gets around some of this problem if you assume that later versions of a control will be backwards compatible; adding the control to the form at runtime with ADDOBJECT() will make use whatever control is associated with the ProgID at runtime.
Most of the time that I get hurt, something else changes the control on me - a later application may put its own version of the control on the system and alter the registry entry. Since only one provider can be associated iwth a given ProgID, the latest one to register wins; if you're checking versions during installs, the latest version wins. Sloppy installs often do not do version checking, and things that woirk suddenly get pretty badly broken.
Another possibility is that one or more of the .DLLs required by the .OCX were not present at the time your application attempted to register the control. Subsequent copy operations may have put those necessary files in place after the fact, so that attempting to register the file with REGSVR32 later suceeded where it failed at first. I'm not certain of the behavior of the Setup Wizard regarding the order of copying and regitration; I know I've been bitten in the past with OLE Server installations that I've written in InstallShield, where I mis-sequenced the copy and registration actions.
>The OCX-file in his machine after the installation was the same version and exactly the same size as the one distributed from the development machine. The users PC was brand new with not much more than windows '98, MS Office and Internet Explorer, as far as I know, so I think that there _probably_ wasn't an older version of MSACAL there from before.
Without having checked the registry entry for the control before you registered it, it's tough to say what was there in retrospect.
>This problem, although easy to remedy, makes me a bit worried...
>
>Arne
