open multiple windows

Hey guys,
I'm having a bit of difficulty getting a handle on a concept I'm working on.

First let me preface by saying that I'm experienced at C programming (not C++). Mainly Console Mode (not GUI) programming. So, when it comes to Windows GUI programming I'm a complete novice.

What I would like to do is a bit different from the usual Windows GUI app, where to open a window you have a WinMain() followed up by a WinProc() for that window to handle callbacks.
The usual one for one, if you will, (one WinMain -> one window -> one WinProc).

What I'd like to do is have a generic "WinMain" type of function for registering a single WNDCLASS and a generic "WinProc" template for handling callbacks for subsequent windows opened using the already registered WNDCLASS.

I can register a WNDCLASS and using the same lpszClassName parameter and open multiple windows, using different MenuNames.
Like:

Code:

---

    wndClass.style        = CS_HREDRAW | CS_VREDRAW | CS_OWNDC;
    wndClass.lpfnWndProc  = WndProc;
    wndClass.hInstance    = hInstance;
    wndClass.hCursor      = LoadCursor(hInstance, IDC_ARROW);
    wndClass.hIcon        = LoadIcon(hInstance, IDI_APPLICATION);
    wndClass.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
    wndClass.lpszClassName = szAppName;

    RegisterClass(&wndClass)

---

followed by:

Code:

---

  hwnd1 = CreateWindow(szAppName, "MyWindow1", ...,);

---

and later, followed by:

Code:

---

  hwnd2 = CreateWindow(szAppName, "MyWindow2", ...,);

---

This displays two windows.
However, when I close either one of the windows, it closes both windows.
Clearly I'm missing something here.

