Sorry for the delayed answer, it has something to
do with the 7 - 9 hours difference between us and
germany.

>I think if I could isolate major functions into a DLL, that would help. Where can I get information on how to create a DLL in FoxPro?
>
I don't now where you can get the info, but it's very easy to create the DLL. In the dialogue where you create the exe file there should also be an option for a dll. Then you can call from your main app the function from the dll like from every other dll. I think it's documented in the help. If not, let me know and i'll send you more infos.

Another possible approach: split you application in one exe an one or more *.app. The exe may contain only the main logic and menues. The you can call your app files as needed.

Like Bruce said, 6 MB it's not unusual or very big for today, but on some misconfigured maschines with only 16 MB it may be a problem. The splitting makes sense only if you can partition your functionality over the dlls or app in such a way that your user won't need them all at the same time.

If your are concerned only by the time it takes to load your application, then you may use a little trick: compile your whole application as an dll an write a small vc or vb program wich will only bring the splash screen and then start in the background your real application. It's really great, the user will see the splashscreen almost immediatly after his mouse click ....

>Is there a difference with an .APP and a .EXE? I mean, do you have to put SCX's inside an EXE while you don't for an .APP?
>

There are a lot o differences between an app an an exe, but this has nothing to do with the location of the scx files. In order to run an app your client will need a copy o vfp. For the exe he will need only the vfp runtimes. An exe is an app with an exe header.

If you include the scx in your exe or app, then they will be write protected (like any other file you've included) an "always" (not thinking now about os paging) in main memory. Drawback: if you have a small change to one scx based form, then you will have to recompile your whole app or exe and redistribute it to your customer.

Scx outside your app or exe: put the scx in a directory which is in the path of your application and the application will find them. It's also very easy to update only one form, with an email attachement, disekette and so on. The only drawback: the scx are unprotected on your drive. I think you can make the directory read only, but I'm not quite sure. As somebody in the thread pointed out: o can do the same with your vcx, and with almost all your files.

Sorry for the misinformation, you don't need to pack the scx, only the vcx, Bruce is right.

>I've looked through my development library and see that 2.11MB is dedicated to screen forms (scx). I've only got 1.1MB in procedural code and that's about the size a DLL would be anyway so may it can stay where it is. My class lib consumes 1.02MB, and then I have images, bitmaps and icons that consume 2MB. (Gee that' a lot of window dressing?!?!)
>
Then it's seems to be a good decision to exclude the scx and vcx from the main application file. You can do the same with the bitmaps, but take care, because a form or buttons without the bitmaps or icons it's not very pleasent to look at. Give it a try with the read only directory.

>By getting rid of the deleted records in the scx and vcx, is that a matter of using the scx or vcx tables exclusively and packing them?
>

Yes ! Forget the scx.

>Thanks for your help and ideas.

Your welcome !