Class Constructor Parameters

[Entiranz]

Hi, im currently trying to design a level editor for a school project. Im using WinAPI code, and i'm havin trouble with the classes creating the base window. The constructor of the class thats creating the window needs a parameter, but sadly i don't exactly know what parameter to put in there. I probably need a reference to the class or an instance of the class that the creator class is inhereting from.

The header for the classes creating the window:
WinClass.h

#ifndef WINCLASS_H_INCLUDED
#define WINCLASS_H_INCLUDED
#include "WinProcedure.h"
#include <string>

class WinClassPara
{

    public:
        WinClassPara (HINSTANCE hInstance): hInst (hInstance){}
        HINSTANCE GethInst () const { return hInst; }
        char const * GetwcName () const {return wcName.c_str();}
    protected:
        HINSTANCE hInst;
        std::string wcName;

};

class WinClassMain: public WinClassPara
{

    public:
        WinClassMain (HINSTANCE hInstance, WNDPROC WndProc);

        void RegisterWin();
        void DeclareWinProp();
    protected:
        WNDCLASSEX wc;

};

class WinCreator: public WinClassMain
{

    public:
        WinCreator(); //Here is the issue.
        operator HWND () {return _hwnd;}
        void CreateWin();
        void ShowWin(int nShowWin = SW_SHOWNORMAL);
    protected:

        WinClassMain    & wc;
        HWND           _hwnd;

        DWORD        ExStyle;
        char const * WinName;
        DWORD          Style;
        int             xPos;
        int             yPos;
        int          cHeight;
        int           cWidth;
        HWND          WinOwn;
        HMENU           Menu;
        void          * Data;

};

#endif // WINCLASS_H_INCLUDED

The source code file:
WinClass.cpp

#include <windows.h>
#include "WinClass.h"
#include "Resources.h"

WinClassMain::WinClassMain(HINSTANCE hInstance, WNDPROC WndProc): WinClassPara (hInstance)
{

    wc.lpfnWndProc = WndProc;
    DeclareWinProp();

}

void WinClassMain::DeclareWinProp()
{

    wc.lpszClassName = GetwcName();
    wc.hInstance = GethInst ();
    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
    wc.hCursor = LoadCursor(0, IDC_ARROW);
    wc.cbSize = sizeof(wc);
    wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
    wc.style = CS_HREDRAW | CS_VREDRAW;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;

}

void WinClassMain::RegisterWin()
{

    RegisterClassEx(&wc);

}
                       // And also here, where i need the parameters again.
WinCreator::WinCreator ():_hwnd (0), wc (), ExStyle (0), WinName (0), Style (WS_OVERLAPPED), xPos (CW_USEDEFAULT), yPos (0), cHeight (CW_USEDEFAULT), cWidth (0), WinOwn (0), Menu (0), Data (0)
{
}

void WinCreator::CreateWin()
{

    CreateWindowEx(ExStyle, GetwcName(), WinName, Style, xPos, yPos, cHeight, cWidth, WinOwn, Menu, GethInst (), Data);

}

void WinCreator::ShowWin(int nShowWin)
{

    ::ShowWindow (_hwnd, nShowWin);
    ::UpdateWindow (_hwnd);

}

The error recieved without any parameters (or with parameters that ive tested for that matter) is this: error: no matching function for call to 'WinClassMain::WinClassMain()'

I hope you can help me with this, i'm rather new at C++/winapi programming.

[VictorN]

I guess you have to implement the default ctor for WinClassMain class.

[Entiranz]

Ive tried that as far as i know. Either i'm implementing it incorrectly or it won't accept it. Could you give me an example of how it would look if i did select it correctly?

[mlgoff]

Please post WinProcedure.h. We can't compile and debug this without it.

[Paul McKenzie]

Hi, im currently trying to design a level editor for a school project. Im using WinAPI code, and i'm havin trouble with the classes creating the base window.

One big word of advice:

Unless you're familiar with the Windows API 'C' interface, attempting to wrap these in classes yourself will become very time-consuming. The Windows API is complex enough using straight 'C'. Unless you have gone through the pains of implementing a non-trivial Windows program using the 'C' API, you shouldn't be trying to wrap the 'C' API into classes.

