template won't compile - C2975

Sounds like an interesting project. I'm not sure if you are aware of (you probably are), but you can have a look at the way WTL is structured. It is a very lightweight wrapper for some windows. Of course it's only part of the story though.

But I don't see why "pWindow = new window("EDIT")" is not C++ or not OO ?

I mean that window is actually a class that you define along the lines of :

Code:

---

class window
{
public:
 window()
 {
  // Default constructor doesn't subclass
 }
 window(char *pSuperClass)
 {
  // Create the window using the the specified window superclass
 }

 char *m_pSuperClassWindow;
};

---

Yes i have read some reviews of WTL, and seen some samples, i also read an introduction to WTL by its author. But i never seen whats its guts, how it is built. Author never showed the details of the implementation, so i can only assume its overhead. I know MFC overhead is ridiculous for example, but some people find it paying off when writing medum sized applications. It is a matter of taste. So to conclude, i will continue R&D but will grab any WTL text book ASAP to educate myself, so i am not reinventing the wheel. MFC is history for me though.

Regarding "pWindow = new window("EDIT")"... no it is a very clean and straightforward nicely designed approach. I haven't really found out whether it suits me as a matter of fact ;) i mean, i am ACTUALLLY SITTING WITH R&D RIGHT NOW... It s hard to think that stuff alone without counter opinions, but conversing to you gives me food to the brain...

However if we think generic OO nice patterns come out:

class WNDCLASSEX //actually struct
{

}

defines a window class. In c++ terms we have got a C++ class defining a window class. In c++ terms we can assume this is a template then, because a template also defines a class.
So what i am trying to do is create a framework that will treat window classes as c++ classes based on templates:

Somethink similiar to:

class window::edit: public window::registered<"EDIT">
{
//add some wrappers for functions edit control can perform
//since most of them are called with messages, something
//that will create a mess in the code
}

Tired of typing, hope you catch my point, i am a terrible writer, or i have had too little time to express my idea. Indeed, this is interesting topic.

Hello there Ann & Yves

Your topic's quite interesting. I'm having the same idea as Ann. I don't know why ATL/WTL does a weird thing to create a window. It use a macro that expand to a static function to retrieve information of a window class. And then use this function in the a window creatation. That's limit us a lot and not clear as well.

I'm thinking of write a window class that can create a window object. Similar to a ClassFactory create COM object.

Hi TruBic, welcome to the discussion ;)

Well, its not like i DO object the WTL/ATL but ...Could you explain your idea better ?

I doesn't object ATL/WTL either. I just wonder why they do the weird thing.

What i mean is in order to create a window. We need to have an ATOM return when we register a window class. ATL did do that in their CWndClassInfo.

But instead let the CWndClassInfo create a window they let CWindowImpl create the window. But in order to create the window CWindowImpl need the ATOM from CWndClassInfo. So they define some special macros to get reference to CWndClassInfo. This is one of the macro:

Code:

---

#define DECLARE_WND_CLASS(WndClassName) \
static CWndClassInfo& GetWndClassInfo() \
{ \
        static CWndClassInfo wc = \
        { \
                { sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, StartWindowProc, \
                  0, 0, NULL, NULL, NULL, (HBRUSH)(COLOR_WINDOW + 1), NULL, WndClassName, NULL }, \
                NULL, NULL, IDC_ARROW, TRUE, 0, _T("") \
        }; \
        return wc; \
}

---

The inconvinience is when want to customize some details of the class info then we have to declare new macros, re-write CWindowImpl and insert our new macro in. Everything is the same, the only difference is we replace the DECLARE_WND_CLASS macro by our macro!

That's why I think let the CWndClassInfo create the window and return a pointer to the window object. By that way we can change whatever details of the CWndClassInfo as we like and don't have to re-write anything.

TruBic, there is an easier way of doing this ATL. You just add a member function to your control that overrides GetWndClassInfo.

Code:

---

static CWndClassInfo& GetWndClassInfo()
{
  static CWndClassInfo wc =
  {
    { sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, StartWindowProc,
      0, 0, NULL, NULL, NULL, NULL, NULL, "TestWindowType", NULL },
      // (HBRUSH) COLOR_WINDOW + 1
      NULL, NULL, NULL, TRUE, 0, _T("")
    };
    return wc;
}

---

For WTL, you can actually look at its source code. It's not nearly as complicated as MFC or the ATL innards.

Thanks for the help Yves. I got ATL point now.

Hang on Yves, I think I have to override the Create function as well, do I ?

Let say I create new type of window based on CWindowImpl then I have to do the following:

Code:

---

CMyWindow : public CWindowImpl<CMyWindow>
{
  static CWndClassInfo& GetWndClassInfo()
  {
    static CWndClassInfo wc =
    {
      { sizeof(WNDCLASSEX), CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS, StartWindowProc,
        0, 0, NULL, NULL, NULL, (HBRUSH)(COLOR_WINDOW + 1), NULL, "MyWindowClassName", NULL },
      NULL, NULL, IDC_ARROW, TRUE, 0, _T("")
    };
    return wc;
  }

  HWND Create(HWND hWndParent, RECT& rcPos, LPCTSTR szWindowName = NULL, DWORD dwStyle = 0, DWORD dwExStyle = 0, UINT nID = 0, LPVOID lpCreateParam = NULL)
  {
    return CWindowImpl<CMyWindow>::Create(hWndParent, rcPos, szWindowName, dwStyle, dwExStyle, nID, lpCreateParam);
  }
};

---

Is it right ?

Well, no ;) Since you derive from CWindowImpl, you'll see that CWindowImpl will actually use the information you provide in GetWndClassInfo.

Code:

---

HWND CWindowImpl::Create(HWND hWndParent, RECT& rcPos, LPCTSTR szWindowName = NULL,
  DWORD dwStyle = 0, DWORD dwExStyle = 0,
  UINT nID = 0, LPVOID lpCreateParam = NULL)
{
  if (T::GetWndClassInfo().m_lpszOrigName == NULL)
    T::GetWndClassInfo().m_lpszOrigName = GetWndClassName();
  ATOM atom = T::GetWndClassInfo().Register (&m_pfnSuperWindowProc);

  dwStyle = T::GetWndStyle(dwStyle);
  dwExStyle = T::GetWndExStyle(dwExStyle);

  return CWindowImplBaseT< TBase, TWinTraits >::Create(hWndParent, rcPos, szWindowName,
    dwStyle, dwExStyle, nID, atom, lpCreateParam);
}

---

Oh yeah, that T's so important and I ignore it. Thanks Yves.

There is no magic about the "T", its simply the template parameter for CWindowImpl<class T>. So since you specify your own class as the parameter, calling some function like T::func() means that you call a static function on your own class.

CWindowImpl provides a default implementation for GetWndClassInfo by using the DECLARE_WND_CLASS macro you were referring to, but since this is C++, your implementation will override the default one ;)

Quote:

---

Originally posted by Yves
Although I'm still not quite sure that it's really useful to put constants into template parameters.

---

It's quite when using static array sizes, which must be const. Imagine:

Code:

---

template<int N, type T>
class fixed_size_array
{
  /* ... */
private:
    T m_data[N]
};

---

This is faster than using dynamic memory. Boost has a great array class based on this. This array class
also has some other interesting features, such that it can take an initializer list of values.

I've used it personally for an n-tree implementation--basically a tree with each node having n children.

Jeff