Common problem, non mfc app has to link with a mfc dependant lib, how to solve. - Programmer

This is a discussion on Common problem, non mfc app has to link with a mfc dependant lib, how to solve. - Programmer ; Ok, I have come across this too many times now, someone must have a good solution. I have a non-mfc dll, that uses ATL and COM quite a lot and I want it to stay that way. A new version ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Common problem, non mfc app has to link with a mfc dependant lib, how to solve.

  1. Common problem, non mfc app has to link with a mfc dependant lib, how to solve.

    Ok, I have come across this too many times now, someone must have a
    good solution.

    I have a non-mfc dll, that uses ATL and COM quite a lot and I want it
    to stay that way. A new version of one of the libraries we need to use,
    just happens to be MFC dependant. It doesnt even have a GUI, so I
    suspect its probably just using something like CStrings somewhere. Its
    header files include afxwin.h

    I end up with the error message: fatal error C1189: #Fehler :
    WINDOWS.H already included. MFC apps must not #include

    But my app is specifically not MFC, its only one little 3rd party lib
    that uses it.

    I wish it the compiler was smart enough to just link the MFC bits in
    where its needed, and ignore it for the other bits.

    Now I have solved this problem in previous projects, but making my DLL
    a MFC dll, which messes up with some of the COM and ATL stuff in there
    involving lots of tedious mucking around trying to get it all to work.

    But that cant be the right way. There must be a standard way to use a
    MFC dependant lib in a non-MFC project. Changing the whole project to
    an MFC one just to suit one tiny little lib is not an option anymore.

    Anyone know the standard way to do this?

    Thanks


  2. Re: Common problem, non mfc app has to link with a mfc dependant lib, how to solve.

    wrote in message
    news:1137665760.553701.37600@z14g2000cwz.googlegro ups.com...
    > Ok, I have come across this too many times now, someone must have a
    > good solution.
    >
    > I have a non-mfc dll, that uses ATL and COM quite a lot and I want it
    > to stay that way. A new version of one of the libraries we need to use,
    > just happens to be MFC dependant. It doesnt even have a GUI, so I
    > suspect its probably just using something like CStrings somewhere. Its
    > header files include afxwin.h
    >
    > I end up with the error message: fatal error C1189: #Fehler :
    > WINDOWS.H already included. MFC apps must not #include
    >
    > But my app is specifically not MFC, its only one little 3rd party lib
    > that uses it.
    >
    > I wish it the compiler was smart enough to just link the MFC bits in
    > where its needed, and ignore it for the other bits.
    >
    > Now I have solved this problem in previous projects, but making my DLL
    > a MFC dll, which messes up with some of the COM and ATL stuff in there
    > involving lots of tedious mucking around trying to get it all to work.
    >
    > But that cant be the right way. There must be a standard way to use a
    > MFC dependant lib in a non-MFC project. Changing the whole project to
    > an MFC one just to suit one tiny little lib is not an option anymore.
    >
    > Anyone know the standard way to do this?
    >
    > Thanks
    >


    If your talking about an import library that contains MFC, I would try to
    change the library's header file assuming that no MFC code is used in any
    entry points (parameters).

    If your talking about a static library, you've probably found the only way,
    at least the only one I know of.

    --
    ============
    Frank Hickman
    Microsoft MVP
    NobleSoft, Inc.
    ============
    Replace the _nosp@m_ with @ to reply.



  3. Re: Common problem, non mfc app has to link with a mfc dependant lib, how to solve.

    On 19 Jan 2006 02:16:00 -0800, kzawah@gmail.com wrote:

    >I have a non-mfc dll, that uses ATL and COM quite a lot and I want it
    >to stay that way. A new version of one of the libraries we need to use,
    >just happens to be MFC dependant. It doesnt even have a GUI, so I
    >suspect its probably just using something like CStrings somewhere. Its
    >header files include afxwin.h
    >
    >I end up with the error message: fatal error C1189: #Fehler :
    >WINDOWS.H already included. MFC apps must not #include


    This *might* work. It's been the "key" for me several times. It seems
    to happened when mixing Win32, COM and MFC.

    #undef windows.h at the appropriate place, maybe right before the
    error then #define it again when and where needed. Basically you will
    be bringing it in and out of scope where needed.

    Admittedly this is tricky stuff, but "whaddya going to do."

    We must either find a way or make one. - Hannibal. :-)

+ Reply to Thread