One big reason is that Windows API is event driven -- you have to somehow wrap runtime semantics (not just function calls) into a usable C++ infrastructure. That isn't as trivial as it looks. You need to know how to dispatch messages properly to your window classes, decide which is the best method to do this (a map of HWND's to objects, or some other means), etc.

Individuals and companies (such as Microsoft, Borland, etc.) that have successfully wrapped the Windows API into C++ classes spent a lot of time on accomplishing this, and the only way they could do this is that these individuals have extensive experience with Windows programming using the C' API.

If you want a framework, why didn't you use MFC, or if you really wanted to, use an established C++ interface to the Windows API, such as this one:

http://www.relisoft.com/win32/index.htm

Secondly, as to your code, why are you deriving WinCreator from WinClassMain, and at the same time, have a WinClassMain reference inside of WinCreator? What is your design idea using this strange setup?

Regards,

Paul McKenzie

[Entiranz]

Okay, will try to explain my actions here, keep in mind that im new.

I did have a working window before, but it was very simple and the next part of the level editor im not very familiar with. So, i tried making classes so that inserting new parameters into the window would be easier for me.

When it comes to the link below that you sent me, ive actually looked at that. However, im not good at simply implementing code from different sources as the result usually is that i need to put in variables that i have no idea what they should be, or what they do. So i write most of my code myself, and ive actually used the Generic program from that link as a template for my own. Maybe a good idea, probably not. At any rate, thats the code i have now, and id rather try to find a solution to it than have to rewrite it, if its at all possible.

When i started writing this code, i had no idea what MFC was. I was introduced to it by your suggestion.

And lastly as i stated before, im using the Generic program as a kind of template for this. The code in that program therefore looks rather like mine, except the parameter in the constructor they are using, works. Mine doesnt.

and to mlgoff, heres WinProcedure.h.

#ifndef WINPROCEDURE_H_INCLUDED
#define WINPROCEDURE_H_INCLUDED

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);



#endif // WINPROCEDURE_H_INCLUDED

Since its kinda empty, just declaring WndProc, heres the source code as well.
WinProcedure.cpp

#include <windows.h>
#include "WinProcedure.h"
#include "Resources.h"
#include "WinMenuFile.h"
#include "OpenFile.h"
#include "SaveFile.h"


HWND ghwndEdit;

LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{

   switch(msg)
   {
      case WM_CREATE:
         AddMenus(hwnd);
         break;
      case WM_COMMAND:
         switch(LOWORD(wParam))
         {

            case IDM_FILE_NEW:
               ::MessageBox (hwnd, "Not Implemented Yet!", "New File", MB_ICONINFORMATION | MB_OK);
               break;
            case IDM_FILE_OPEN:
               OpenDialog(hwnd);


               break;
            case IDM_FILE_SAVE:
               ::MessageBox (hwnd, "Not Implemented Yet!", "Save File", MB_ICONINFORMATION | MB_OK);
               break;
            case IDM_FILE_SAVEAS:
               SaveDialog(hwnd);
               break;

         }
         break;
      case WM_DESTROY:
         PostQuitMessage(0);
         break;
   }

   return DefWindowProc(hwnd, msg, wParam, lParam);

}