The Platform SDK suggests (or at least that's my impression) that it can be done, but, I haven't found the right example to understand how to make it work.

From SDK:

Quote:

---

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.

---

Maybe someone here understands how to do this.

Usually a program will have one main window, then sub-windows are dialogs which are usually created using a resource editor. Each dialog has it's own dailogproc, so no conflicts.

In the case of multiple "top level" windows, you should register multiple classes and give each one it's own message tosser (wndproc()).

All windows in your program should share a common message dispatcher loop...

Code:

---

    // dispatch window messages
    while (GetMessage(&msg,NULL,0,0) > 0)
      if (!TranslateAccelerator(GetForegroundWindow(),AccelTable,&msg))
      if(!IsDialogMessage(GetForegroundWindow(),&msg))
        { TranslateMessage(&msg);
          DispatchMessage(&msg); }

---

It is possible --although terribly convoluted-- for two windows to share a tosser... but every case statement (eg. case: WM_CLOSE) and all functions accessed from those statements will have to be made sensitive to the window's handle. It's just a lot simpler to have two classes and two tossers.

Thanks Tater,
Perhaps my approach is wrong.
The program begins in a Console Mode window, which then opens up secondary GUI windows.
Perhaps instead of the approach I'm using, as you suggest, I should be opening Dialogs. I had not considered that.
I'll look into that.

While you can open dialogs and sub-windows from a console, this too is somewhat less than optimal behaviour... It's generally wise to do it all one way or all the other... It keeps the code simpler and you can use windows controls (which are windows in themselves) far more effectively than you will ever use a console.

You may also want to read up on the old-style MDI windows... windows opened inside a main window... but with some special logic to keep everything making sense.

May I ask what it is you're trying to get working?

You're probably calling PostQuitMessage from WM_DESTROY so that when either window is closed your whole app is terminated.

Quote:

---

Originally Posted by Steve A.

The Platform SDK suggests (or at least that's my impression) that it can be done, but, I haven't found the right example to understand how to make it work.

---

The SDK's description is a bit misleading. I'm sure they mean sub-windows in the same class... that is a parent with it's children as opposed to multiple parent windows.

Quote:

---

May I ask what it is you're trying to get working?

---

It's actually a Basic-like interpreter.
It works quite well actually, I want to add functionality to it.
It currently functions in Console Mode and I want to add Native GUI capability.

Quote:

---

You're probably calling PostQuitMessage from WM_DESTROY so that when either window is closed your whole app is terminated.

---

Yes, I didn't know there was any other way.
How else might I do that.

Keep a count of how many windows you create, when you're destroying the last one call PostQuitMessage. There's no problem with creating multiple top-level windows, here's my WindowWatcher doing it. Don't click the link in the description, it doesn't work

Quote:

---

Originally Posted by adeyblue

Keep a count of how many windows you create, when you're destroying the last one call PostQuitMessage.

---

Ahhhh!
I get it.
Btw, I was keeping count, but, for another reason. Now it makes sense.
Huh! :cool:

Quote:

---

Originally Posted by Steve A.

Ahhhh!
I get it.
Btw, I was keeping count, but, for another reason. Now it makes sense.
Huh! :cool:

---

Window Watcher is pretty cool...

But it's not the same as having multiple top level windows open *in the same application*...

In the demo video, he has multiple applications open --MS Word, Browser, Media Player-- being monitored by yet another application (his)... Thus everything is running it's own classes and tossers.

Take the example of a simple message... WM_SIZE... Ok, now you have 3 windows open with different controls in each window. If you resize one of them the system sends WM_SIZE, now it's not going to know which window to redraw... To fix this you have to track the foreground window and make WM_SIZE sensitive to the window handle... The same will apply to WM_CLOSE, WM_PAINT, WM_CHAR, etc. And that's a lot of complex coding that just begs errors.

On the other hand making separate classes for each top level window and working them off separate tossers... no problem, the dispatcher I showed you earlier will sort that all out for you automatically.

It's also likely that will turn into a bigger fiasco when you have client programmers writing their own code, making their own windows and dialogs, so unless you're planning some serious obfuscation of the underlying mechanisms, it's going to be a real pain for both you and them.

Quote:

---

Originally Posted by Steve A.

Yes, I didn't know there was any other way.
How else might I do that.

---

There really isn't any other way. Check the SDK... the shut down for an app is to catch WM_CLOSE, do whatever you need to save data and shut down processes, then when WM_CLOSE returns the system immediately sends WM_DESTROY where you are supposed to shut down the dispatcher, which then falls through to WinMain() and causes the application to exit.

You can sensitize that so only one of your windows can cause a program exit, but it's going to depend on the application which window that is... you can't always exit when the last window is closed... you want to exit when the *main* window is closed.

Silly as it sounds... there are rules about this, set down my Microsoft as a means of providing a uniform end user experience in Windows.

Quote:

---

Originally Posted by CommonTater

In the demo video, he has multiple applications open --MS Word, Browser, Media Player-- being monitored by yet another application (his)... Thus everything is running it's own classes and tossers.

---

WindowWatcher has one message pump, one window class and one wndproc, and the demo is running two top-level windows (that's top-level in the WinAPI sense, unowned desktop parented windows). That's what I meant.

If you and the OP meant something like MDI then, sshh, I'm learning how to spam.

Quote:

---

There really isn't any other way.

---

I don't know. A thread timer that periodically calls EnumThreadWindows and exits the app if it finds none would work. You could also use a thread per window approach, with the main thread waiting for them all to exit. You wouldn't even have to remove the PostQuitMessage with that approach. But yeah, that's just being pedantic, nobody would ever do any of that, would they? We should start an experiment with the most contrived code possible and see how many copy 'n paste people run with it

Quote:

---

Originally Posted by adeyblue

WindowWatcher has one message pump, one window class and one wndproc, and the demo is running two top-level windows (that's top-level in the WinAPI sense, unowned desktop parented windows). That's what I meant.

---

That was not apparent from the video...

Hey Guys,
okay, still learning...,

let's assume I open a single gui window and draw some text on it via WM_PAINT, (which is in my wndproc() function), like below:

Code:

---

        case WM_PAINT:
            BeginPaint(hwnd, &ps);

            GetClientRect(hwnd, &rect);
            DrawText(hdc, "Hello World!.", -1, &rect, DT_SINGLELINE | DT_CENTER | DT_VCENTER);

            EndPaint(hwnd, &ps);
            break;

---

then, else where, (in another function) I issue a gdi line-draw command like so:

Code:

---

void DrawLine(HWND hwnd)
{
    int x1=50, y1=50, x2=50, y2=150;
    HDC  myhDC;

    myhDC = GetDC(hwnd);

    MoveToEx(myhDC, x1, y1, NULL);
    LineTo(myhDC, x2, y2);

    ReleaseDC(hwnd, myhDC);
}

---

In the center of my window I have text that reads "Hello World!" and near the upper left corner, I have a 100 pixels long line.
I can drag my window all over the screen and my two objects remain in tact.
However, if I cover my window with another window, only the text remains when I toggle back to my window. The gdi line is no longer displayed.

How would I get windows to redraw the entire contents of the window, including the gdi line I have drawn ?
(without putting the line-draw routine inside of WM_PAINT, that is).

Quote:

---

Originally Posted by Steve A.

How would I get windows to redraw the entire contents of the window, including the gdi line I have drawn ?
(without putting the line-draw routine inside of WM_PAINT, that is).

---

Any drawing done outside the paint msg will only 'last' (be visible) until the next WM_PAINT msg.

The easiest way is to put the drawing code inside the WM_PAINT. Problem is that this will often slow down the painting and can cause flicker/shearing of the screen (unless the drawing is VERY simple).


Otherwise you need to 'double buffer' the drawing. This is creating a copy of the screen in memory and drawing this copy in response to a WM_PAINT msg.

When the app starts;
Create a DC compatible to the screen (CreateCompatibleDC) [lets call it memDC]
Create a bitmap compatible to the screen (CreateCompatibleBitmap) and the same size as the app window or PC screen resolution (see below).
SelectObject the bitmap into the memDC, saving the default bmp that is 'pushed' out.
Clean up any GDI objects (ie release any GetDC()'s).

When the screen changes;
Draw the changes to the memDC
Call for a paint msg (InvalidateRect() followed by UpdateWindow() )

When you get a paint msg
BitBlt the memDC to the the DC from the PAINTSTRUCT, using the rect from the PAINTSTRUCT (so we redraw the minimum amount and do all drawing in one call)

When the app changes size;
Clean up the DC and create a new one the correct size (OR create the compatible bmp the same size as the PC screen in the first place, instead of the app window size)
redraw to the new size
call for a paint

When your app closes;
SelectObject the default bmp back into the memDC
DeleteDC the memDC
DeleteObject the compatible bmp

I have posted code before if you need (try a search for 'double buffering').

Thanks for the detailed information novacain.
Very instructive.

Steve

Well, I've taken your advise and read-up on "double buffering" as you suggested.
From what I've read so far, it seems to be a good possibility that could work.
In fact, I have no doubt that is the way to go. Now I just have to figure a way of implementing it in my situation. Should be do-able.

Quote:

---

Originally Posted by novacain

Create a DC compatible to the screen (CreateCompatibleDC)
Create a bitmap compatible to the screen (CreateCompatibleBitmap) .
SelectObject the bitmap into the memDC, saving the default bmp that is 'pushed' out.
Clean up any GDI objects (ie release any GetDC()'s).

---

Okay, borrowing from older posts, I have recreated the code I need.

Code:

---

    HdcWindow = BeginPaint(hwnd, &ps);
    HdcBuffer = CreateCompatibleDC(HdcWindow);
    DoubleBuffer = CreateCompatibleBitmap(HdcWindow, MYWIDTH, MYHEIGHT);
    OldBuffer = (HBITMAP)SelectObject(HdcBuffer, DoubleBuffer);

    FillRect(HdcBuffer, &rect, (HBRUSH)GetStockObject(WHITE_BRUSH));
    HdcBitmap = CreateCompatibleDC(HdcWindow);

---

For the most part it seems to be working.
I have added this to WM_PAINT:

Code:

---

    case WM_PAINT:
        BitBlt(HdcWindow, 0, 0, MYWIDTH, MYHEIGHT, HdcBuffer, 0, 0, SRCCOPY);
        break;

---

the only problem is, that, for some reason WM_PAINT goes into an endless loop.
I found that if I add this:

Code:

---

    case WM_PAINT:
        hdc = BeginPaint(hwnd, &ps);
        EndPaint(hwnd, &ps);
        BitBlt(HdcWindow, 0, 0, MYWIDTH, MYHEIGHT, HdcBuffer, 0, 0, SRCCOPY);
        break;

---

it works just fine. I don't get it...

Quote:

---

Draw the changes to the memDC
Call for a paint msg (InvalidateRect() followed by UpdateWindow() )

---

Well, when the only thing I draw to my buffer is a line, like this:

Code:

---

void DrawLine(HWND hwnd)
{
    HDC myhDC = HdcBuffer;
    int x = 50, y = 50;

    MoveToEx(myhDC, x, y, NULL);
    LineTo(myhDC, x + 100, y);

    InvalidateRect(hwnd, &glrect, FALSE);
    UpdateWindow(hwnd);
}

---

this alone does not seem to work.
However, if I add a BitBlt() at the end, like this:

Code:

---

    InvalidateRect(hwnd, &glrect, FALSE);
    UpdateWindow(hwnd);

    BitBlt(HdcWindow, 0, 0, MYWIDTH, MYHEIGHT, myhDC, 0, 0, SRCCOPY);
}

---

then it works.
Of course, I'm forceing it to work. I can live with this.

What I think I need to fix, though, is the WM_PAINT thing.
Any suggestions ?

You can not call BeginPaint() except in response to a WM_PAINT msg.

You only need one buffer for this level of drawing, looks like you have one of my two back buffer systems, used for very complex drawing.

Code:

---

//WM_CREATE or WM_INITDIALOG
    //get the app windows DC (or use NULL for screen DC)
    HDC HdcWindow= GetDC(hwnd);
    //create comp DC and BMP
    HdcBuffer = CreateCompatibleDC(HdcWindow);  //global scope HDC
    DoubleBuffer = CreateCompatibleBitmap(HdcBuffer , MYWIDTH, MYHEIGHT); //global scope BMP

    //select in BMP, catching 1x1 monochrome default BMP
    OldBuffer = (HBITMAP)SelectObject(HdcBuffer, DoubleBuffer); //global scope BMP

    //clear screen
    FillRect(HdcBuffer, &rect, (HBRUSH)GetStockObject(WHITE_BRUSH));
    //clean up GDI
    ReleaseDC(HdcWindow);

---

Code:

---

//copy the minimum amount from our global HDC (HdcBuffer) to the screen HDC

    case WM_PAINT:
        BeginPaint(hwnd, &ps);
        BitBlt(ps.hdc, //can use the HDC in the PAINTSTRUCT or use the returned HDC from BeginPaint()
                ps.rect.left,  ps.rect.top,  //draw only the invalidated rect not the whole screen
                ps.rect.right - ps.rect.left,  ps.rect.bottom -  ps.rect.top, 
                HdcBuffer, 0, 0, SRCCOPY);
        EndPaint(hwnd);
        break;

---

Make sure this code is actually called and use the actual DC, not a copy of it.

Code:

---

//draw any changes to our global HDC (HdcBuffer)
void DrawLine(HWND hwnd)
{
    //clear HDC with FillRect() if we need to erase previous lines etc

    //draw
    int x = 50, y = 50;
   
    MoveToEx(HdcBuffer, x, y, NULL);
    LineTo(HdcBuffer, x + 100, y);

    //for ease, repaint the whole screen
    rect ClientRect = {0,0,0,0};
    GetClientRect(hwnd, &ClientRect);
    InvalidateRect(hwnd, &ClientRect, FALSE);
    UpdateWindow(hwnd);
}

---

Don't forget to clean up on WM_CLOSE (or similar).

NOTE: written from memory, not compiled

Hey novacain,
this latest post really explained a lot for me.
Being a complete noob to GUI programming, I often don't know what goes where, when or why.

With only minor mods I was able to take your latest code examples and plug it in to the correct slots. It works beautifully. I can't believe how well it works.
Pretty slick.

I am reminded that double buffering is a lot like pageing that we used to do back in the old DOS (QuickBasic) days. Where you drew directly on display adapter memory, then flipped pages.

I'll be testing this out in my interpreter to see if there are any breaking points.

Thanks.

Hey novacain,
Ok, I've been playing around a lot with the double buffer and it really fits the bill nicely.

I have discovered, however, that if I resize the visible client area, progamatically or otherwise, it of course has no effect on the back-buffer, which I'm drawing to.
i.e.
1) let's say my front client area is one fourth the visible display size, (beginning in the upper left), as is my back-buffer,
2) I paint my entire buffer area blue, the client rectangle gets repainted to blue,
3) now, I issue a command to resize the client area to MAXIMIZE,
it does and it gets repainted: ShowWindow(hwnd, SW_MAXIMIZE);

4) now, I have a blue rectangle on an otherwise white screen.

Hmmm ...!

How do I make changes to the back-buffer, in keeping with changes to the client area ?

You need to process the WM_SIZE msgs.

I suggest you create the buffers the same size as the entire screen when the app starts, so you do not have to re-create them if the client area gats bigger.

When you get a WM_SIZE msg find the new client area, redraw the screen and call for a paint.

Quote:

---

Originally Posted by novacain

You need to process the WM_SIZE msgs.

I suggest you create the buffers the same size as the entire screen when the app starts, so you do not have to re-create them if the client area gats bigger.

When you get a WM_SIZE msg find the new client area, redraw the screen and call for a paint.

---

Okay,...
so the buffer (in the background) starts out at full screen size, ... to begin with. (?)
Okay, I'll give that a try.
Thanks.

Hey novacain & guys,
here is what my double buffer setup looks like:

Code:

---

        case WM_CREATE:
            bufWIDTH = cxScreen;  // maximum size
            bufHEIGHT = cyScreen;  // maximum size

            glrect.left = 0;
            glrect.top = 0;
            glrect.right = bufWIDTH;
            glrect.bottom = bufHEIGHT;

            HdcWindow = GetDC(hwnd);

            HdcBuffer = CreateCompatibleDC(HdcWindow);
            DoubleBuffer = CreateCompatibleBitmap(HdcWindow, bufWIDTH, bufHEIGHT);

            OldBuffer = (HBITMAP)SelectObject(HdcBuffer, DoubleBuffer);

            FillRect(HdcBuffer, &glrect, (HBRUSH)GetStockObject(WHITE_BRUSH));
            ReleaseDC(hwnd, HdcWindow);
            break;

        case WM_PAINT:
            BeginPaint(hwnd, &glps);
            BitBlt(glps.hdc, 0, 0, myWIDTH, myHEIGHT, HdcBuffer, 0, 0, SRCCOPY);

            EndPaint(hwnd, &glps);
            break;

        case WM_SIZE:
            myWIDTH = LOWORD(lParam);
            myHEIGHT = HIWORD(lParam);

            break;

---

This basic setup, by making the buffer the full screen size, now seems to be working when I resize the screen.
Pertaining to resizing my foreground screen, is there anything else you recommend that I should be adding to WM_SIZE ?
Thanks.

If you create the buffer (specifically the bitmap inside it) smaller than the screen, and the user maximaised the app, you would have to destroy the current bitmap and create a bigger one. This is slow while the app is trying to redraw the screen.

So I create the buffer the same size as the screen at start.

When the app changes size you need to redraw any part of the screen that is dependent on/proportional to the size.

In your example you would call a method to fill the new client area with blue rectangle.

So you need to add some code that calls your drawing routines and pass in the new size. The drawing routine will redraw based on the new size and call for a paint.

Quote:

---

Originally Posted by novacain

-snip-
So you need to add some code that calls your drawing routines and pass in the new size. The drawing routine will redraw based on the new size and call for a paint.

---

I have followed your advise and I am very pleased with the results.
Thanks novacain.