Ok, the builder still doesn't work and it restores paths from the MMVisCollect project. I found that it uses Appincl.h and Appincl.dbf

So, does it mean that we can not have two different projects in the same directory sharing the libraries? Or we need to have another AppIncl table for the second project in some other place?

Looks like there is no simple workaround except adding the libraries to the "main" project.

Or the builder can be modified. If we have not empty SET('classlib') let's assume it's the correct one and don't re-build it. But the builder is in the MereMortals directory and we're reluctant to change it.

>Nadya,
>
>After running SetX for our project, SET("Classlib") returns a string 15,418 characters long (and we add to this total almost weekly), so I doubt it's an inherent MM problem.
>
>Which object is the builder trying to instantiate when you get this error?
>
>Also, which version of MM are you using?
>
>I seem to remember that setx takes a parameter of the project name, or you can just set the default directory.
>
>We have a stub program that sets up the debug/working environment (runs startmm, sets our default directory, changes the title bar to something amusing) among other things. Maybe that would help in your case?
>
>Hope that helps,
>---J
>
>>I traced the problem in the builder. It's an error 1733 when it tries to instantiate a class using CREATEOBJECT command. The classlib is supposed to be in the memory, but it is not. I checked SET('classlib'), it's a very very long string:
>>
>>However, a second ago I tried SET CLASSLIB TO
>>=setx()
>>set classlib to aBatchProcessBiz.vcx additive and then createobject, it seems to work. I think, we may hit some limit...
>>
>>The length of the SET('classlib') is 5450. I'm not sure how setx() works, I need to check its code. I want to work with different project right now, but it seems like it is taking libraries from MMVisCollect project rahter than from BatchProcess project.