>>>>>>How do you programmatically instanciate the common dialog control?
>>>>>>CREATOBJECT("CommonDialog") doesn't work. Thanks
>>>>>
>>>>>John,
>>>>>
>>>>>Let me save you a ton of trouble. Don't try to do this! The reason is that it won't work at run-time. You'll get an error. It's best to drop the control on a form, and either use the property sheet or programmatically set the properties.
>>>>>
>>>>>For details on the error, see MS KB article Q192693 "BUG: License Error with ActiveX Control Added at Run-Time".
>>>>
>>>>Gee, I knew there must be some reason I had never done this programmatically. < g >
>>>
>>>I wish I could say the same.:-( Unfortunately, from a design standpoint, I think it's exactly what you should do. Maybe this bug is fixed in VFP 7.0. Unfortunately, it's a bit hard for me to try. All of my boxes have VFP installed, so it's tough to test. Maybe Mike can tell us if this has changed.
>>
>>Since I can't run an .EXE runtime only version with Beta 1, I can't tell either.
>
>>But I just tried it in VFP6 and it worked just fine as an .EXE. Is that because I've already got a full VFP6 installed?
>
>Yep, that's it exactly. You've got the design time license, and with that, it works fine. I've mentioned this before, but sometime (last year or before) there was an article in the MSDN news about extracting design time licenses. I want to say that it dealt with the MSCOMM32 control (which suffers from the same behavior). It was directed towards C++ users (which should tell you that it ain't easy to do< g >).
>
>I'm sure you've encountered or heard of situations where the response to a user that's having problems with an app is, "...but it works fine on my machine!" This is a case, where this would absolutely apply.:-)

Thanks George. I've certainly run into the "my machine" syndrome before, but it's never had (much) to do with the licensing. < g > DLL Hell springs instantly to the forefront there. :(