void LoadFile(LPSTR file)
{

   HANDLE hFile;
   DWORD dwSize;
   DWORD dw;

   LPBYTE lpBuffer = NULL;

   hFile = CreateFile(file, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
   dwSize = GetFileSize(hFile, NULL);
   lpBuffer = (LPBYTE) HeapAlloc(GetProcessHeap(), HEAP_GENERATE_EXCEPTIONS, dwSize + 1);
   ReadFile(hFile, (LPWSTR)lpBuffer, dwSize, &dw, NULL);
   CloseHandle(hFile);
   lpBuffer[dwSize] = 0;
   SetWindowText(ghwndEdit, (LPSTR) lpBuffer);
   HeapFree(GetProcessHeap(), 0, lpBuffer);

}

void SaveFile(LPSTR)
{



}

at the moment thats mostly used for the menus, which isnt the current issue here.

Hope that clears a few things up regarding my code (and whatnot).

[mlgoff]

Let's try this again. If you don't post the entire project, it makes it much harder for us to help you.

#include "Resources.h"
#include "WinMenuFile.h"
#include "OpenFile.h"
#include "SaveFile.h"

Also please post the exact error message you are getting.

1>------ Build started: Project: WinClassMain, Configuration: Debug Win32 ------
1>Build started 3/28/2012 8:39:01 AM.
1>InitializeBuildStatus:
1>  Touching "Debug\WinClassMain.unsuccessfulbuild".
1>ClCompile:
1>  WinProcedure.cpp
1>c:\projects\tutorials\c++\winclassmain\winclassmain\winprocedure.cpp(3): fatal error C1083: Cannot open include file: 'Resources.h': No such file or directory
1>  WinClass.cpp
1>c:\projects\tutorials\c++\winclassmain\winclassmain\winclass.cpp(3): fatal error C1083: Cannot open include file: 'Resources.h': No such file or directory
1>  Generating Code...
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.49
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Note that in the above listed output, The error code follows the text "fatal error:" (in this case "C1083"). If you highlight the error code and hit the F1 key, it will open the MSDN help page for the highlighted error code. That may help you as well.

[Entiranz]

Okay, will then post my entire code, along with the error. I will ignore the files i got that are currently empty, since they dont really do anything.

main.cpp

#include <windows.h>
#include "include/WinProcedure.h"
#include "include/WSmaker.h"
#include "include/WinClass.h"
#include "include/WinException.h"
#include "include/WinMenuFile.h"
#include "include/OpenFile.h"


int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int CmdShow)
{

   MSG msg;

   WinClassMain WCM1(hInstance, WndProc);

   WCM1.DeclareWinProp ();
   WCM1.RegisterWin ();

   WinCreator Wincreate(WCM1);

   Wincreate.CreateWin();
   Wincreate.ShowWin(CmdShow);

   while(GetMessage(&msg, NULL, 0, 0))
   {

      TranslateMessage(&msg);
      DispatchMessage(&msg);

   }
   return (int) &msg.wParam;

}

WSmaker and WinException are both empty at the moment.

WinProcedure.h

#ifndef WINPROCEDURE_H_INCLUDED
#define WINPROCEDURE_H_INCLUDED

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);



#endif // WINPROCEDURE_H_INCLUDED

WinProcedure.cpp

#include <windows.h>
#include "WinProcedure.h"
#include "Resources.h"
#include "WinMenuFile.h"
#include "OpenFile.h"
#include "SaveFile.h"


HWND ghwndEdit;

LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{

   switch(msg)
   {
      case WM_CREATE:
         AddMenus(hwnd);
         break;
      case WM_COMMAND:
         switch(LOWORD(wParam))
         {

            case IDM_FILE_NEW:
               ::MessageBox (hwnd, "Not Implemented Yet!", "New File", MB_ICONINFORMATION | MB_OK);
               break;
            case IDM_FILE_OPEN:
               OpenDialog(hwnd);


               break;
            case IDM_FILE_SAVE:
               ::MessageBox (hwnd, "Not Implemented Yet!", "Save File", MB_ICONINFORMATION | MB_OK);
               break;
            case IDM_FILE_SAVEAS:
               SaveDialog(hwnd);
               break;

         }
         break;
      case WM_DESTROY:
         PostQuitMessage(0);
         break;
   }

   return DefWindowProc(hwnd, msg, wParam, lParam);

}

void LoadFile(LPSTR file)
{

   HANDLE hFile;
   DWORD dwSize;
   DWORD dw;

   LPBYTE lpBuffer = NULL;

   hFile = CreateFile(file, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);
   dwSize = GetFileSize(hFile, NULL);
   lpBuffer = (LPBYTE) HeapAlloc(GetProcessHeap(), HEAP_GENERATE_EXCEPTIONS, dwSize + 1);
   ReadFile(hFile, (LPWSTR)lpBuffer, dwSize, &dw, NULL);
   CloseHandle(hFile);
   lpBuffer[dwSize] = 0;
   SetWindowText(ghwndEdit, (LPSTR) lpBuffer);
   HeapFree(GetProcessHeap(), 0, lpBuffer);

}

void SaveFile(LPSTR)
{



}

Resources.h

#ifndef RESOURCES_H_INCLUDED
#define RESOURCES_H_INCLUDED

