Rick Schummer wrote: > Michael, > > >>> By creating several APPs instead of one big, all encompassing EXE, do you >>> manage memory better via >>> > your application's performance since in theory, when an APP was done, it'd be > released from memory? > (Assuming that's how it works?!?)<< > > One of the problems with APPs called from a single EXE is the management of > things like SET PATH, > SET CLASSLIB, SET PROCEDURE, SET LIBRARY, etc. In particular, SET CLASSLIB > and VFP's class caching > is a pain in the neck when you use this model. Specific to an example: you > may have your main > program use a base label object from your base class class library to display > something on the > desktop. Your APP module also has the same class library compiled in it to > display labels within the > APP module functionality. Your APP will use the one cached in memory by the > EXE. > ... > I'll be interested in hearing if others have solved this and are using this > architecture. > > Rick > White Light Computing, Inc. It's funny, I just did this (splitting into multiple Apps) for a huge VFE app.
I had some trouble with the metadata splitting and such, it did take some time to work out. Here's a high level breakdown... Main module -- had all the base classes, intermediate level classes, graphics, menus and so on. If a class was called from two different modules, that class library needed to be included as well. That took some time to figure out. Subsidiary modules -- Project had all base classes and intermediate level classes in order to compile, but were excluded from the project. I found that if a class used a graphic on a command button, I needed to include that graphic in the subsidiary app even though it existed in the main application. Now VFE specific stuff.... Metadata was a pain. Each module (including the main one) had it's own Metadata table (the VFEMeta and SDTMeta tables were shared by all and didn't change). Basically, each module needed to have it's own MetaData table built at design time based on the project's VCXes and PRGs in the project that weren't excluded. It's easier to do than it is to explain -- it's a simple SELECT...INTO Table (Metadata table) statement. OK, so now we have subsidiary modules and a main EXE. What then? I did have to build another table like this: iID (I), cClassName (C 150), cModule (C 150), cApp (C 30), lUseSubApp (L)). This table was included into the main executable. When you select a menu bar that's tied to a form to run in VFE, a call is made to the application object's DoForm method. It could look like this: RETURN THIS.oApplication.DoForm([FormClassToBeCalled]) Okay, so far, so good. What does this extra table do? Well, when DoForm is called, I look up this form class in the table. If I get a hit on cClassName (meaning, I have a match), then see if I've loaded the metadata for the application in cApp. If so, great, if not, load it (as opposed to SET CLASSLIB...Additive, one must use SET CLASSLIB IN (cApp) Additive). Then, as opposed to using CREATEOBJECT() to load the form, I use NEWOBJECT(lcClassName, lcModule, lcApp), where lcModule is the cModule field (basically, the class library) and lcApp is the cApp field (both ALLTRIM() ed). So what is the lSubApp field used for? This is a bit tricky, so bear with me. This app has a lot of interrelated pieces. Some of the forms are in the main module because they're called from multiple places. But their child grids are specific for that module. What a lUseSubApp = .f means is to load the metadata associated with the subsidiary application, but make the call from the main module -- IOW, use NEWOBJECT(lcClassName, lcModule) without the lcApp. Now it was a matter of putting the right class libraries in the right modules. When things got shuffled, be sure to exclude classes from the project when appropriate so they're not duplicated and regenerate metadata for the projects with shuffled class libraries (Side note: The metadata for the main project needed an additional record for the menu classes and would be added manually when regenerating). Gains: More memory, much more snappier load times and the app feels less boggy, even though it's huge. Downside, figuring out all this. But in this case, it's clearly worth it. Bill _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
