>>>Josef
>>
>>I have an idea... surprising, huh? I know there was a problem with the 6.0 framework identifying the wrong exe as the one to SET CLASSLIB IN. It had to do with using SYS(16) to determine which was the calling program. Anyway, to make a long story slightly longer, Kevin changed some code (in MMortals\Common30\Progs\Setup.prg... SetProcsAndLibs() is the method) that used to issue a SET CLASSLIB IN. Now it calls SET CLASSLIB without the IN. This may be causing your problem, because it won't recognize where the classes are... unless they're in the same path as the executable/app
>>
>>You may have luck in copying the old Setup.prg into your new MMortals directory (of course, copy the old one to a new name/directory first!) and then recompiling.
>>-Hope that helps!
>>---J
>
>Dear Jason!
>
>Your idea was genious!!!!
>
>I have changed code in Setup.prg SetProcAndLibs() to old code from MM6.0 and reports start to function! This problem was not onla in case when libraries were in different EXEs, but olso in case when application was compiled in one exe.
>
>Thank you very much
>
>Josef

Kevin, I mentioned a related problem with this to you awhile back when we were having trouble with SET CLASSLIB IN picking up our "stub" program instead of the main exe.

We found the best way around this was to loop through calls to SYS(16, lnCount), where lnCount is incremented from 1 until a match is found with a variable set to the main exe name. Currently, I'm storing the name of our main exe in AppIncl.dbf using EXEC_NAME as the key --- not the most elegant of solutions, I know, but despite my youthful ignorance, it worked!

Originally, I wanted to use a goApp property, until I realized we don't yet have a reference to the application object when Setup is run. What would you suggest, short of modifying QuickStart to add another record like the one we came up with in AppIncl when creating a project? Help?
---J