#define IDM_FILE_NEW 1
#define IDM_FILE_OPEN 2
#define IDM_FILE_SAVE 3
#define IDM_FILE_SAVEAS 4


#endif // RESOURCES_H_INCLUDED

WinMenuFile.h

#ifndef WINMENUFILE_H_INCLUDED
#define WINMENUFILE_H_INCLUDED

#include "Resources.h"

void AddMenus(HWND);


#endif // WINMENUFILE_H_INCLUDED

WinMenuFile.cpp

#include <windows.h>
#include "WinMenuFile.h"
#include "Resources.h"

void AddMenus(HWND hwnd)
{
   HMENU hMenubar;
   HMENU hMenu;

   hMenubar = CreateMenu();
   hMenu = CreateMenu();
   AppendMenu(hMenu, MF_STRING, IDM_FILE_NEW, "&New");
   AppendMenu(hMenu, MF_SEPARATOR, 0, NULL);
   AppendMenu(hMenu, MF_STRING, IDM_FILE_OPEN, "&Open");
   AppendMenu(hMenu, MF_SEPARATOR, 0, NULL);
   AppendMenu(hMenu, MF_STRING, IDM_FILE_SAVE, "&Save");
   AppendMenu(hMenu, MF_STRING, IDM_FILE_SAVEAS, "&Save as");

   AppendMenu(hMenubar, MF_POPUP, (UINT_PTR)hMenu, "&File");
   SetMenu(hwnd, hMenubar);

}

WinClass.h

#ifndef WINCLASS_H_INCLUDED
#define WINCLASS_H_INCLUDED
#include "WinProcedure.h"
#include <string>

class WinClassPara
{

    public:
        WinClassPara (HINSTANCE hInstance): hInst (hInstance){}
        HINSTANCE GethInst () const { return hInst; }
        char const * GetwcName () const {return wcName.c_str();}
    protected:
        HINSTANCE hInst;
        std::string wcName;

};

class WinClassMain: public WinClassPara
{

    public:
        WinClassMain (HINSTANCE hInstance, WNDPROC WndProc);

        void RegisterWin();
        void DeclareWinProp();
    protected:
        WNDCLASSEX wc;

};

class WinCreator: public WinClassMain
{

    public:
        WinCreator(); //Here is the issue.
        operator HWND () {return _hwnd;}
        void CreateWin();
        void ShowWin(int nShowWin = SW_SHOWNORMAL);
    protected:

        WinClassMain    & wc;
        HWND           _hwnd;

        DWORD        ExStyle;
        char const * WinName;
        DWORD          Style;
        int             xPos;
        int             yPos;
        int          cHeight;
        int           cWidth;
        HWND          WinOwn;
        HMENU           Menu;
        void          * Data;

};

#endif // WINCLASS_H_INCLUDED

WinClass.cpp

#include <windows.h>
#include "WinClass.h"
#include "Resources.h"

WinClassMain::WinClassMain(HINSTANCE hInstance, WNDPROC WndProc): WinClassPara (hInstance)
{

    wc.lpfnWndProc = WndProc;
    DeclareWinProp();

}

void WinClassMain::DeclareWinProp()
{

    wc.lpszClassName = GetwcName();
    wc.hInstance = GethInst ();
    wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
    wc.hCursor = LoadCursor(0, IDC_ARROW);
    wc.cbSize = sizeof(wc);
    wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
    wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
    wc.style = CS_HREDRAW | CS_VREDRAW;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;

}

void WinClassMain::RegisterWin()
{

    RegisterClassEx(&wc);

}
                       // And also here, where i need the parameters again.
WinCreator::WinCreator ()
                        :_hwnd (0), wc (),
                        ExStyle (0), WinName (0), Style (WS_OVERLAPPED), xPos (CW_USEDEFAULT), yPos (0), cHeight (CW_USEDEFAULT),
                        cWidth (0), WinOwn (0), Menu (0), Data (0)
{
}

void WinCreator::CreateWin()
{

    CreateWindowEx(ExStyle, GetwcName(), WinName, Style, xPos, yPos, cHeight, cWidth, WinOwn, Menu, GethInst (), Data);

}

void WinCreator::ShowWin(int nShowWin)
{

    ::ShowWindow (_hwnd, nShowWin);
    ::UpdateWindow (_hwnd);

}

