[W2k, C++ Builder, Handle] hangende app

[TimmeStein]

Ik krijg steeds rare lock-ups met mijn code. Ik zal het eventjes schematisch en kort samenvatten.

Ik heb een form met daarop een paar radiobuttons om de Com poort te selecteren. Kep een globale variabele die hComm (van comhandler) heet. Dit initialiseer ik met NUL (handle hComm = NULL).

Nu zeg ik, op event radiobutton1click:

code:

        if (hComm != NULL)
        {
                ReadThread->Terminate();
                Sleep(250);
                PurgeComm(hComm, PURGE_RXABORT);
                SetCommTimeouts(hComm, &ctmoOld);
                CloseHandle(hComm);
                hComm = NULL;
        }

        DCB dcbCommPort;

        // Create ComHandler
        hComm = CreateFile("COM1",
                           GENERIC_READ | GENERIC_WRITE,
                           0,
                           0,
                           OPEN_EXISTING,
                           0,
                           0);

// Error?
        if(hComm == INVALID_HANDLE_VALUE)
        {
                MainForm->Memo1->Text = GetLastError();
        }
// Timeout variables
        GetCommTimeouts(hComm,&ctmoOld);
        ctmoNew.ReadTotalTimeoutConstant = 100;
        ctmoNew.ReadTotalTimeoutMultiplier = 0;
        ctmoNew.WriteTotalTimeoutMultiplier = 0;
        ctmoNew.WriteTotalTimeoutConstant = 0;
        SetCommTimeouts(hComm, &ctmoNew);

// Just some more variables
        dcbCommPort.DCBlength = sizeof(DCB);
        GetCommState(hComm, &dcbCommPort);
        BuildCommDCB("19200,N,8,1", &dcbCommPort);
        SetCommState(hComm, &dcbCommPort);

Op radiobutton2click hetzelfde, maar dan bij CreateFile uiteraard COM2.
Nu zou je zeggen dat je gewoon op die 2 button kan blijven douwen. Want wanneer de hComm niet NULL is -> wegslopen die handler en een nieuwe maken maar dan met een andere COMpoort.

Nu het probleem: ik ken 1 keer op een andere knop drukken. Maar de 2de keer hangt de app.

Wie-o-wie weet het antwoord (of een andere manier/voorbeeld prog) om een COMpoort-select-iets te maken?

[LordLarry]

gebruik je threads?

default zijn de calls blocking, is dat niet het probleem? heb je 100% cpu als ie locked?

stap eens door je code tot ie locked en kijk waar dat is.

[Baron]

Misschien kan je deze component gebruiken?

http://www2.arnes.si/~sopecrni/

[curry684]

LordLarry schreef op 09 september 2002 @ 14:58:
gebruik je threads?

Mwah hij terminate een thread in regel 2, dus ik gok van wel

stap eens door je code tot ie locked en kijk waar dat is.

Idd, da's de enige manier om er fatsoenlijk achter te komen...

[TimmeStein]

Hij lijkt na een paar keer tussen de radiobuttons (en dus de compoorten) te switchen op

code:

SetCommTimeouts(hComm, &ctmoOld);

te blijven hangen.

[farlane]

Als je eens op het terminaten van je readthread gaat wachten voordat je alles purged en closed enzoo ?

[LordLarry]

En gebruikt die thread niet dezelfde variablen (en dus ook componenten) als de GUI (main thread) of heb je zelfs meerdere threads? Want dan zou je ook daar nog last van kunnen hebben.

[TimmeStein]

Ik heb 1 thread die staat te luisteren naar die port. Maar voordat ik die handler wegsloop, kill ik die thread (of gaat dit niet goed?). Hebben jullie niet ergens een mooi stukkie code staan? Ik heb een hekel aan third party libs e.d.

[ Voor 0% gewijzigd door TimmeStein op 09-09-2002 22:41 . Reden: typo ]

[curry684]

