C / C++ / MFC

Adam Roderick J4-Apr-10 20:15

Adam Roderick J

4-Apr-10 20:15

CString is MFC class.
And the buffer it uses inside this class is handled by CString, it has nothing to do with user unless you are creating a pointer of the CString( Which is not at a good practice.)
Inside this CString class, destructor is having the code to delete the memory allocated for its internal buffer. So dont worrry, CString will delete that memory for you when it goes out of scope Smile | :)

Величие не Бога может быть недооценена.

modified on Monday, April 5, 2010 3:06 AM

TechAvtar4-Apr-10 21:35

TechAvtar

4-Apr-10 21:35

But what if the usage is as below? The variable temp is not going out of scope.
Will it cause leak?

CString temp; //global variable

while(1)
{
temp = "hello"; //Assignment 1
temp = "world"; //Assignment 2
}

Adam Roderick J4-Apr-10 21:40

Adam Roderick J

4-Apr-10 21:40

It will release the memory of previously allocated pointer on the = operator of CString.

See the code of CString.
The specified function is called inside the = operator.

void CString::AllocBeforeWrite(int nLen)
{
	if (GetData()->nRefs > 1 || nLen > GetData()->nAllocLength)
	{
               // This release will release all the memory allocated previously, so you wont face any memory leak.
		Release();
		AllocBuffer(nLen);
	}
	ASSERT(GetData()->nRefs <= 1);
}

Hope you are now clear with it Smile | :)

Величие не Бога может быть недооценена.

modified on Monday, April 5, 2010 3:53 AM

Joe Woodbury5-Apr-10 6:41

Joe Woodbury

5-Apr-10 6:41

Since "world" is the same length as "hello", no reallocation will be done; "world" will just overwrite "hello".

