>>The problem will come at runtime on a machine that does not have developer license installed on many ActiveX controls.
>
>In this case it is on the original machine.
>
>> The workaround to this is to subclass the control by dropping on a form. Then you instanciate the form instead of the control.
>
>Do you think there is any problem using this from an FRX? I don't see why there would. I am thinking put the code in a function, and return a reference to the form that can be stored in a report var. For each record I can pass the var to a function that can use the control on the form. When the report is done, the var goes out of scope. This way I won't be creating/destroying for each record. Sound good?

I see no problem with doing that. I embed report fields with function calls as the data source quite often, including passing parameters as well. Works slick especially when you are trying to generate government forms. I use arrays as well because I can use a report variable that is like a counter. Each record increments the counter by one and that becomes the array element whose value I pass back to the report. This helped resolve a many-to-many problem that a cursor just could not fix. That little brainstorm hit me in the wee hours of a restless night.