Newbie: how to create a .LIB file? (Should I?)

[Michelle S.]

Hello
I am writing an application with lots of UI classes (trayicons, cool menus,
buttons etc...). The problem is that everytime i add a new class to my
project, it shows up in the Workspace. With so many non-important, non
changing classes there, it is hard to get at my CMainFrame and Doc/App
classes. Should I be making a LIB file and "packaging" all these extra
classes in it?
If so, I have a couple questions:

1) should i make a DLL or LIB?
2) where do i put the .H files, and after i have the LIB, do i still need
all the .CPP's?
3) how do i make a LIB or DLL and bring it into my application...?

THanks for any help.

-Mich

[Yael Raz]

Putting these controls into either a DLL or LIB sounds perfectly reasonable.
Use App Wizard (File | New | Projects) to create either an MFC Extension DLL
or Win32 static library. I would tend towards the DLL: as long as the
interface doesn't change, you won't need to re-link your application
whenever you change something in the custom-control implementation. However,
a DLL would have to be installed with the application, whereas a static
doesn't.

I'd put all the source code into a separate folder, define the DLL or LIB as
a separate project, remove the custom-control code from the app's project
and link the app with the resulting .LIB file (Project | Settings | Link |
Object/Library modules) - this is for both DLL and static LIB: to link with
a DLL you link with its LIB file. If you go the DLL way, you'll have to add
__declspec(dllexport) to your class declaration to make it visible from
outside the DLL (eg: class __declspec(dllexport) CMyClass, or better still:

#ifdef _AFXDLL
#define DLL_EXPORT __declspec(dllexport)
#else
#define DLL_EXPORT
#endif
class DLL_EXPORT CMyClass
{ ...

Michelle S. wrote in message ...

[Joseph M. Newcomer]

Making a DLL is easy; just create an "MFC Extension" DLL by selecting
the appropriate options in the AppWizard.

Whether you make a DLL or not is a matter of choice, taste, etc. I
rarely make DLLs because creating fully general reusable classes is
extremely time-consuming, and it seriously complicates the
distribution of an app (most of my clients want to send a single .exe
file, and they actively discourage the use of gratuitous DLLs).

What you do with the .cpp files (which you absolutely, positively
need!) is create subprojects of your main project. Use the
"Dependencies" menu item to indicate that your project depends on the
DLLs, so automatic bulids will do the right thing. Put the .cpp files
in the subdirectories of the main project. Put the .h files in an
include directory (at least that's what I do).

Add the .LIB files in the Project Settings, Link, Other Libraries edit
control. Be warned that this is a tediouos control to use because it
uses horizontal scrolling instead of being the much more sensible
draggable list box that it should be. Make sure you put the debug
version of your library in the debug version of your main project and
the release version of your library in the release version of your
main project. Alternatively, modify the subproject to create the .LIB
and .DLL files in the corresponding Release and Debug subdirectories
of your main project (my preference) then you don't need to put
explicit paths on the link library names.

You will need to make sure that the DLL files are in the same
directory as your executable. You must not, under any circumstances,
consider putting your DLLs into the Windows System directory. This is
always a strategic *and* tactical error. With the DLLs in your
executable directory, they will be found when your application starts
up.

The art of sharing DLLs with other applications you write, which might
be in other directories, is trickier. At that point, it is worth
considering using ActiveX controls to provide the functionality so you
can put them anywhere. But you have to consider techniques such as
explicit LoadLibrary calls and GetProcAddress. That's a topic for
another message someday.
joe
On Tue, 23 Mar 1999 18:12:16 -0600, "Michelle S." <mns...@ilstu.edu>
wrote:

>Hello
>I am writing an application with lots of UI classes (trayicons, cool menus,
>buttons etc...). The problem is that everytime i add a new class to my
>project, it shows up in the Workspace. With so many non-important, non
>changing classes there, it is hard to get at my CMainFrame and Doc/App
>classes. Should I be making a LIB file and "packaging" all these extra
>classes in it?
>If so, I have a couple questions:
>
>1) should i make a DLL or LIB?
>2) where do i put the .H files, and after i have the LIB, do i still need
>all the .CPP's?
>3) how do i make a LIB or DLL and bring it into my application...?
>
>THanks for any help.
>
>-Mich
>
>

Joseph M. Newcomer
newc...@flounder.com
http://www3.pgh.net/~newcomer