>>I'm losing hair for three days now over this problem. Here's the layout of it:
>
>I remember typing with my forehead long time ago on a similar problem:
>customer of large parent exe has 2 apps compiled into 2 different apps oWW.app and oHH.app.
>Both apps utilize common classes found in multirisk.vcx as ParentClasses.
>In first releases multirisk.vcx was included in oWW.pjx and oHH.pjx, resulting in duplicate code being installed at all sides where both apps were installed.
>In optimizing maintainance about 2 years later DRY even on rollout was specced, as the previous way of doing things also utilized duplicte loading time for multirisk.vcx and memory space.
>As some installs had neither oWW.app nor oHH.app compilng multirisk.vcx into exe was not an option. Optimized solution was to exclude multirisk.vcx from oWW.pjx and oHH.vcx and create new oMultirisk.app with multirisk.vcx included.
>
>Loading either oWW.App or oHH.App was done via special method, which
>
>1) put oMultirisk on the program stack
>2) called a tiny function ***inside oMultirisk.app*** adding multirisk.vcx via set libr
>3) called via parameter starting function in oWW.app or oHH.app from Multirisk.app
>
>(confidence of my own memory only 80% of that including ALL necessary steps)
>Remember the times when only single "other" prg could be "referenced" in FPD?
>Utilizing the "search for program name" in already loaded memory meant that you load the "helper functions" onto the program stack and if later called from own code the runtime searched up the stack to find program name - similar principle, with some more twists like "do in xxx.app" with tcparameter
>
>;-)))
>
>Gimme feedback if it works so I can reschedule Alzheimer diagnostic visits to later times ;-)

It'll have to wait until monday, as I'm presently mentally exhausted (and had 4 beers with a friend...). But I was thinking somewhere along those lines. I even created one object (the simplest label I found) from each of the classlibs, assigned them to properties of _screen, hoping to get them on the stack and thus make them available, but no luck, still not found.

Then I remembered one thing - one container from this external lib is already instantiated in the caller form. The only trouble was that it was unable to find its pictures, which I solved by doing _clipboard=strconv(filetostr("pic_name_here.png"), 13) and then included that in text-endtext to stuff into a variable, and then, well, this.pictureval=strconv(lcVar, 14) and that worked. So it seems that it's not the classlibs per se that are the problem, it's various files and referencing them from a standalone scx. So I tried to include the scx back into the project... and it seemed to work a little better (got a different error :). But then it was evening already... so, monday.