[C++] de processmessages deel 2

[Verwijderd]

Goeiemorgen.

Ik heb dit probleem al eerder voorgelegd maar wil jullie hulp toch nog 1 keer vragen.

het gaat om de regel Application->Procesmessages();

de situatie:

ik stuur met mijn programma een ander programma aan via windowmessaging en kijk of het andere programma nog leeft door middel van een doorgelusde compoort.

de aansturing begint op tijdstip: 15:28:53.30
het gaat goed tot tijdstip: 19:19:04.80

in deze tijd heeft het programma 588 testen uitgevoerd. in zo'n test wordt een verschillend aantal keer de regel application->procesmessages(); gebruikt. verschillend van 0 tot +/- 20.

ineens gaat de application->procesmessage(); regel heel veel tijd in beslag nemen.

mijn vraag is: WAAROM?

hieronder staat een stukje uit mijn logfile:

code:

Application ProcessMessages started19:19:04.80
Application ProcessMessages ended19:19:04.81
Proces D ended
Delay started19:19:05.45
Delay ended19:19:08.47
Proces F started
Get info compport19:19:08.49
writed to port19:19:09.03
readed from port19:19:09.07
Proces F ended
Proces G started
Proces G ended
(588    ) #MATHEMATICAL                  #C:\StresstestProjects\MyProject\Tests\MATHEMATICAL\AddAutoOnMoveTraces
19:19:09.11
Proces A ended
Proces B started
Delay started19:19:09.15
Delay ended19:19:12.16
Proces B ended
Proces A Started
(589    ) #AVSB                          #C:\StresstestProjects\MyProject\Tests\AVSB\MultiplyAutoOffTryButtonbar
19:19:12.18
Proces C started
Proces C ended
Proces D started
Proces K started19:19:12.23
Proces K ended19:19:12.43
Application ProcessMessages started19:19:12.46
Application ProcessMessages ended 6:29:02.73
Proces D ended
Proces C started

weten jullie misschien waarom de computer INEENS 11 uur nodig heeft om de regel application->processmessage(); af te handelen?

.modbreak: layoutverneuking weggehaald

[ Voor 12% gewijzigd door .oisyn op 13-01-2003 16:52 ]

[Soultaker]

Omdat je een vertraging van 11 uur hebt ingeprogrammeerd, na kwart over zeven 's avonds? Omdat je je computer tussen 19:19:13 en 6:29:01 op standby had staan?

Hoe verwacht je dat ik (of wie dan ook) dit weet, zonder concrete code of informatie wat er in je ProcessMessages functie gebeurt (of hoort te gebeuren)? Wat is dat ueberhaupt voor functie? Iets wat MFC of Borland C++ Builder aanbied? Dan blijft nog steeds de vraag: wat moet daarin gebeuren?

[ Voor 3% gewijzigd door Soultaker op 13-01-2003 09:48 ]

[LordLarry]

Je hebt code in een OnMessage of andere events die dan aangeroepen worden? Componenten krijgen messages binnen en doen er heel lang over om hier actie op te ondernemen?

Als je de code bekijkt van ProcessMessages zie je al dat ie al kijkt of er wat in de message queue staat. Zoniet, dan returned ProcessMessages meteen. Profile eens wat meer of herschrijf die code voor in een thread.

[Verwijderd]

Owke Application->ProcessMessages(); hoort ervoor te zorgen dat alle messages voor de applicatie afgehandeld worden.

bijvoorbeeld:
als er op een knop in het programma gedrukt is dan wordt deze knop ingedrukt op het moment dat de regel application->Processmessages(); aangeroepen wordt.

Op zich hoort deze regel dus meteen te returnen want de applicatie is vrijdag avond gestart voordat ik naar huis ging en niemand heeft daar aangezeten tot maandag morgen. Dus zouden er ook geen muishandelinge of wat dan ook uitgevoerd zijn. Ik werk hier op een WINNT 4.0 systeem en toen ik naar huis gegaan ben heb ik het systeem gelocked.

De application->Processmessage zat eerst heel vaak in de code maar ik heb alles weggehaald en eentje overgelaten (als ik de laatste ook weghaal kan ik geen knoppen meer drukken en dus ook de applicatie niet afsluiten).

Het rare van dit alles is dat het dus 4 uur lang gewoon goed gaat en van het ene op het andere moment 11 uur gaat duren.

Het enige stuk code waar de application->processmessages(); regel zich bevint staat hieronder

