Hallo allemaal,
Is de tijd welke je met Sleep(nnn) voor elke PC/Labtop instelt altijd nnn seconden of moet je een andere methode gebruiken?
Met een vriendelijke groet, Frans
Hallo allemaal,
Is de tijd welke je met Sleep(nnn) voor elke PC/Labtop instelt altijd nnn seconden of moet je een andere methode gebruiken?
Met een vriendelijke groet, Frans
Sleep is in milliseconden, maar ik gebruik deze nooit.
Sleep blokkeert het programma en kan niet onderbroken worden.
Ik heb deze routine als alternatief.
Delphi Code:
procedure Delay(TickTime : Integer); var Past: longint; begin Past := GetTickCount; repeat application.ProcessMessages; Until (GetTickCount - Past) >= longint(TickTime); end;
10.4.2, Delphi2010, of Lazarus 2.2.0
Maar die Delay procedure pauzeert niet. Die handelt alle messages af, en dus kan je tijdens de delay bijvoorbeeld op buttons drukken e.d. Een prima manier om de hele flow van je programma in de war te gooien..
1+1=b
Jos, Heb je een betere (of andere) methode ?
10.4.2, Delphi2010, of Lazarus 2.2.0
code die een "wachttijd" nodig hebben in een thread zetten en daar een event aan hangen of anders een state introduceren en in een timer de state correct zetten
sleep wacht _minstens_ nn milliseconden. Het kan meer zijn, al zijn echt grote afwijkingen zeldzaam in het multicore tijdperk.
Nee. D.w.z., ik kan me geen situatie voorstellen waarin ik een codepad binnen 1 thread wil pauzeren voor een bepaalde lange tijd, en ondertussen wel messages met andere code erin af wil handelen.
Application.ProcessMessages is vaak al een teken van een risicovolle implementatie, maar deze gaat nog een stapje verder.
Meestal heb je lange code, die blokkeert de main thread, en je kan er dan ProcessMessages tussen zetten om de het toch nog een beetje te laten reageren, zonder het daadwerkelijk naar een thread te verhuizen. Waarom je die langdurige code nog langer zou willen laten duren... Ik ben nieuwsgierig hoe je dit gebruikt.
Overigens, klein detail, maar als je na 49,7 dagen op het verkeerde moment deze procedure start, dan kan die mogelijk blijven hangen, omdat GetTickCount dan wrapt naar 0.
1+1=b
Ik gebruik dergelijke routines (maar dan gewoon met now() ) tijdens applicatie shutdown. Dit om events die al gegenereerd zijn door de threads (of nog gegenereerd worden tot de thread definitief shutdowned) nog te verwerken voordat ik de main thread systemen begin af te schieten.
Je wordt weer met je neus op de feiten gedrukt, dit is een routine ooit gemaakt en staat standaard in een eigen unit.
Omdat het eigenlijk altijd gewerkt heeft heb ik daar verder nooit meer naar gekeken.
Zo zie je maar hoe leerzaam een forum kan zijn, destijds (in de onwetendheid toen > 10 jaar geleden), fout geschreven procedures vervuilen de code zonder dat je het in de gaten kan heb.
Een knip en plakt voorbeeldje voor een medeforum lid, brengt zo maar een potentieel probleem boven.
De routine heb ik er inmiddels tussenuit geknipt, met een melding erbij.
Als deze in de code voorkomt in een programma zal ik deze gaan herschrijven.
Bedankt voor deze eyeopener
Peter
10.4.2, Delphi2010, of Lazarus 2.2.0
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks