WinApi窗口多次创建后异常销毁问题及屏幕特效C实现重构咨询

Hey, let's tackle this window destruction issue with your ScreenMelter singleton. I’ve dealt with similar WinAPI singleton window quirks before, so here’s what I’d recommend to fix those abnormal destruction problems after multiple create/destroy cycles:

The core problem here is that singletons and WinAPI windows have misaligned lifecycle rules—static singleton state often sticks around after the window is destroyed, causing conflicts when you try to recreate it. Let's fix this step by step.

1. Align Singleton Cleanup with Window Lifecycle #

Your static members (TimerID, nScreenWidth, nScreenHeight) aren't being reset when the window is destroyed, leading to invalid state on subsequent runs. Update your window procedure and add explicit cleanup to the singleton:

Update the Window Procedure (MelterProc) #

Make sure WM_DESTROY handles full resource release and state reset:

LRESULT CALLBACK MelterProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {
    switch(msg) {
        case WM_DESTROY:
            // Kill the timer first to halt any ongoing screen melting logic
            if (ScreenMelter::TimerID != 0) {
                KillTimer(hWnd, ScreenMelter::TimerID);
                ScreenMelter::TimerID = 0;
            }
            // Reset static screen dimensions (in case display resolution changed)
            ScreenMelter::nScreenWidth = 0;
            ScreenMelter::nScreenHeight = 0;
            // Mark the singleton's HWND as invalid
            ScreenMelter::GetInstance()->hWnd = NULL;
            // Post quit message only if this is your app's main window (adjust as needed)
            PostQuitMessage(0);
            break;
        // ... keep your other message handlers here ...
        default:
            return DefWindowProc(hWnd, msg, wParam, lParam);
    }
    return 0;
}

Add a Public Cleanup Method to the Singleton #

Static singletons don't get destructed until program exit, so you need an explicit way to tear down the window between runs:

class ScreenMelter {
private:
    HWND hWnd;
    static unsigned int TimerID;
    static unsigned int nScreenWidth;
    static unsigned int nScreenHeight;
    // Private singleton constructor
    ScreenMelter() : hWnd(NULL) {}
public:
    static ScreenMelter* GetInstance() {
        static ScreenMelter instance;
        return &instance;
    }

    // Explicit cleanup to destroy the window and reset state
    void Cleanup() {
        if (hWnd != NULL && IsWindow(hWnd)) {
            // Trigger the WM_DESTROY handler to clean up resources
            SendMessage(hWnd, WM_DESTROY, 0, 0);
            // Wait for the window to fully destroy (prevents race conditions)
            while (IsWindow(hWnd)) {
                MSG msg;
                PeekMessage(&msg, NULL, 0, 0, PM_REMOVE);
                TranslateMessage(&msg);
                DispatchMessage(&msg);
            }
        }
    }

    // ... your existing InitClass, CreateWindow, and effect logic methods ...
};

Call ScreenMelter::GetInstance()->Cleanup() every time you need to destroy the window before recreating it.

2. Fix Window Class Registration #

Your InitClass() method is probably trying to register the same window class every time you create a window, which causes errors on subsequent runs. Check if the class exists first:

bool InitClass() {
    WNDCLASS wc = {0};
    // Only register the class if it doesn't already exist
    if (!GetClassInfo(GetModuleHandle(NULL), L"ScreenMelterClass", &wc)) {
        wc.lpfnWndProc = MelterProc;
        wc.hInstance = GetModuleHandle(NULL);
        wc.lpszClassName = L"ScreenMelterClass";
        wc.hCursor = LoadCursor(NULL, IDC_ARROW);
        // ... set other class properties (background brush, etc.) ...
        if (!RegisterClass(&wc)) {
            // Handle registration failure (log GetLastError() if needed)
            return false;
        }
    }
    return true;
}

This eliminates "class already registered" errors when recreating the window.

3. Reset State Before Re-Creating the Window #

When you go to create a new window after destruction, make sure you start with a clean slate. Update your window creation method:

bool CreateMelterWindow() {
    Cleanup(); // Guarantee any existing window is destroyed first

    if (!InitClass()) {
        return false;
    }

    // Fetch fresh screen dimensions (don't rely on old static values)
    nScreenWidth = GetSystemMetrics(SM_CXSCREEN);
    nScreenHeight = GetSystemMetrics(SM_CYSCREEN);

    hWnd = CreateWindowEx(
        WS_EX_TOPMOST | WS_EX_LAYERED, // Common for screen effects
        L"ScreenMelterClass",
        L"Screen Melter",
        WS_POPUP,
        0, 0, nScreenWidth, nScreenHeight,
        NULL, NULL, GetModuleHandle(NULL), NULL
    );

    if (hWnd == NULL) {
        return false;
    }

    // Set up your timer and effect initialization here
    TimerID = SetTimer(hWnd, 1, 16, NULL); // ~60fps update rate
    // ... your screen snapshot and bitwise effect setup ...

    return true;
}

4. Clean Up GDI Resources (If Using Layered Windows) #

If you're using WS_EX_LAYERED for your screen effect, make sure you release any GDI objects (like DCs or bitmaps) in WM_DESTROY:

case WM_DESTROY:
    // ... existing cleanup steps ...
    // Release any screen snapshot DC/bitmap resources
    if (hWnd != NULL) {
        HDC hdc = GetDC(hWnd);
        if (hdc != NULL) ReleaseDC(hWnd, hdc);
        // Delete any memory DCs or bitmaps you created for snapshots
        // DeleteDC(hMemDC);
        // DeleteObject(hScreenBitmap);
    }
    // ... rest of WM_DESTROY handling ...

Why This Works #

• Explicit Cleanup: WinAPI doesn't automatically release all resources when a window is destroyed—you have to manually handle timers, GDI objects, and static state.
• Singleton-State Alignment: Tying the singleton's cleanup to WM_DESTROY ensures the singleton's internal state always matches the actual window state.
• Registration Safety: Checking for an existing window class prevents conflicts on repeated window creation.

Give these steps a try, and if you hit specific error codes or edge cases, let's dig into those details next!

内容的提问来源于stack exchange，提问作者Kolin Verdum