code:

UINT m_keyCodeMsgReleas = RegisterWindowMessage("UniqueEkKeyCodeReleas");
        UINT m_keyCodeMsgClick = RegisterWindowMessage("UniqueEkKeyCodeReleas");
        UINT m_keyCodeMsgPress = RegisterWindowMessage("UniqueEkKeyCodeReleas");

        AnsiString tijd = LogForm->GetTime();
        WriteLineToOutput("Proces K started" +tijd);
        //Application->ProcessMessages();
        if(theAction == "ACTION_UP")
        {
                ::PostMessage(HWND_BROADCAST, m_keyCodeMsgReleas, row, column);
        }
        else if(theAction == "ACTION_CLICK")
        {
                ::PostMessage(HWND_BROADCAST, m_keyCodeMsgClick, row, column);
        }
        else if(theAction == "ACTION_DOWN")
        {
                ::PostMessage(HWND_BROADCAST, m_keyCodeMsgPress, row, column);
        }
        Sleep(200);
        tijd = LogForm->GetTime();
        WriteLineToOutput("Proces K ended" +tijd);
        tijd = LogForm->GetTime();
        WriteLineToOutput("Application ProcessMessages started" +tijd);
        Application->ProcessMessages();

Ik heb geen methode's voor OnMessage.

Ik ben nu bezig om te testen met PeekMessage en bijbehorende DispatchMessage.

Hier vinden ze het ook een heel erg raar probleem en weten het ook niet.

Daarom wil ik eigenlijk de volgende vraag stellen.

Is er een reden?
zoja is er een oplossing?
zonee is er een alternatieve oplossing?

[LordLarry]

Verwijderd schreef op 13 januari 2003 @ 10:10:
Ik heb geen methode's voor OnMessage.

Maar de componenten in je applicatie reageren wel op messages. Waaronder, neem ik aan, de postmessages die jij zelf doet in die loop. Misschien zit er in die code wel een foutje?

Ik ben nu bezig om te testen met PeekMessage en bijbehorende DispatchMessage.

Dat doet ProcessMessages al. Kan jij het beter dan?

Is er een reden?
zoja is er een oplossing?
zonee is er een alternatieve oplossing?

Geef aub de indruk dat je alle reacties op je post ook leest. Daar staan alle antwoorden in die wij kunnen geven met deze karige informatie.

Als zeer onwaarschijnlijke mogelijkheid kan ik me nog voorstellen dat windows of je cpu in een sluimerstand raakt als je m zolang niet aanraakt. Of je screensaver en een ander process start op die tijd.

[Verwijderd]

ik heb alle reactie's gelezen maar snap af en toe niet wat er bedoeld wordt. sorry daarvoor!

ik ben aan het testen of het misschien om de een andere reden met peekmessage en dispatch message beter gaat. zou niet weten waarom maar we zijn hier een beetje wanhopig dus waarom niet.

De mogelijk dat windows of CPU in sluimerstand raakt zou misschien kunnen maar dan lijkt het mij dat wanneer ik weer met de computer aan de gang ga dat deze uit die sluimerstand moeten komen en dat dan de applicatie ook weer verder draait. Dit is echter ook niet het geval.

Maar ik vermoed dat ook hier niemand een reden kan geven waarom de procesmessages ineens 11 uur erover doen. missschien door mijn gebrekkige info. maar goed dan is dat mijn eigen schuld in ieder geval weer bedankt voor het meedenken.

[Olaf van der Spek]

Kun je de app niet debuggen dan? Start de app in de debugger, ga slapen en als je wakker wordt kijk je of het probleem is opgetreden. Zo ja, dan break je het programma en kijk je wat er aan de hand is.

[Verwijderd]

dat heb ik gedaan! dan zit hij in de regel van de application->processmessage(); daar kun je echter geen step into bij doen. dan krijg je niks te zien.

[LordLarry]

Dan moet je het vinkje 'Use Debug DCUs' aandoen in je project. En het 'Debug Source' path even vullen zodat ie die .pas kan vinden.

[Verwijderd]

sorry maar hier snap ik niks van! ik werk in borland C++ builder en kan daar niks over vinden.

[Creepy]

Project -> Options -> Compiler -> Use Debug DCU's (tenminste, daar zittie bij Delphi)

[Olaf van der Spek]

