I know this is an old thread. I have bumped into the same problem. The runtime distribution involks the "Insert Object" dialog. The article (http://www.kbalertz.com/kb_192693.aspx) suggests that VFP6 under setup wizard behaved the same - but I cannot recall that issue.

THe article also suggests that using NewObject offers a workaround if the project uses PRG OCX class definitions that NewObject can subclass. It works great in the KBs PRG form - but I have not been able to to avoid the "Insert Object" with anything but a VCX via Set Classlib.

It would be neat if anyone has the PRG OCX subclasses firing. I don't understand or appreciate the big deal with design time vs runtime and MS VFP OCX classes. It seems it should make no difference.

One article mentioned SP-2 (maybe). But the requirement to hang a visual control on a form (which can be tedious should it be a child of an object other than a form) or park it in a VCX is something I would be careful not to force on my customers if I had all the brain power MS has on this stuff.

I think it's a bug disquised as a new feature. Whenever the are "notes" in the help screen - I tend to wonder.

The problem is inefficiency. It's easy to comment out OCX methods that are not needed or make little changes right in the PRG (it's an easy direct/random access) as opposed to the sequential (indirect access) tedium of mousing through a VCX.

Could the OCXs be registered with a reg file (one time) as long as the MSMs are packaged with the distribution "setup"?

Has anyone found a PRG workaround that works. Here is the way I tried to accomplish the KB's NewObject PRG work around - any help appreciated.

* In the (main) form that contains my imagelist contrl, the forms init
* method calls a PRG procedure <code>Main_Init(thisform)</code>
* First the class definition
DEFINE CLASS myImageList as OleControl
oleclass = 'MSComctlLib.ImageListCtrl.2'
ENDDEFINE &&IL
* Now the Main forms init
procedure Main_Init(oform)
AddImageList(oform)
endproc
* Now the init's called procedure using the KB's PRG workaround
procedure AddImageList(oform)
oform.newobject('IL','myImageList','BC_Objects.prg')
   * The insert object dialog pops here
with oform.IL
/ ... image list stuff ... /
endwith
endproc

And the article suggests that NewObject is required with a VCX, but that is not the case, AddObject will add an OCX should a VCX be availble at distribution run time.

Any new news or work arounds to add PRG OCXs would be most appreciated!
>That's a good question Sergey. The water is extremely muddy, but it appears that the license that MSMAPI is looking for when it says that it doesn't have an appropriate license is a design time license, not a runtime license. So, in order to get around it, the registry hack takes a design-time license and moves it to a user's computer. Here's a kb article that has an interesting little line in it... http://www.kbalertz.com/kb_192693.aspx
>
>"A distribution created with the Visual FoxPro Setup Wizard or InstallShield Express only allows a run-time license, while the AddObject method requires a design time license."
>
>In any event, I believe the accepted way to get around this problem is to add the ActiveX control to a form or create a subclass of the olecontrol in a vcx at design-time, that way only the run-time licensing is needed when the application is installed at a user's location and the activex will stop complaining that it doesn't have the appropriate license on the user's machine. Whether this violates the EULA for the MSMAPI controls and/or the EULA for VFP is a matter that could be debated. But I think it is clear that hacking the registry is using a design-time license not a runtime license, and as such, I stay away from it.