[win32/C++] Programma sluit niet af

[Verwijderd]

Ik heb dus een proggy gescheven die de Windows API gebruikt,
ook de WM_CLOSE messages goed en zo.
Bij mij sluit hij normaal af, maar bij twee vrienden van mij is hij niet af te sluiten.
Ik kan me vaag iets herrinneren dat bij Windows XP de message nogmaals vertaald moet worden, maar ik kan er niets over vinden.

Is iemand die hier meer van weet?

bvd,

[.oisyn]

Hoe reageer je dan op die WM_CLOSE? En hoe ziet je message pump eruit? Laat je code eens zien

[ Voor 24% gewijzigd door .oisyn op 14-01-2004 17:28 ]

[Verwijderd]

dit is de messageloop

code:

        if(PeekMessage(&msg,wHandle,0,0,PM_REMOVE))
        {
            TranslateMessage(&msg);

            DispatchMessage(&msg);
        }

edit: dit staat natuurlijk in een loop ^^

en dit is de WinProc:

code:

LRESULT CALLBACK wP(HWND windowHandle, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch(message)
    {
    case WM_CLOSE:
        {
            PostQuitMessage(0);
            return 0;
        }
    
    case WM_KEYDOWN:
        {
            keys[wParam] = true;
            return 0;
        }
    }
    return DefWindowProc(windowHandle,message,wParam,lParam);
}

maar het rare is dat hij bij mij, en op windows 98 systemen wel gewoon afsluiten.

als je de gehele code wilt zien moet je het maar even aangeven.

bvd

[ Voor 5% gewijzigd door Verwijderd op 14-01-2004 17:34 ]

[.oisyn]

wat is de conditie van die loop waarin je PeekMessage aanroept? PostQuitMessage () zal natuurlijk een WM_QUIT genereren, test je daar wel op?

En ik weet niet of je wat anders zinnigs in je loop doet, maar zo niet dan kun je er natuurlijk beter een while (GetMessage (...)) { translate; dispatch; } van maken

[Verwijderd]

.oisyn schreef op 14 januari 2004 @ 17:42:
wat is de conditie van die loop waarin je PeekMessage aanroept? PostQuitMessage () zal natuurlijk een WM_QUIT genereren, test je daar wel op?

En ik weet niet of je wat anders zinnigs in je loop doet, maar zo niet dan kun je er natuurlijk beter een while (GetMessage (...)) { translate; dispatch; } van maken

C++:

    MSG msg;

    do
    {
        if(PeekMessage(&msg,wHandle,0,0,PM_REMOVE))
        {
            TranslateMessage(&msg);

            DispatchMessage(&msg);
        }
        if(keys[VK_ESCAPE])
        {
            SendMessage(wHandle,WM_CLOSE,0,0);
            keys[VK_ESCAPE] = false;
        }
        if(keys[VK_RIGHT])
        {
            SendMessage(winamp,WM_COMMAND,40048,0);
            keys[VK_RIGHT] = false;
        }
        if(keys[VK_LEFT])
        {
            SendMessage(winamp,WM_COMMAND,40044,0);
            keys[VK_LEFT] = false;
        }

        GetWindowText(winamp,title,sizeof(title));
        SetWindowText(wHandle,title);

    } while(msg.message != WM_QUIT);

dit is de loop zelf.
Ik zal dat voorbeeld van jou even proberen zo.
bedankt

[farlane]

C++:

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

[.oisyn]

farlane: waarom? Op het kruisje drukken geeft een WM_CLOSE, en die geeft een WM_QUIT. Moet dus gewoon normaal werken.

[farlane]

.oisyn schreef op 14 januari 2004 @ 20:50:
farlane: waarom? Op het kruisje drukken geeft een WM_CLOSE, en die geeft een WM_QUIT. Moet dus gewoon normaal werken.

Hm, idd. Was in de veronderstelling dat je op een WM_DESTROY moest quitten, maar op WM_CLOSE doet ie het ook. ( Je krijgt dan geen WM_DESTROY meer trouwens )

[curry684]

Misschien een gek idee of zo, maar vind je het echt tactisch dat je programma permanent 100% CPU-tijd trekt? Je yield nergens en zo....

[farlane]