Verwijderd schreef op 13 January 2003 @ 15:18:
dat heb ik gedaan! dan zit hij in de regel van de application->processmessage(); daar kun je echter geen step into bij doen. dan krijg je niks te zien.

Niks of assembly?

[curry684]

Verwijderd schreef op 13 January 2003 @ 09:02:
Ik heb dit probleem al eerder voorgelegd maar wil jullie hulp toch nog 1 keer vragen.

De vorige 3 keer luisterde je ook al niet idd. Ik geef het op met jou.

Ow en ik gok dat je computer idd op standby sprong rond 19:19.

* curry684 signing off out of everything related to flykiller20.

[LordLarry]

Verwijderd schreef op 13 januari 2003 @ 15:54:
sorry maar hier snap ik niks van! ik werk in borland C++ builder en kan daar niks over vinden.

Sorry, ik had Delphi in mn hoofd. Ik heb niet zo heel veel verstand van BCB, maar ik denk dat Linker -> Use debug libs de equivalent is.

[hobbit_be]

lijkt me geen eenvoudig geval... kun je eerst niet zonder compoorte gevallen effe testten wat ie doet? en waarom geen socket based / network keepalive... en is die ProcessMessages lijkt me Borland only niet? Nou ja je moet dan ook niet Borland C++ gebruiken voor te proggen onder windows he... die compiler is bekent (de nieuwe versies) vanwege fouten. Compile (als dat al kan) met Intel/Vc++ comp en kijk of ie het dan nog doet. wel rot dat 4 uur moet wachten totdat je iets weet. Het zou wel kunnen dat als die process messages een while loop is en dat ie totaal geen messages ontvangt - dan zit ie vast natuurlijk (totdat er iets gebeurt). en een sleep in het midden van je ThreadCode is niet proper - zet die van achter...

[LordLarry]

offtopic:
[quote]hobbit_be schreef op 13 January 2003 @ 20:05:
en is die ProcessMessages lijkt me Borland only niet? Nou ja je moet dan ook niet Borland C++ gebruiken voor te proggen onder windows he... die compiler is bekent (de nieuwe versies) vanwege fouten[/quote]

Dit hoor ik nu al enkele malen hier, maar in het veld heb ik daar nog nooit wat over gehoord. Kan iemand mij hier wat meer over vertellen? Internetpagina's misschien?

[Verwijderd]

het is opgelost door alle applications->Processmessages(); regels te vervangen door een CheckMessages(); methode.

code:

CheckMessage()
{
           MSG    lpMsg;

           if(PeekMessage(&lpMsg, NULL, 0, 600, PM_REMOVE))
           {
                     TranslateMessage(&lpMsg);
                     DispatchMessage(&lpMsg);
           }
}

weet echter niet waarom het fout gaat met de application->processmessage();
weer geen probleem opgelost.

[ Voor 6% gewijzigd door Verwijderd op 14-01-2003 10:42 ]

[LordLarry]

Het verschil is dat je nu maar 1 message per keer afhandel en met ProcessMessages alles tot de queue leeg is. Ook wordt het event OnMessage aangeroepen als er aan een aantal condities voldaan wordt.

Misschien wordt er door het afhandelen van een bepaalde message steeds weer een nieuwe message gestuurd en zo blijft het in die loop hangen.

[hobbit_be]

die problemen met de compiler van C++ waren er al vanaf de eerste versie met de IDE in windows (die borland dos compiler was erg goed daarentegen). Soms genereert de compiler simpelweg foute code. op industrievlak wordt borland (C++, niets over Delphi) al lang niet meer serieus genomen. Maar hij is wel goedkoop en wordt vaak gratis aangeboden aan studenten . Kun je er niet achter komen wat de code van ProcessMessages is? wat ik niet snap is dat die CheckMessage slechts een keer een message gaat afhalen en dan loopt ie weer verder. dus ik neem aan dat die in een thread zit?

[curry684]

hobbit_be schreef op 14 januari 2003 @ 16:00:
Kun je er niet achter komen wat de code van ProcessMessages is? wat ik niet snap is dat die CheckMessage slechts een keer een message gaat afhalen en dan loopt ie weer verder. dus ik neem aan dat die in een thread zit?

Ik heb 'm in dit op slot gezet topic al gewezen op het feit dat ik al had uitgelegd hoe ProcessMessages werkt. Die gast is zo hardhoors als wat.

[D2k]

en een nieuw topic openen nadat de vorige is gesloten is not done
tips genoeg