OpenFile.h

#ifndef OPENFILE_H_INCLUDED
#define OPENFILE_H_INCLUDED

void OpenDialog(HWND);

void LoadFile(LPSTR);

#endif // OPENFILE_H_INCLUDED

OpenFile.cpp

#include <windows.h>
#include "Resources.h"
#include "OpenFile.h"

void OpenDialog(HWND hwnd)
{

   OPENFILENAME ofn;
   TCHAR szFile[MAX_PATH];

   ZeroMemory(&ofn, sizeof(ofn));
   ofn.lStructSize = sizeof(ofn);
   ofn.lpstrFile = szFile;
   ofn.lpstrFile[0] = '\0';
   ofn.hwndOwner = hwnd;
   ofn.nMaxFile = sizeof(szFile);
   ofn.lpstrFilter = TEXT("All Files(*.*)\0*.*\0");
   ofn.nFilterIndex = 1;
   ofn.lpstrInitialDir = NULL;
   ofn.lpstrFileTitle = NULL;
   ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;

   if(GetOpenFileName(&ofn))
   {

      LoadFile(ofn.lpstrFile);

   }

}

SaveFile.h

#ifndef SAVEFILE_H_INCLUDED
#define SAVEFILE_H_INCLUDED

void SaveDialog(HWND);

void SaveFile(LPSTR);

#endif // SAVEFILE_H_INCLUDED

SaveFile.cpp

#include <windows.h>
#include "SaveFile.h"
#include "Resources.h"

void SaveDialog(HWND hwnd)
{

   OPENFILENAME sfn;
   TCHAR szSaveFileName[MAX_PATH];

   ZeroMemory(&sfn, sizeof(sfn));
   sfn.lStructSize = sizeof(sfn);
   sfn.lpstrFile = szSaveFileName;
   sfn.hwndOwner = hwnd;
   sfn.nMaxFile = sizeof(szSaveFileName);
   sfn.lpstrFilter = TEXT("AndysLvlEditorFile (*.Alef)\0*.Alef\0*All Files(*.*)\0*.*\0");
   sfn.Flags = OFN_EXPLORER | OFN_PATHMUSTEXIST | OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT;
   sfn.lpstrDefExt = "Alef";

   if(GetSaveFileName(&sfn))
   {

      SaveFile(sfn.lpstrFile);

   }

}

And as for the error im getting:

||=== Level Editor, Debug ===|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.h||In constructor 'WinCreator::WinCreator()':|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.h|43|warning: 'WinCreator::_hwnd' will be initialized after|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.h|42|warning: 'WinClassMain& WinCreator::wc'|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.cpp|36|warning: when initialized here|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.cpp|39|error: no matching function for call to 'WinClassMain::WinClassMain()'|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.cpp|5|note: candidates are: WinClassMain::WinClassMain(HINSTANCE__*, LRESULT (*)(HWND__*, UINT, WPARAM, LPARAM))|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.h|20|note: WinClassMain::WinClassMain(const WinClassMain&)|
C:\Documents and Settings\nkpit09aski\Mina dokument\Dropbox\Spelet - P100\RIKTIGT HEMLIG PROGRAMMERINGSKOD\Andreas Brosum LvL editor of Awesumness\Level Editor\include\WinClass.cpp|36|error: value-initialization of 'WinClassMain& WinCreator::wc', which has reference type|
||=== Build finished: 2 errors, 3 warnings ===|

The exact error im referring to is this:
error: no matching function for call to 'WinClassMain::WinClassMain()'|

That is so far my entire level editor. Hope it isnt too hard to read.

[VictorN]

...
The exact error im referring to is this:
error: no matching function for call to 'WinClassMain::WinClassMain()'|

That is so far my entire level editor. Hope it isnt too hard to read.

As I wrote you in the post#2:

... you have to implement the default ctor for WinClassMain class.

So, Why did you ignore my post?

[TheGreatCthulhu]

As I wrote you in the post#2:
[...]
So, Why did you ignore my post?

To his defence, he didn't:

Ive tried that as far as i know. Either i'm implementing it incorrectly or it won't accept it. Could you give me an example of how it would look if i did select it correctly?

