>>>>1) trying to start next form via not included Prg instead of directly from subfolder\addon.vcx aggregated on Exe form (easy to check, but only 9% estimate of succeding)
>>>>2) trying to start next form via included Prg instead of directly from subfolder\addon.vcx aggregated on Exe form (easy to check, but only 15% estimate of succeding)
>>>>3) In exe, instantiate a class ONLY in subfolder\addon.vcx as property on screen, start second form from method of that class (harder to check, only 7% estimate of succeding but I'd do before 4)
>>>>4) stimulate brain by repeated forehead/keyboard connections
>>>
>>>Now the funny part, before (4) kicks in... I've removed the suspect object from the form class and am adding it via addobject(), wrapped up in try-catch, and bingo - the form shows up, without that object.
>>
>>Hmmm, would it have been better if form shows up WITH object?
>> ;-)
>>At least next step is clear: pipe all Parentclasses of that class from walking the vcx into text file, do createobjects until one works...
>>Vct mishaps happen, perhaps even vcx...
>
>It all works when the source folder is there, which will not be the case on clients' side, so I even wrote a batch file to rename it, run the exe, rename back. So here's what works:
>- the container from my.vcx hosted on a form
>- instantiating a form from a class in my.vcx, which contains several objects from other classlibs in the exe
>where it breaks:
>- addobject, newobject, createobject from a classlib inside the exe
>
>For a while I thought it was the path, because the classlib was in a subfolder, so the path to parent classes it was ..\src\libs, while at runtime it was .\src\libs, so I moved my.vcx into the same folder where exe is. No change.
>
>Next attempt: have everything in vcx, no addobject.

Hmmm: 2 points to stick out from gut and memory:
we had app, not vcx to run from
project was OOP bordering on POOP: pretty certain a (often empty) subclass always was created at lower level before aggregating at that "project" level