>>>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.

*******************************
Remember the times when only single "other" prg could be "referenced" in FPD?
*******************************
Yes, and that problem persisted through VFP6 and who knows how further up. It's how VFP creates and holds a list of files.
Yes, parentclasses or whatever in VFP spread across different physical files gets strange.
I recently was told to write the code in VFP9 and avoiding VFP9 features and then compile that and other code that uses the same library in VFP8. Ok, did that and compiled and build APPs and a calling EXE and it would depend on whether the end user went to my new app named 'Foo' that I coded in VFP9 when it loaded the library file. Things got strange if the end user didn't go to the 'Foo' app first and went to a different APP file in the global lists of apps we had and then it loaded a different version of the common library. So, until we moved to VFP9 I had to code some protection code in my main form to detect if the newer library was in memory or not using pemstatus to test for a method or a property that only my APP file had in it.

This nothing like your problem, but I had to compile/build the app file using VFP9 or it would not build. I guess there's some under the hood differences in the APP files between VFP9 and VFP8. We were hoping there wouldn't be.

I know that the above doesn't make a whole lot of sense, but there's definitely weird stuff in VFP memory when it comes to 'common' classlibs coming from different app files.