@OP:
It looks like you're a bit confused about what the default constructor is - it's a parameterless constructor (or one where all the arguments have defaults). This constructor is auto-generated by the compiler if you don't define your own constructor(s).

Now, as pointed out here:

Although the constructors and destructors of the base class are not inherited themselves, its default constructor (i.e., its constructor with no parameters) and its destructor are always called when a new object of a derived class is created or destroyed.

If the base class has no default constructor or you want that an overloaded constructor is called when a new derived object is created, you can specify it in each constructor definition of the derived class:

derived_constructor_name (parameters) : base_constructor_name (parameters) {...}

[EDIT by me] This is often formatted like this:

derived_constructor_name(parameters) 
    :base_constructor_name(parameters) 
{
    // ...
}

For example:

// constructors and derived classes
#include <iostream>
using namespace std;

class mother {
  public:
    mother ()
      { cout << "mother: no parameters\n"; }
    mother (int a)
      { cout << "mother: int parameter\n"; }
};


// mother: no parameters
// daughter: int parameter
class daughter : public mother {
  public:
    daughter (int a)
      { cout << "daughter: int parameter\n\n"; }
};

// mother: int parameter
// son: int parameter
class son : public mother {
  public:
    son (int a) : mother (a)
      { cout << "son: int parameter\n\n"; }
};

int main () {
  daughter cynthia (0);
  son daniel(0);
  
  return 0;
}

Notice the difference between which mother's constructor is called when a new daughter object is created and which when it is a son object. The difference is because the constructor declaration of daughter and son:

daughter (int a)               // nothing specified: call default
son (int a) : mother (a)    // constructor specified: call this

See also these answers at StackOverflow for another simple example and some links about initialization lists.

So, figure our what's best for your design, and either provide a default constructor, or explicitly call the existing one.

The argument about the WinClassMain-WinCreator relationship still stands: it is a bit weird. When you see a class named something like "Creator", it makes you think that it's a factory class of some kind, but that's not the case here. Factories usually don't inherit the objects they are creating. What are you trying to do with the two levels in the inheritance hierarchy? What do those classes represent, conceptually?

[TheGreatCthulhu]

A few words.
I've been looking at the "Generic" example you used as a starting point for your design - and I think you didn't quite get it.

There, the (WinSimpleClass <----- WinClass <----- TopWinClass) hierarchy has a specific purpose of defining and representing window classes, and there is a separate hierarchy that actually creates windows belonging to these window classes, and the windows themselves, strictly speaking, aren't actually represented as objects. Some of their functionality is represented by view-controller pairs, since the example uses the Model-View-Controller (MVC) architectural style (well... a rather funky variation of it, but let's not get picky...).
The design here is rather different from the approach used in MFC - where you have classes actually representing windows and controls.

Let me stop for a moment here. Window class is a concept of the windows operating system, and it doesn't really have anything to do with the C++ language. From MSDN:

Each window class has an associated window procedure shared by all windows of the same class. The window procedure processes messages for all windows of that class and therefore controls their behavior and appearance. For more information, see Window Procedures.

A process must register a window class before it can create a window of that class. Registering a window class associates a window procedure, class styles, and other class attributes with a class name. When a process specifies a class name in the CreateWindow or CreateWindowEx function, the system creates a window with the window procedure, styles, and other attributes associated with that class name.

WinClass encapsulates this concept. It inherits some basic functionality from WinSimpleClass, and providing some default values for the internal state (a WNDCLASSEX instance). It provides methods to manipulate the internal state, and in this particular design, derived classes, like TopWinClass use those methods to change the defaults to something more appropriate (note that inheritance is not the only way to go here).

Note that, unlike your constructors, the constructors for WinClass and TopWinClass both explicitly call base class constructors.

Next, there's the (WinMaker <---- TopWinMaker) hierarchy, which simply wraps the native CreateWindowEx api and enables you to show/hide the window in various ways. This is not a Factory, since it doesn't return any kind of window-representing object - it just wraps function calls.

The Controller supposed to be MVC Controller, and it's job is to detect user input and inform the view when appropriate, or update the model if required (but I don't see it actually doing the latter). Each created window should have a distinct Controller instance associated with it. It is accessed from MainWndProc. (Note: One would expect it's methods to be called by the corresponding WndProc of any corresponding window. The About dialog doesn't use it, though.)
Again, it simply wraps some API calls.

