>Dear Universal Thread User's
>
>We had develop an application in Visual Foxpro 5.0 which displays an TIF image file using Wang Imaging Software (ActiveX
>control) in Windows 95 and works fine till date.
>
>We recompiled it in Visual Foxpro 6.0 (with Service
>pack 2) and we started getting following error when
>executed on all other machine
>other then machine where the application was developed.
>
Something updated the control, or updated the ProgID in the registry, and stored by VFP as a part of your form, used to reference the control on your machine. You might try recreating your distribution with the current version of the OCX on your development machine, and have the OCX reregistered on target systems.
From your description, something changed about the control itself or how it's being identified on target systems, so it's an issue with the ActiveX control, not VFP. You could confirm this by restoring an old version of the OCX to your development system, re-registering it, and then rebuilding and recompiling your application again. This may be a greater incovenience than just updating the control and form on your target systems through your application distribution and installation tools,. since putting an old control back in place may break something on your development box.
> OLE errorcode 0x80040154: Class not registered.
> Class containing OLE object is being ignored. Record Number 3
>
>
>
>We took following step to resolve the same, but could
>not do so :
>
>1. We went back to Visual Foxpro 5.0 and recompiled the
> same project, but the same error was displayed.
>
>2. We went back and unziped the older version of code
> (VFP 5.0 code) and recompiled the same.
>
> Now it worked on some (4) machines but on 3 other
> machine the same error was being displayed.
>
> We reinstalled the ActiveX application assumming
> the file must have got corrupted, but no use.
>
In all probability, reinstallation on the affected target systems won't help unless you install the same version that's currently on the development system. It could also be that some other supporting component related to the OCX that got updated when you installed VFP6. You should probably examine the version information for the OCX on the development machine and compare it to the version on affected targets. Examining the entry under HKEY_CLASSES_ROOT for the ActiveX control might help as well.
Windows tries to keep the most current version of common components, including ActiveX controls, so just reinstalling the control on the development system won't help if something updated the control; a well-behaved installer will either skip over updates to files whose versions are more recent than the one in the install, or will give you a dialog that would let you replace a newer version with an older one - dangerous to do unless you understand the exact consequences to other affected applications.
You might try uninstalling the OCX on your development system before attempting to reinstall the old version; if it is an issue related to versioning, this gives you the best chance of updating things cleanly.
> Also note that we have not copied any code or
> object (cut & paste) from VFP 6.0 project.
>
>3. We tried to delete and reinsert the olecontainer in
> our form and recompiled in VFP 5.0, but did not work.
>
>4. We created a fresh small application for a test
> purpose in VFP 5.0 with just an textbox for
> file name input and an olecontainer to hold and
> display the image.
>
> This application was working fine on all the machine.
>
>5. We also wanted to see if this works with VFP 6.0.
> We created a fresh application in VFP 6.0 and
> it run on all the machines.
>
>From this we draw a conculsion that, there must be some
>code corruption in corresponding .SCX file, though the
>form opens perfectly when opened in VFP 5.0 & 6.0.
>We also tried to add some more objects so that it may
>modify and resave the form, but still the problem
>persist.
>
>Can any one help us to solve the same:
>
>1. Where & what must have gone wrong.
>2. Is it possible to rectify .SCX files since it
> has binary information but .SCT still shows some
> ASCII info.
>
>With regards,
>(Upendra Nayak)
>Email : Bilav@vsnl.com / udnayak@hotmail.com
>Country : INDIA