curry684 schreef op 15 januari 2004 @ 10:22:
Misschien een gek idee of zo, maar vind je het echt tactisch dat je programma permanent 100% CPU-tijd trekt? Je yield nergens en zo....

Dat doet PeekMessage toch voor je ?

[SWfreak]

farlane schreef op 15 januari 2004 @ 12:24:
[...]


Dat doet PeekMessage toch voor je ?

Nope, PeekMessage returnt altijd meteen, of er nu wel of geen message is...

[curry684]

farlane schreef op 15 januari 2004 @ 12:24:
[...]
Dat doet PeekMessage toch voor je ?

GetMessage yield alleen, indien er geen messages staan. Zijn message loop yield nooit en zal dus zeker onder 98 het hele systeem starven.

[Verwijderd]

curry684 schreef op 15 januari 2004 @ 10:22:
Misschien een gek idee of zo, maar vind je het echt tactisch dat je programma permanent 100% CPU-tijd trekt? Je yield nergens en zo....

dit is eigenlijk een goede veronderstelling
had ik zelf nog niet aan gedacht.

de mensen bij wie hij niet af wil sluiten zeggen ook dat het programma "vastloopt"

dus ik moet gewoon die loop een paar keer per seconde laten lopen neem ik aan.

ik ga het meteen proberen.

[curry684]

Ik snap je message pump sowieso niet... waarom gebruik je geen standaard GetMsg/Translate/Dispatch loop waarin je WM_KEYDOWN en WM_PAINT correct afhandelt ipv die troep hier op een volstrekt foute plaats af te handelen?

[edit]
Het probleem van het vastlopen is trouwens wel duidelijk, je processed maximaal 1 message per iteratie, en SetWindowText produceert er minimaal 1 (WM_PAINT). Met de muis bewegen zorgt er dus al voor dat de message queue binnen de kortste keren overloopt.

[ Voor 39% gewijzigd door curry684 op 15-01-2004 13:47 ]

[.oisyn]

curry: wordt de WM_PAINT niet direct aan de windowproc gegeven ipv eerst door de messagequeue te gaan? UpdateWindow () en RedrawWindow doen dat iig wel (en bovendien is het volgens mij een WM_NCPAINT)

Ik zat idd ook te denken aan het overlopen van de queue door SetWindowText, maar ik zie zo snel niet waardoor. Het is natuurlijk wel gewoon lompe code, zo elke iteratie de windowtext aanpassen

[Verwijderd]

Een minimale message loop hoort er zo uit te zien...

code:

BOOL bRet;

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{ 
    if (bRet == -1)
    {
        // handle the error and possibly exit
    }
    else
    {
        TranslateMessage(&msg); 
        DispatchMessage(&msg); 
    }
}

De rest van de troep moet je in je window procedure afhandelen.

[curry684]

.oisyn schreef op 15 januari 2004 @ 15:46:
curry: wordt de WM_PAINT niet direct aan de windowproc gegeven ipv eerst door de messagequeue te gaan? UpdateWindow () en RedrawWindow doen dat iig wel (en bovendien is het volgens mij een WM_NCPAINT)

Ik zat idd ook te denken aan het overlopen van de queue door SetWindowText, maar ik zie zo snel niet waardoor. Het is natuurlijk wel gewoon lompe code, zo elke iteratie de windowtext aanpassen

WM_PAINT en WM_NCPAINT gaan wel via de queue, maar op een speciale manier: er kan nooit meer dan 1 WM_*PAINT message in de queue staan (de eerste), en die trekt met BeginPaint alle pending rectangles open.

UpdateWindow en RedrawWindow zijn functies die juist bedoeld zijn om respectievelijk alle pending paints af te handelen en een immediate repaint te doen, en bypassen dus idd de message queue (en flushen eventueel aanwezige WM_*PAINT's).

SetWindowText is alleen een NCPAINT indien wHandle een overlapped window is, als wHandle een button of edit control is een gewone PAINT

En die queue loopt dus gewoon over, je krijgt iedere iteratie een WM_PAINT plus eventuele inputmessages. Als je dus tussen PeekMessage en SetWindowText erin slaagt om 2 toetsen in te drukken zal de bijbehorende WM_KEYDOWN van de 2e dus al nooit aankomen, en een WM_CHAR zal al helemaal nooit in de queue komen schat ik zo.