The View class in this example doesn't do much, other than handling the painting of the window, and storing it's size. In MVC, the view class would store all the view-related data (size, location, sub-controls, state of one or more widgets), so that it is separated from the presentation logic (what's enabled-disabled and under what conditions, what is checked/unchecked and when, what colors are used and for what...), which would be implemented in some other class (like in the Controller).
All this a bit advanced; the main reason for this separation is to facilitate the testing of the presentation logic, which can be rather complicated, and potentially of other program logic (unit-testing frameworks can make use of mock view and model objects, for example).
Also, when MVC was originally developed, the control ("widget") classes were oblivious to user input, so they used Controllers to get the user input and connect it to the view classes in a OO way.
Today, most UI frameworks, like MFC, have controls with built-in input detection, so a similar architectural pattern is used, called Model-View-Presenter (MVP), which assumes that the View can detect user input.

But, in the "Generic" example, the concept of a window is not entirely encapsulated; rather, a part of the functionality of a window is encapsulated in 2 specific classes (view/controller), and there's an encapsulation of the concept of OS window classes.
These all come together in the window procedure - so the overall impression is that the separation from the API is rather thin (which is not necessarily a bad thing).

Finally the Model represents your data layer. It should abstract away the actual storage mechanism, so that it can be changed or replaced without affecting the view/controller classes.

Anyway, I hope this provides you with a better understanding of what is going on in there. As you see, there are a lot of things to consider, so it's not a trivial task - but if you're up for it, for the sake of practice, then go for it.

However, if you want to create a working level editor for your school project, consider switching to MFC. The hard work of abstracting away the WinAPI using an OO approach is already done there, and it's a stable framework that exists for quite some time. Also, if you're familiar with windows API (at least to some extent), then you'll do just fine with MFC - a lot of the functions are named almost exactly the same. In the end, trying it out will provide you with some insight into how the encapsulation is done in MFC - try thinking about what's going on under the hood, in terms of how would you do the same thing in windows API.
With that insight, you might have a better idea on how would you approach wrapping it - if only for practice.

Doing things yourself is good, but you also need to learn to use existing libraries (you're actually doing so already - otherwise, you'd be programming in assembly or something). At some point, things will become too complicated, and time will become too limited, so you won't be able to afford reinventing the wheel. But by that point, you'll hopefully be experienced enough to be able to understand the design and the inner workings of a library to the extent that enables you to use it properly.

[Entiranz]

Ive looked over the MFC, and sadly i cant say i understand much of it. I see that theres a great amount of already finished classes in there, with explanations of what they and their members are supposed to do. Sadly, theres so much! I cant really tell which ones i need for my project.

And once again, im confronted with the biggest problem i face when using finished code like this, i really have no idea where to put things. Inserting code that others have made is not one of my strong sides.

Ive heard the term "reinventing the wheel" before, even though that was in OOP based PHP. I know that doing that is time consuming and not the best idea, but when i look to other code for help i either look at other code and copy it by writing similarily structured code myself, or look at code ive made myself earlier, so i can understand it more easily.

In this case, i might just have to reinvent the wheel. Im not fond of it, but even if i fail i will at least have gained some insight for use in other projects in the future. Even if that insight is that i really have to learn how to implement finished code into my own projects.

[Paul McKenzie]

Ive looked over the MFC, and sadly i cant say i understand much of it.

Are you attempting to look at the MFC source code, or understand how to use the MFC classes?

Ive heard the term "reinventing the wheel" before, even though that was in OOP based PHP. I know that doing that is time consuming and not the best idea, but when i look to other code for help i either look at other code and copy it by writing similarily structured code myself, or look at code ive made myself earlier, so i can understand it more easily.

There is a big issue with attempting to reinvent this particular wheel:

The Windows API is not trivial. As I stated before, if you don't know how to write a Windows event-driven program using straight 'C' code, understand message dispatching, etc. then no amount of experience with C++ is going to help you. You can't just copy and paste code here and there to accomplish something as complex as wrapping the Windows API -- you have to have some sort of design pattern on how to implement these various pieces of a Windows program.

Did you go to the link I posted? Those persons who implemented the classes took one approach, MFC takes another approach, Borland's OWL takes a third approach, Windows++ takes another approach, I could go on. All of these different methods of wrapping the Windows API into C++ classes has their strengths and weaknesses. But regardless, the persons putting these libraries together had a plan of putting a 'C' based, event-driven API into a C++ framework.

In this case, i might just have to reinvent the wheel. Im not fond of it, but even if i fail i will at least have gained some insight for use in other projects in the future. Even if that insight is that i really have to learn how to implement finished code into my own projects.

You would be better off if you learn an existing framework, it doesn't have to be MFC.

Again, unless you have experience writing a fully-fledged 'C' Windows API program, plus have intermediate to advanced experience in C++ plus know design patterns, then you're not going to get too far without having seen how others have done this and learn the technique(s) they're using.

Regards,

Paul McKenzie

[Entiranz]

Posted by: Paul McKenzie
Are you attempting to look at the MFC source code, or understand how to use the MFC classes?

Both. Its a little overwhelming.

Did you go to the link I posted? Those persons who implemented the classes took one approach, MFC takes another approach, Borland's OWL takes a third approach, Windows++ takes another approach, I could go on. All of these different methods of wrapping the Windows API into C++ classes has their strengths and weaknesses. But regardless, the persons putting these libraries together had a plan of putting a 'C' based, event-driven API into a C++ framework.

Yes, as i stated earlier, i have gone to that link. The problem with the code both there and in MFC, is that there is so much of it that for someone who is relatively new, it is hard to see what is what. Most ways of learning something new takes you through it step by step. Relisoft jumps from something simple and easily understood to a huge mass of code with poor explanations. MFC doesnt really start simple at all, i can go through the various classes as much as i want, even though they explain what everything does, theres probably alot of things in there i dont need and i cant tell which is which.

So unless i find an existing framework that doesn't really suffer from these problems as much as these two do, there isnt much i can do. Any suggestions would be welcome.

[Paul McKenzie]

Both. Its a little overwhelming.

You should be learning the high-level portion of MFC, not the MFC source code. You should be studying basic programs using MFC.

Of course the source code is going to be sophisticated, because wrapping the Windows API takes sophistication.

Yes, as i stated earlier, i have gone to that link. The problem with the code both there and in MFC, is that there is so much of it that for someone who is relatively new, it is hard to see what is what.

Write a program using the MFC, Relisoft, whatever. Then single step through the program to see how it works. Learn the public interface first, not the internals.

Most ways of learning something new takes you through it step by step. Relisoft jumps from something simple and easily understood to a huge mass of code with poor explanations. MFC doesnt really start simple at all, i can go through the various classes as much as i want, even though they explain what everything does, theres probably alot of things in there i dont need and i cant tell which is which.

Again, you are taking the wrong approach.

In general, any library, be it MFC, Relisoft, or even ones that are not related to GUI such as Math libraries, Image libraries, etc. all are sophisticated under the hood. The point of the library is to hide that sophistication from the user of the library by providing a public interface, functions to call that makes the job easier, etc.

For example, my company produces TWAIN libraries, a scanner protocol. It takes 3 or 4 function calls using our library to open TWAIN, open the scanner, scan the image to a file, and close. Easy, right? Of course it's easy to the user. If you happen to open up the library and see the source code, it contains very sophisticated usage of the TWAIN protocol, event driven loops, some multithreading, etc. hiding all of these details from the user. All the user sees is 4 simple functions that do the job.

So I'll say it again,

If,

1) you don't have the requisite C++ knowledge, plus

2) don't have a familiarity with design and design patterns and which ones to use plus

3) don't know, on a low-level, the entity you're attempting to wrap as an API,

then forget about it. You can be a user of a library, but to create your own requires much more experience in the three items I mentioned. Look at TheGreatCThulhu's post, and you see that all 3 items I mentioned above are necessary to implement anything decent in terms of wrapping the Windows API.

So unless i find an existing framework that doesn't really suffer from these problems as much as these two do,

There are no problems in these libraries. MFC is easy to use.

The "problem" is not one of the libraries -- again, the Windows API is sophisticated. If you're looking for a C++ API wrapper that is "easy", then you're not going to find it, because of the very nature of Windows OS itself.

Regards,

Paul McKenzie