If you set a string "hello world", the internal buffer would be reallocated in a safe manner, resulting in no leak. (For optimization reasons, CString sometimes allocates a larger buffer than requested, so even setting a larger string won't result in a reallocation.)

Second Window in Win32

Fareed Rizkalla4-Apr-10 14:51

4-Apr-10 14:51

I've written a Win32 application that runs and displays a window, but I'm trying to run a second window.

After pressing a button or any other similar event.
The problem is that everywhere I looked, the second dialog was created using the Dialog function.

I was wondering is their any possible way to start one using Win32 API.
Appreciate any notes on this matter/subject. Cool | :cool:

enhzflep4-Apr-10 15:09

4-Apr-10 15:09

Hia.

Yeah, sure this is possible - in perhaps fewer lines of code than you may expect.
You'll want to declare a static HWND in the windowProcedure for the first window, or declare it as a global.
Then it's just a matter of creating the new window.

I keep a flag that tells me if the child window currently exists or not, then I act accordingly - either setting the window text, or creating the window.

if (!isChildOpen)
{
    GetWindowRect(hwndDlg, &myRect);
    imgChildHWND = CreateWindowEx(0, "picWnd", myWad.getLumpName(resNum), WS_SYSMENU|WS_CAPTION|WS_POPUP|WS_VISIBLE|WS_CHILD, myRect.right, myRect.top, 300, 300, hwndDlg, NULL, hInst, 0);
    isChildOpen = true;
}
else
    SetWindowText(imgChildHWND, myWad.getLumpName(resNum));

The child window sends a message to the controlling window whenever it is closed so I know if the window is open or not without resorting to findWindow,

i.e

case WM_CLOSE:
     PostMessage(GetParent(hwnd), IDC_CHILDCLOSING, 0, 0);

Where IDC_CHILDCLOSING is a message I've defined (#define IDC_CHILDCLOSING 1011)

Fareed Rizkalla4-Apr-10 20:53

4-Apr-10 20:53

I got it to work thank you very much.
However their is other problems.

How will I differentiate the window messages between parent and child window. Unsure | :~

For the controls, parent has a ListView child has a ComboBox.

enhzflep5-Apr-10 1:59

5-Apr-10 1:59

That's okay, it's my pleasure. Thumbs Up | :thumbsup:

Each window receives messages from its own controls, so the parent gets WM_NOTIFY and LVN_xxxxxx messages, while the child window gets WM_COMMAND and CBN_xxxxxxx messages.

The key to the scheme is that you need to treat the child window like a custom control, and remember to pass messages from it to it's parent window. You'll need to tell the parent
when something in the child window has happened - e.g a combobox event, you may also wish to send messages from the parent to the child - e.g take this array of strings and add each one to the combobox.

In short, just think of the child window as a control and remember to pass messages between the control and it's parent whenever something needs to be done(e.g fill combo with array of strings), or whenever something has happened (e.g chosen item in combobox has changed)

Fareed Rizkalla5-Apr-10 3:51

5-Apr-10 3:51

I tried to detect which window handle is reporting to WM_CLOSE.

So I set up

if (hwnd == g_hWindow)
{
//MessageBox Main Window
}
if (hwnd == g_hChildWindow)
{
//MessageBox Child Window
}

However when I close the child window the message box goes smooth and I call destroy window with the g_hCildWindow passed along the function.

But then my main window gets killed along the way after it.
Even the background color of the child window is messed up.
I did setup the PAINSTRUCT like on the default main window.
But it doesn't seem to kick in. Unsure | :~

enhzflep5-Apr-10 8:36

5-Apr-10 8:36

I still can't help but get the feeling that you're using a single WindowProcedure to handle both the Parent window and the Child window.

As far as I know, you have to use _seperate_ procs for each window. With that in mind, there is no issue when it comes to finding out who generated a message - the message automatically goes to it's own parent. Perhaps I'm missing something?

Here's about the smallest, simplest (& unfortunately perhaps the nastiest) example I can think of at 4:30am

#include <windows.h>

/*  Declare Windows procedure  */
LRESULT CALLBACK childWndProc(HWND, UINT, WPARAM, LPARAM);
LRESULT CALLBACK parentWndProc(HWND, UINT, WPARAM, LPARAM);
bool myRegClass(WNDPROC lpfnWndProc, char *szClassName, HINSTANCE hInst);
char *szParentClassName = "parentClass", *szChildClassName = "childClass";
HINSTANCE hThisInstance;
HWND parentWnd;

#define IDC_FROMPARENT   1000
#define IDC_FROMCHILD   1001


int WINAPI WinMain (HINSTANCE hCurInstance,
                     HINSTANCE hPrevInstance,
                     LPSTR lpszArgument,
                     int nCmdShow)
{
    HWND hwndParent;                          /* This is the handle for our window */
    MSG messages;                             /* Here messages to the application are saved */

    hThisInstance = hCurInstance;

    if (myRegClass(parentWndProc, szParentClassName, hThisInstance) == false)
        return 0;

    if (myRegClass(childWndProc, szChildClassName, hThisInstance) == false)
        return 0;

    /* both the classes are registered, let's create the program*/
    parentWnd = CreateWindowEx(
           0,
           szParentClassName,         /* Classname */
           "Code::Blocks Template Windows App - parent",       /* Title Text */
           WS_OVERLAPPEDWINDOW|WS_VISIBLE, /* default window */
           CW_USEDEFAULT,       /* Windows decides the position */
           CW_USEDEFAULT,       /* where the window ends up on the screen */
           544,                 /* The programs width */
           375,                 /* and height in pixels */
           HWND_DESKTOP,        /* The window is a child-window to desktop */
           NULL,                /* No menu */
           hThisInstance,       /* Program Instance handler */
           NULL                 /* No Window Creation data */
           );

    while (GetMessage (&messages, NULL, 0, 0))
    {
        TranslateMessage(&messages);
        DispatchMessage(&messages);
    }
    return messages.wParam;
}


bool myRegClass(WNDPROC lpfnWndProc, char *szClassName, HINSTANCE hInst)
{
    WNDCLASSEX wincl;        /* Data structure for the windowclass */

    /* The Window structure */
    wincl.hInstance = hInst;
    wincl.lpszClassName = szClassName;
    wincl.lpfnWndProc = lpfnWndProc;      /* This function is called by windows */
    wincl.style = CS_DBLCLKS;                 /* Catch double-clicks */
    wincl.cbSize = sizeof (WNDCLASSEX);

    /* Use default icon and mouse-pointer */
    wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION);
    wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION);
    wincl.hCursor = LoadCursor (NULL, IDC_ARROW);
    wincl.lpszMenuName = NULL;                 /* No menu */
    wincl.cbClsExtra = 0;                      /* No extra bytes after the window class */
    wincl.cbWndExtra = 0;                      /* structure or the window instance */
    /* Use Windows's default colour as the background of the window */
    wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND;

    /* Register the window class, and if it fails quit the program */
    if (RegisterClassEx (&wincl))
        return true;
    else
        return false;
}

