>>>So the current solution with the two initial pieces staying welded inside the exe (caller grid, the form) and everything else (classlib, prgs with bizobjects, couple of small readonly dbfs) in the subfolder is the usable solution.
>
>Our interfaces have prg classes inside the exe with localization in a prg outside the exe. The localizer prg contains a subclass definition and a single line to create an instance of that class.
>
>Simplifying and removing status/error trapping etc, the subclassed/localized object is created by
>
>

loLocalizer="" && variable left in scope for...
>
>do outsidelocalizer.fxp
>
>if vartype(loLocalizer) !="O"
>	loLocalizer=create("localizerbase")
>endif
>...
>...
>Define class localizerbase as custom
>...
>...

>
>and in outsidelocalizer.prg:
>

loLocalizer=CREATEOBJECT("customLocalizer")
>RETURN
>
>DEFINE CLASS customLocalizer as localizerbase
>...
>...

>
>That definitely works. So it might be worth moving the key class into a prg via classbrowser or whatever, then distribute your add-on fxp.

I knew there were no such problems with prg-based classes, been doing that for a while. However, there's about 20 inner containers with average of 50-80 fields (with about 30% of them being represented by combos which have some setup code)... and those are not built by me. So conversion into prg would have to be done for each update... For a brief moment I considered that option, decided that giving this another week will be easier. Turned out I was right.