1

I was talking about re-factoring yesterday, and the approach I was going for was obviously wrong. I looked into suggested patterns, but the problem was still that the common functionality is really a thing of a supper class, which I couldn't derive from as the MFC puts on it's own requirements for different windows (CWnd/CDialogEx).

Today I got an idea, that is, I could use a superclass template to pack the common logic which would solve the problem, theoretically...

That is, I define templated CCommon class, and inherit it with required superclass in all window classes. Like class CMyWnd : private CCommon<CWnd>

Unfortunately MFC makes things super ugly because of the macros...

#pragma once

template <class T> class CCommon : public T
{
    //DECLARE_DYNAMIC(CCommon)

public:
    CCommon();
    virtual ~CCommon();

//protected:
    //DECLARE_MESSAGE_MAP()
};


//IMPLEMENT_DYNAMIC(template <class T> CCommon<T>, CWnd)

template <class T> CCommon<T>::CCommon()
{

}

template <class T> CCommon<T>::~CCommon()
{
}


//BEGIN_MESSAGE_MAP(template <class T> CCommon<T>, CWnd)
//END_MESSAGE_MAP()

Is there a way I could work around this problem?

Things like IMPLEMENT_DYNAMIC(template <class T> CCommonWndLogic<T>, T) or template <class T> IMPLEMENT_DYNAMIC(CCommonWndLogic<T>, T) doesn't seem to compile at all. Same with message maps, which I would really like carry over to the base class.

Coder
  • 3,695
  • 7
  • 27
  • 42
  • Unfortunately, the work-around is to not use MFC. Think about ATL/WTL as they are similar without all the backwards compatability goop, ugly easy to break macros and shitty socket code. You can find ATL/WTL links here: http://en.wikipedia.org/wiki/Windows_Template_Library They tend to move around on the MS site. – JimR Jan 04 '11 at 09:36
  • Unfortunately I have to re-factor an existing code base and rewrite is out of scope :( WTL really seems nice. – Coder Jan 04 '11 at 09:57
  • [Check this thread](http://stackoverflow.com/questions/3004870/can-a-custom-mfc-window-dialog-be-a-class-template-instantiation) – Goz Jan 04 '11 at 23:42

1 Answers1

3

You are asking for trouble with this approach unfortunately. MFC is riddled with hacks and legacy workarounds. Your approach isn't really practical unless you can work with MFC at source level. You really can't. Use MFC strictly as an API to be called as required. Do all your state of the art bleeding edge C++ software engineering in your own independent class hierarcy, and just call MFC as required to implement the details of your UI.

Bill Forster
  • 6,137
  • 3
  • 27
  • 27
  • I found the BEGIN_TEMPLATE_MESSAGE_MAP(theClass, type_name, baseClass ) macro, which now compiles with the message map, unfortunately there seems to be no IMPLEMENT_DYNAMIC alternative, can I just skip it if the derived class will have IMPLEMENT_DYNAMIC on it's own? – Coder Jan 04 '11 at 09:56
  • @Coder, Sorry I wish I could answer your specific, detailed questions. I can't. Experience, including much bitter experience with MFC suggests to me that your approach is impractical because it will leave you forever foundering in a sea of weird macros and other detritus. The best way of living with MFC is to use it conservatively, as an API not a framework, and in ways its designers(!?@#) made provision for. If you do have no other alternatives I wish you good luck. And I hope whatever you come up with will be compatible with whatever maintenance approach(es) MS applies in the future. – Bill Forster Jan 04 '11 at 21:18
  • +1 for this. You might get something to work eventually, but you're fighting the architecture every step of the way. Do you know how old MFC is? Templates are foreign to it; they had to hack their own try/catch for goodness sake. – Mark Ransom Jan 05 '11 at 03:49