   Wrapper for wxWidgets and MFC
  This is perhaps an odd request, but I'd need a Visual C++ wrapper that supports both wxWidgets and MFC.Anyone happens to have that ?Thanks   
  A wrapper for a wrapper? Seriously?   ;  Why do you think you need a wrapper instaed of an interface?If you separate all application related processing from the user interface you should be able to implement your UI portion in either MFC or wxWidgets and the rest of the application won't care.I'd suggest you just stick to using wxWidgets exclusively.  Its just easier.  You'd still want to separate application processing from UI processing though.   ;  It's just a complicated matter. I have to use a MFC VC++ project because I have to use some API's from Idrisi (www.clarklabs.org) which are working only on MFC's.But I'd like like to use wxWidgets to design the software. That's why I asked if existed such a wrapper.   ;  I looked at the URL you posted, but couldn't find anything saying they require MFC or only support MFC.Are the components you're trying to use doing UI or just doing GIS back end stuff?If its just back end stuff, then I would use the Adapter pattern to encapsulate the MFC-ness inside that one component and do everything else in wxWidgets.   ;  The components are just doing GIS back end elaborations. How would I use the adapter pattern ? I never heard anything about that.Thanks for your support.   ;  The Adapter pattern takes one object's interface and makes it appear to the caller like some other interface.  The adapter class adapts the original object's interface to the new interface.In this particular case, you've got a 3rd party component that is coupled to MFC and you want to adapt that component so that callers of the component don't have to be coupled to MFC.  I'll assume that's because the 3rd party component is using some sort of MFC related classes in its public interface, say something like CArray.Let's create a hypothetical class to make the discussion a little more concrete:struct Point{    float x;    float y;};class MegaGIS{public:    MegaGIS();    ~MegaGIS();    CArray<Point> GetBoundary();};We want to use this MegaGIS class, but we don't want people to have to deal with CArray<Point>.  We want to use std::vector<Point> instead.  We can write an adapter around MegaGIS that handles the difference in interfaces.// headerclass MegaGISAdapterImpl;class MegaGISAdapter{public:    MegaGISAdapter();    ~MegaGISAdapter();    std::vector<Point> GetBoundary();private:    MegaGISAdapterImpl *m_impl;};// source implementationclass MegaGISAdapterImpl{public:    MegaGISAdapterImpl() : m_megaGIS()    {}    ~MegaGISAdapterImpl()    {}    std::vector<Point> GetBoundary()    {   CArray<Point> results = m_megaGIS.GetBoundary();   std::vector<Point> adaptedResults(results.GetCount());   std::copy(adaptedResults.begin(), adaptedResults.end(), &results[0]);   return adaptedResults;    }private:    MegaGIS m_megaGIS;};MegaGISAdapter::MegaGISAdapter() : m_impl(new MegaGISAdapterImpl()){}MegaGISAdapter::~MegaGISAdapter(){    delete m_impl;}std::vector<Point> MegaGISAdapter::GetBoundary(){    return m_impl->GetBoundary();}Now remember, the whole point of this adapter was to hide the "MFC-ness" of MegaGIS from the consumers of the adapter.  For that reason I've used the "pImpl" idiom to hide the fact that the implementation deals with CArray<T>.  Otherwise, anyone who included the header for the adapter would also have to include the header for MFC's CArray<T>.Of course, there was a price to be paid for using the adapter to make the interface hide the MFC-ness.  We are copying the data around from a CArray<T> to a std::vector<T>.  Depending on the amount of data flying around, it might not be practical to do this.My general advice would be to try and keep the MFC-ness of the 3rd party component isolated and contained into the single source file that implements the adapter.  I wouldn't expose the MFC-related business to more components of your application until a profiling run indicated that the adapter was taking too much time.If you could post an example of the kind of MFC-contamination that's in the 3rd party component you're trying to use, we could give more specific advice.   ;  legalize, thanks for your long and instructive post. After that I've been able to encapsulate the MFC classes and now they work perfectly.   