Wes
July 13th, 2000, 10:05 AM
I'm one of a team a people developing an "n-tier" Microsoft application. It uses MS technologies, (ADO, DCOM, ASP, C++ COM components under MTS, NT, etc., a relational DBMS ), and a VB client. The VB client is a standard MDI application. It has quite a few child windows, some using multiple user controls. Our problem is that the executable size is getting too large, approaching 8 or 9 MB, which is not really practical for this application. We would like a smaller EXE. We have identified some functionality that we would would like to isolate into separate files. We found we could easily create separate EXE's and have one executable shell to the other when necessary, but this doesn't seem like the best approach. Ideally we would like to break out some of the VB client functionality into separate DLL's or OCX's. We think that the best sounding solution for us at this point would be to move some of the existing MDI child windows and their user controls into a seperate DLL(s) and then simply reference them in our main MDI project, with minimal changes to our exisiting code. But we suspect that it's not going to be that easy nor simplistic. When creating a new VB project (VB 6.0 Enterprise), you're presented with a lot different choices for project types, (ActiveX Exe, ActiveX DLL, ActiveX Control, ActiveX Document Exe, ActiveX Document DLL, etc.). What's the best way to proceed to try to put some of the child forms (or just their user controls) and their functionality into a DLL or OCX? What are our choices? What are some of the most obvious pitfalls, and how much rework would we have to do? And, where can we find some resources (online hopefully) that address this kind of design\development issue? Thanks for your help. Will.