/*  This function is called by the Windows function DispatchMessage()  */
LRESULT CALLBACK parentWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    static HWND childWnd, listBox;
    switch (message)                  /* handle the messages */
    {
        case WM_CREATE:
               childWnd = CreateWindowEx(
               0,
               szChildClassName,         /* Classname */
               "Code::Blocks Template Windows App - child",       /* Title Text */
               WS_OVERLAPPEDWINDOW|WS_VISIBLE, /* default window */
               CW_USEDEFAULT,       /* Windows decides the position */
               CW_USEDEFAULT,       /* where the window ends up on the screen */
               544/2,               /* The programs width */
               375/2,               /* and height in pixels */
               NULL,          /* The window is a child-window to desktop */
               NULL,                /* No menu */
               hThisInstance,       /* Program Instance handler */
               NULL                 /* No Window Creation data */
               );
            CreateWindowEx(0, "BUTTON", "Msg to Child", WS_VISIBLE | WS_CHILD | WS_TABSTOP | 0x00000001, 8, 8, 150, 23, hwnd, (HMENU)IDOK, hThisInstance, 0);
            return 0;
            break;

         case IDC_FROMCHILD:
            MessageBox(NULL, "Child window sent me a message", "Parent", MB_OK);
         break;

        case WM_COMMAND:
                switch(LOWORD(wParam))
                {
                 case IDOK:
                    PostMessage(childWnd, IDC_FROMPARENT, 0, 0);
                 break;
                }
            break;

        case WM_DESTROY:
            PostQuitMessage (0);       /* send a WM_QUIT to the message queue */
            break;
        default:                      /* for messages that we don't deal with */
            return DefWindowProc (hwnd, message, wParam, lParam);
    }
    return 0;
}

/*  This function is called by the Windows function DispatchMessage()  */
LRESULT CALLBACK childWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)                  /* handle the messages */
    {
        case WM_CREATE:
            CreateWindowEx(0, "BUTTON", "Msg to Parent", WS_VISIBLE | WS_CHILD | WS_TABSTOP | 0x00000001, 8, 8, 150, 23, hwnd, (HMENU)IDOK, hThisInstance, 0);
            //parentWnd = GetParent(hwnd);
            return 0;
            break;

        case WM_DESTROY:
            PostQuitMessage (0);       /* send a WM_QUIT to the message queue */
            break;

         case IDC_FROMPARENT:
            MessageBox(NULL, "Parent window sent me a message", "Child", MB_OK);
         break;

        case WM_COMMAND:
                switch(LOWORD(wParam))
                {
                 case IDOK:
                    PostMessage(parentWnd, IDC_FROMCHILD, 0, 0);
                 break;
                }
            break;

        default:                      /* for messages that we don't deal with */
            return DefWindowProc (hwnd, message, wParam, lParam);
    }
    return 0;
}

Fareed Rizkalla5-Apr-10 15:41

5-Apr-10 15:41

As I see your experienced with Win32 API, what is the effect of hInstance. I usually ignore it and pass it as NULL in CreateWindow, what problems can plague by doing so.

enhzflep6-Apr-10 2:12

6-Apr-10 2:12

I've played with it a little over the years. I think I've got vague memories of passing NULL as well, but had forgotten about the trick. It's a perfect time you should ask what may go wrong, as I see there's a thread that asks just the same question right here[^].

Fareed Rizkalla6-Apr-10 5:13

6-Apr-10 5:13

I'm the one asking. Wink | ;)

But I still can't understand a thing from the blog, I guess my mind is a bit clouded atm.

enhzflep6-Apr-10 17:42

6-Apr-10 17:42

Ah crap!

Guess I should've looked a little closer. :grin:

From what I understand of the blog, this is used as a way of differentiating between different modules (dlls) that are loaded by an app.

Imagine I had an app that loaded 3 dlls, each one of them has an icon in it with the resource ID of 1000, yet each of the icons are entirely different. In order to reliably load the desired resource, you specify the hInstance of the DLL that contains it.

Well, that's my take on it anyway.

Fareed Rizkalla5-Apr-10 16:28

5-Apr-10 16:28

I've run this code in Visual Studio 2010.
I now have a deeper aspect of WS_VISIBLE, instead of having ShowWindow.
And I can understand the buttons and each message passing a message to the other.
It's a new example of Win32 communication taking place.

I'm really thankful for your help.
My program creates a main window and some time along the way I create a second window.
Hopefully that will be through the Win7 JumpList or a Shortcut Key, currently I place the code for triggering this in the message queue to trigger it. The problem was how to start another window, while the parent is running.

Please advise on how to create a new window, while the main window is running.
Although the Win32 documentation is a clear desert, MFC is just an encapsulation of that desert.
I can't figure it out yet, although I have worked with other GUI code.
Native is the way to go, but hard to walk the path if your mapless. Suspicious | :suss: