Don't be sorry. That might be a good solution. It's not trivial to distribute the control to the hundreds of users who already have the app installed (using an installer we've been providing over the past 5 years). A lot of users don't have admin access to the machines they use (but some do). So it would require IT intervention. I would rather just do the following:
1. Test for the OCX's registration, and if registered, use it.
2. If not registered, try to register it on the fly (assuming user has admin access) using an auto-download/update feature in the app framework. Use DLLRegisterServer() for this.
3. If neither 1 nor 2 are successful, just fall back to GetFile() for non-admin users.

It's a logistical hassle for our users to run a new installer (some with admin access to their own machines, many using machines to which they do not have admin access, depending on where the machines are located and who owns them).

So I need a more dynamic workaround for our current users.


>I'm sorry for jumping in, but I would recommend do add this class to a container, save it as a new class and try to add it to the form in run-time using newobject method.
>
>But all of these are mute, since you just simply need to distribute the control.
>
>>I've about decided that this whole OCX thing is a bunch of crap.
>>
>>On a test machine (no development environment), I have found that even if the OCX is installed, it seems that you cannot easily test for it. As you inferred earlier, this construct:

>>CREATEOBJECT("MSComDlg.CommonDialog.1")

>>always fails on an "unlicensed" machine.
>>
>>The alternative: If you just go ahead and use the control on a form but the control is not registered on the machine, you've got to capture the OLE error at a weird time (when the form is instantiating).
>>
>>Can you tell me, if you put the control on a form, how do you create a try/catch construct to "catch" the failure of the control to instantiate on the form? Basically, I need to catch the OCX failure when it's not registered on the machine so that I can fall back to GetFile().
>>
>>What do you recommend? Thanks gain.
>>