De TThread functie Terminate is niet instantaneous.... het zet alleen threadsafe een booltje waardoor de thread zelf kan besluiten dat ie moet sluiten. Je moet dus dmv. WaitFor wachten totdat de thread klaar is... par example (pseudocodish, weet signatures zo snel niet precies):

C++:

int TMyReaderThread::Execute()
{
while(!Terminated)
  {
  // Doe je ding
  ....
  }
return 0;
}

void TMyForm::MyButtonClick(TObject* p_Sender)
{
TThread*    l_MyThread = new TMyReaderThread(false);   // Geen suspended start

// Terminate de thread
l_MyThread->Terminate();

// Doe eventueel nog wat ander spul, en zodra de thread echt weg *moet* zijn doe je:
int l_ReturnCode = l_MyThread->WaitFor();
}

[Verwijderd]

meerdere treads EN forms . .stop je de messagedispatch-flow toevallig niet ?

[curry684]

Verwijderd schreef op 10 september 2002 @ 15:53:
meerdere treads EN forms . .stop je de messagedispatch-flow toevallig niet ?

Ik mag hopen dat ie in de readerthread geen Win32-user of GDI-functies gebruikt...

[TimmeStein]

Verwijderd schreef op 10 september 2002 @ 15:53:
meerdere treads EN forms . .stop je de messagedispatch-flow toevallig niet ?

Eeuuhhh... Wat?

[curry684]

TimmeStein schreef op 10 september 2002 @ 19:03:
Eeuuhhh... Wat?

Functies uit de Userlib (windows/controls etc.) en de GDI (bitmaps etc.) zijn per definitie singlethreaded, en moet je dus niet vanuit andere threads gaan aanroepen dan degene waarin je window procedure zich bevindt... mocht het nodig zijn moet je de functie TThread::Synchronize gebruiken. Je mag overigens vanuit een andere thread wel PostMessage gebruiken, maar bijv. SendMessage is extreem uit den boze.

[Verwijderd]

TimmeStein schreef op 10 september 2002 @ 19:03:
[...]


Eeuuhhh... Wat?

oeps . . hehe. . ok . ..

windows doet alles via messages. . .als jij bv. je muis beweegt, word dat berichtje naar ALLE windows in je App. gestuurd. . zodat alle windows weten dat de muis bewogen is.

als een window dat berichtje binnen krijgt (::GetMessage, ::PeekMessage functions), dan moetie dat ook weer doorsturen (::DispatchMessage function)

Threads programmeren is vrij complex. .. en voordat je het weet gaat het mis met die messages. . vooral als je een window/component probeert te gebruiken uit een andere Thread (kan wel maar is vrij trickie)

als zo'n probleem optreed lijkt het als je App. hangt .. maar eigenlijk zit er iemand op messages te wachten die jij waarschijnlijk niet verstuurd hebt. .. (meestal hangt dan ook alleen jou App. en kun je de PC/andere programma's gewoon blijven gebruiken)

mocht je meer willen weten . .dan moet je GetMessage/PeekMessage/DispatchMessage/Thread op MSDN verder uitzoeken . .

[Verwijderd]

Uhhhh, moest je ook niet in je threads de eventhandling zelf doen (ivm je interface updates e.d.?). Wat ik me bij Delphi ( what's the diff with C++ Builder ) kon herinneren is dat ik daar de message events zelf moest handlen ( code is bij mijn vorige werkgever dus daar kan ik ffff slecht bij )
Thread coding is redelijk simpel als je je maar houdt aan een paar basisprincipes.
Wat het ook nog kan zijn ( maar dit is echt een uneducated guess ) gebruik je CreateThread of Begin en EndThread. Bij de eerste heb je volgens mij te maken met het opnieuw initialiseren van globale variabelen (dat deed zeer, is al 4 jaar geleden dat ik dat geprogged heb).

[ Voor 0% gewijzigd door Verwijderd op 11-09-2002 22:55 . Reden: Bloody typos ]