[BCB] Delay?

[bart0l0meus]

Hallo, ik zal deze keer wat meer inzet vertonen;)
overigens is de code al enorm gevordert

Ik ben bezig om programma`s voor de discovloer te maken, zodat ze in een bepaalde volgorde bewegen bijvoorbeeld.

Hier heb ik 2 functies gemaak;
kleur1 (voor het berekenen van Code1, die verstuurd wordt naar de discovloer en het aanpassen van de GUI, zoals een virtuele discovloer die bestaat uit labels) en sendArray die gebruikt wordt om Code1 via de COM poort naar de vloer te sturen.
RGB1 is de kleur waarde, die via verschillende GUI componenten kunnen worden ingevoerd.
NU had ik het volgende bedacht:

code:

    RGB1 = clWhite;
    kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
    SEND1(Code1,ProgressBar1,cm,BR);

    Sleep(1000);

    RGB1 = clBlue;
    kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
    SEND1(Code1,ProgressBar1,cm,BR);

nu is het alleen zo dat hij na 1s op blauw springt en niet eerst op wit en na 1 s pas op blauw wat wel de bedoeling is, hij voert de functie dus niet op volgorde uit lijkt het wel.
Hoe komt dit??

[ Voor 3% gewijzigd door bart0l0meus op 11-12-2007 17:43 ]

[remco_k]

Hoe ziet de inhoud van kleur1 en SEND1 eruit?
En als je een breakpoint zet op regel 5, is het dan wit?
En is het 'witte commando' dan ook uit de compoort gekomen?

Zonder die info is het behoorlijk wat gokwerk, hier de mijne:

Dergelijke code moet je in een losse thread te bouwen. (aangenomen dat dat nu niet zo is en je de code dus in de main thread uitvoerd).
Nu 'hangt' je applicatie gedurende elke Sleep(x) die je doet, dat is niet zo als deze in een losse thread staat.

Dat is tevens waarschijnlijk de reden waarom hij na 1 seconde ineens naar blauw springt. (maar in werkelijkheid eerst heel kort naar wit en dan meteen naar blauw)
Je applicatie krijgt pas tijd om de gegevens te versturen/verwerken als hij klaar is met het doorlopen van je opgegeven code.
Als je deze code inderdaad in je main thread uitvoerd, dan mag je op regel 4 even de applicatie zijn message queue laten verwerken.
En daardoor kan hij o.a. z'n eigen form bijwerken.
Afhankelijk van de inhoud van de 2 functies kleur1 en SEND1 zal het wellicht gaan werken.
Maar dit is not the way to go! Dit is een hele smerige oplossing en is afhankelijk van de rest van je programma. Mogelijk gaat dit in een later stadium voor hele grote ondoorzichtelijke problemen zorgen.

Overbouwen naar een losse thread is beter en dan hoeft die "message queue verwerken" ook niet.
Wel even opletten, threads zijn mooi maar je mag vanuit een thread geen VCL objecten aanraken. (dus ook de kleur niet zetten of de tekst lezen/schrijven.) Dat mag alleen als je gesynchroniseerd bent met de main thread. Je moet dan ook even uitzoeken of de manier waarop jij naar de compoort praat, of die wel thread safe is.

Als je nog niets van de bron van je probleem snapt, maak dan eens een test op kleine schaal.
Maak een nieuw form, plak er een Label op (Label1) en een Button1.
In het buttonclick event doe je dit:
[code=cpp]
Label1->Caption="1";
Sleep(1000);
Label1->Caption="2";
Sleep(1000);
Label1->Caption="3";
Sleep(1000);
[/code=cpp]
Start die applicatie en druk op de button. Gevolg: 3 seconden lang 'hangt' je applicatie en daarna staat in Label1->Caption "3".
Dit is hetzelfde probleem als jij hierboven hebt. Voor elke sleep de message queue laten verwerken lost het probleem op en je ziet dan netjes na elke seconde het label veranderen van 1 naar 2 naar 3.
Daartussen reageert je programma nergens op gedurende 1 seconde.
Maar zoals gezegd: dit is een smerige oplossing en gaat vroeg of laat voor de grootste problemen zorgen. Dit soort dingen behoor je vanuit een losse thread te doen.

Gezien je andere topic(s) denk ik dat je veel te ver boven je pet bezig bent. Het ontbreekt aan broodnodige theorie. Ik heb dan ook (expres) niet vermeld hoe/waarmee je de message queue kan laten verwerken. Hier moet je maar even in de documentatie gaan duiken en gaan snappen hoe de (windows) message queue werkt.
En omdat je het nou toch in een thread gaat maken, kan je meteen verder lezen hoe/wat/waar een thread...

[ Voor 54% gewijzigd door remco_k op 12-12-2007 16:42 . Reden: Edit: de message queue code vervangen door de woorden message queue. Anders leert onze vriend er nog steeds niets van. ]

[farlane]

Geen thread, gewoon timer met statemachine.
Een thread gebruiken om een Sleep te kunnen gebruiken is bad stuff en op z'n minst mega overkill. Gebruik een timer dan heb je de hele sleep niet nodig.

[remco_k]

farlane schreef op woensdag 12 december 2007 @ 21:06:
Geen thread, gewoon timer met statemachine.

Dat kan ook. Alleen zijn timers totaal niet naukeurig in hun timing. (sleep ook niet trouwens, maar dat terzijde)
En de code in het timer event word eveneens in de mainthread uitgevoerd. In princiepe heb je met statemachine geen Sleep meer nodig denk ik, maar het kan wel de nodige problemen opleveren.
Daarnaast denk ik dat (gezien de ervaring van de TS) statemachine ver boven zijn pet gaat.
Dus dan blijft het bij een Sleep() en die moet niet in de main thread.

Een thread gebruiken om een Sleep te kunnen gebruiken is bad stuff en op z'n minst mega overkill.

Een thread is nooit overkill zeker niet als de kans op uitbreiding van je applicatie groot is. Als je wilt dat je gui ten aller tijde blijft reageren is een thread the way to go.
Je moet zo een lange Sleep nooit in de main thread zetten.
Dus je hebt de keuze: iets anders zoals statemachine of een thread bouwen.

Gebruik een timer dan heb je de hele sleep niet nodig.

Code van het timer event word zoals gezegd ook in de main thread uitgevoerd. Dus als er iets langzaam gaat en het uitvoeren van de code in het timer event duurt b.v. 1 seconde, dan hangt die applicatie alsnog 1 seconde.
Ik kan je zeggen, als ik een avondje voor lightjockey speel is het laatste wat ik wil meemaken dat de software/hardware waarmee ik werk niet reageerd. Ook al is dat maar 100 msec.
Dat geld ook voor andere software. Wat er ook gebeurd, wat die software ook aan het doen is (al staat ie 100% pannenkoeken te bakken op de CPU), de gui moet gewoon blijven reageren.

Daarnaast hebben timers nog 1 heel groot nadeel:
Als de applicatie iets anders in z'n mainthread staat te doen dan word gedurende die tijd het timer event ook niet afgevuurd. B.v. het met je muis vasthouden van het form is daarvoor al genoeg. En zo kan ik nog wel even doorgaan. Hoewel zo'n undocumented 'pause' feature ook welkom kan zijn natuurlijk.
In timers moet je geen bedrijfskritieke dingen doen. Zorgt voor heel onvoorspelbare situaties.
Als ik een applicatie onder ogen krijg waarin in een timer iets kritieks word gedaan, dan verbouw ik dat onherroepelijk om naar een thread.

[ Voor 14% gewijzigd door remco_k op 13-12-2007 14:35 ]

[bart0l0meus]

hmmmm, dit gaat idd zwaar boven mijn niveau!
Ik dacht zelf zoiets:

code:

    for(i>0; i<1001; i++)
      {
      if (i == 1)
        {
          RGB1 = clWhite;
          lblBlok1->Color = RGB1;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          SEND1(Code1,ProgressBar1,cm,BR);
        }

    if (i == 1000)
        {
          RGB1 = clBlue;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          lblBlok1->Color = RGB1;
          SEND1(Code1,ProgressBar1,cm,BR);
        }
      }

maar dit werkt niet!
is er echt geen simpele oplossing te bedenken?

[remco_k]

bart0l0meus schreef op donderdag 13 december 2007 @ 16:27:
hmmmm, dit gaat idd zwaar boven mijn niveau!
Ik dacht zelf zoiets:

code:

    for(i>0; i<1001; i++)
      {
      if (i == 1)
        {
          RGB1 = clWhite;
          lblBlok1->Color = RGB1;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          SEND1(Code1,ProgressBar1,cm,BR);
        }

    if (i == 1000)
        {
          RGB1 = clBlue;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          lblBlok1->Color = RGB1;
          SEND1(Code1,ProgressBar1,cm,BR);
        }
      }

maar dit werkt niet!
is er echt geen simpele oplossing te bedenken?

Simpel? Wat denk je nou, zal ik het even voor je maken?
Weet je zelf wel wat je gemaakt hebt nu?
Wat werkt er niet?
Heb je uberhaubt mijn post (en dan met name dat deel over de message queue) wel gelezen?
Waar is je Sleep() gebleven, wat je nu hebt gemaakt is binnen 2 milliseconden klaar...

[ Voor 12% gewijzigd door remco_k op 13-12-2007 16:38 ]

[bart0l0meus]

sorry
die code was idd verkeerd, deze moet het zijn:
en ik zal je post nogmaals doorlezen.

code:

    for(i>0; i<1001; i++)
      {
      Sleep(5);
      if (i == 1)
        {
          RGB1 = clWhite;
          lblBlok1->Color = RGB1;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          SEND1(Code1,ProgressBar1,cm,BR);
        }

    if (i == 1000)
        {
          RGB1 = clBlue;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          lblBlok1->Color = RGB1;
          SEND1(Code1,ProgressBar1,cm,BR);
        }
      }

[remco_k]

Dus nu 'hangt' je applicatie 5 seconden en ineens is het resultaat blauw.
Toverwoord: message queue....

Je geeft ook geen antwoord op mijn vragen uit m'n eerste post, je hebt duidelijk de test op kleinere schaal niet eens bekeken, laat staan uitgevoerd. Als je dát nou had gedaan...
suc6!

Edit:
trouwens die code van jouw is hetzelfde als dit:

C++:

          RGB1 = clWhite;
          lblBlok1->Color = RGB1;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          SEND1(Code1,ProgressBar1,cm,BR);
          //verwerk de message queue hier
          Sleep(5000);
          RGB1 = clBlue;
          kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
          lblBlok1->Color = RGB1;
          SEND1(Code1,ProgressBar1,cm,BR);

En deze code werkt ook niet omdat op regel 5 de message queue verwerkt moet worden. Pas dan past het form zijn controls aan en zullen kleurtjes veranderen.

Overigens word de RS232 data waarschijnlijk wel gewoon verstuurd. Ook als je de message queue niet verwerkt.

[ Voor 61% gewijzigd door remco_k op 13-12-2007 16:45 ]

[bart0l0meus]

remco_k schreef op donderdag 13 december 2007 @ 16:39:
Dus nu 'hangt' je applicatie 5 seconden en ineens is het resultaat blauw.
Toverwoord: message queue....

Je geeft ook geen antwoord op mijn vragen uit m'n eerste post, je hebt duidelijk de test op kleinere schaal niet eens bekeken, laat staan uitgevoerd. Als je dát nou had gedaan...
suc6!

Ik ben begonnen met het uitproberen op kleine schaal, dit was het eerste wat ik heb gedaan toen ik op het idee kwam.
Ik ben me nu aan het informeren over message queu.
Ik heb een break neergezet na regel 9, dan wordt hij wel wit, maar telt hij niet meer door naar 1000.

[farlane]

remco_k schreef op donderdag 13 december 2007 @ 14:28:
Dat kan ook. Alleen zijn timers totaal niet naukeurig in hun timing. (sleep ook niet trouwens, maar dat terzijde)
En de code in het timer event word eveneens in de mainthread uitgevoerd. In princiepe heb je met statemachine geen Sleep meer nodig denk ik, maar het kan wel de nodige problemen opleveren.
Daarnaast denk ik dat (gezien de ervaring van de TS) statemachine ver boven zijn pet gaat.
Dus dan blijft het bij een Sleep() en die moet niet in de main thread.

Welke problemen dan? Een statemachine is in principe een switch structuur, en als zodanig een heel stuk simpeler dan een losse thread, met alle synchronisatie en locking stuff van dien.

Nogmaals, een Sleep heb je nooit nodig. Het gebruik van een Sleep duidt op een designfout. Als je een hele korte ( < 10 ms bijvoorbeeld ) Sleep nodig hebt moet je een busy wait schrijven. Als je langer wilt wachten gebruik je timer of een waitable event of weet ik veel wat.

Een thread is nooit overkill zeker niet als de kans op uitbreiding van je applicatie groot is.

Alsof die 2 ook maar iets met elkaar te maken hebben.

Als je wilt dat je gui ten aller tijde blijft reageren is een thread the way to go.

Onzin. Als je een timer gebruikt blijft je GUI ook reageren.

Je moet zo een lange Sleep nooit in de main thread zetten.

Je moet helemaal geen sleep gebruiken, zoals ik in mijn eerste post ook al zei.

Code van het timer event word zoals gezegd ook in de main thread uitgevoerd. Dus als er iets langzaam gaat en het uitvoeren van de code in het timer event duurt b.v. 1 seconde, dan hangt die applicatie alsnog 1 seconde.

Dat klopt, maar al datgene dat 1 seconde duurt een Sleep is ben je fout bezig.

Ik kan je zeggen, als ik een avondje voor lightjockey speel is het laatste wat ik wil meemaken dat de software/hardware waarmee ik werk niet reageerd.

En dat los je op door een thread te gebruiken die het werk doet? Als je GUI blijft hangen omdat je er een Sleep in hebt staan, zal de thread ook blijven hangen omdat je er een Sleep in hebt staan en zal er ook niets gebeuren, aangezien je dat wat je in die thread doet ook een resultaat zal moeten opleveren.

Daarnaast hebben timers nog 1 heel groot nadeel:
Als de applicatie iets anders in z'n mainthread staat te doen dan word gedurende die tijd het timer event ook niet afgevuurd. B.v. het met je muis vasthouden van het form is daarvoor al genoeg. En zo kan ik nog wel even doorgaan. Hoewel zo'n undocumented 'pause' feature ook welkom kan zijn natuurlijk.

Als je een naukeuriger timer nodig hebt dan de standaard timer gebruik je bv de multimediatimer. ( Die overigens zijn callback al in een andere thread doet ). In ieder geval een die niet je message loop loopt te verzieken.

In timers moet je geen bedrijfskritieke dingen doen.

Ik zie niet hoe het gebruik van een thread dit probleem gaat oplossen. Een Sleep geeft ook geen enkele garantie dat hij zo lang wacht als jij wilt ( alleen dat hij minstens zo lang wacht ).

[remco_k]

farlane schreef op donderdag 13 december 2007 @ 17:40:
[...]

Welke problemen dan? Een statemachine is in principe een switch structuur, en als zodanig een heel stuk simpeler dan een losse thread, met alle synchronisatie en locking stuff van dien.

Nogmaals, een Sleep heb je nooit nodig. Het gebruik van een Sleep duidt op een designfout. Als je een hele korte ( < 10 ms bijvoorbeeld ) Sleep nodig hebt moet je een busy wait schrijven. Als je langer wilt wachten gebruik je timer of een waitable event of weet ik veel wat.

Zoals jij het gebruik van een Sleep een designfout vind, vind ik het fout om kritieke processen in een timer te doen.
In het geval van de TS zal dat verder niet terzake doen omdat hij verder geen processor intensieve handelingen doet.
Maar als je zoals ik regelmatig te maken hebt met processen die meerdere minuten duren (ik noem maar iets: conversie van een grote WAV file naar MP3 ofzo), dan moet je dat niet in de main thread doen en al helemaal niet in een timer.
Zoeits hoort gewoon in een losse thread (of threads ivm dual en quad cores van tegenwoordig), je applicatie heeft nog gewoon tijd om z'n gui te tekenen en hij kan ook nog een progressbar bijwerken en luisteren naar de 'annuleren' knop.
Als je dit alles in een main thread maakt, of in een timer, dan heb je het niet helemaal begrepen.
Nogmaals zal dit voor de TS nogal overkill zijn... Maar in zijn geval een prima oplossing ook.

Alsof die 2 ook maar iets met elkaar te maken hebben.

Goed anders omschreven: als je functies na wat aanpassingen en uitbreidingen ipv in 10 msec 2 seconden bezig zijn.

Onzin. Als je een timer gebruikt blijft je GUI ook reageren.

Niet als je in de main thread een WAV file van 10 minuten staat te converteren naar MP3...
Tenzij je in elke X samples even Application->ProcessMessages() aanroept (hint hint aan de TS).
Als je dat moet doen, dán heb je pas een design fout.

Je moet helemaal geen sleep gebruiken, zoals ik in mijn eerste post ook al zei.

Ik gebruik ook geen Sleep, maar de TS wel.

En dat los je op door een thread te gebruiken die het werk doet? Als je GUI blijft hangen omdat je er een Sleep in hebt staan, zal de thread ook blijven hangen omdat je er een Sleep in hebt staan en zal er ook niets gebeuren, aangezien je dat wat je in die thread doet ook een resultaat zal moeten opleveren.

Je houd nogal vast aan de Sleep, maar ik doel gewoon op een willekeurig stuk code wat XX seconden duurt, zonder Sleep erin.
Dit stuk 'trage' code verplaatsen naar een tread levert geen snelheidswinst op maar wel een applicatie die nog reageert op de gebruiker.

Als je een naukeuriger timer nodig hebt dan de standaard timer gebruik je bv de multimediatimer. ( Die overigens zijn callback al in een andere thread doet ). In ieder geval een die niet je message loop loopt te verzieken.

Klopt helemaal, en hij komt niet voor niets in een andere thread terug. Dat heeft een hele belangrijke reden, namelijk dat hij die code kan uitvoeren exact op het moment dat hij dat wil en dat het uitvoeren van die code (min of meer) nooit afhankelijk is van de status van de main thread en dat de main thread ook nog zijn werk kan blijven doen, zoals het bijwerken van een progressbar of 'annuleren' knop.

Ik zie niet hoe het gebruik van een thread dit probleem gaat oplossen. Een Sleep geeft ook geen enkele garantie dat hij zo lang wacht als jij wilt ( alleen dat hij minstens zo lang wacht ).

In het geval van de TS lost het gebruiken van een thread het probleem op hoor, misschien iets te ingewikkeld voor zijn kunnen, maar het is nog altijd een prima oplossing.
Het zal de TS zelf boven zijn pet gaan, hij moet dus in z'n voorlopige programma waarmee hij werkt eventjes een Application->ProcessMessages() voor elke sleep zetten om ervoor te zorgen dat z'n gui bij word gewerkt. Dat hoeft niet als je zijn code in een losse thread zet.
Het gebruik ervan levert wel een gevaar op dat je nogmaals dezelfde functie inkomt, terwijl je er nog niet uit bent. Ook bij een timer loop je dit gevaar.

Maargoed, je hoeft het niet met mij eens te zijn. Iedereen heeft zo z'n werkwijzes en een ander hoeft niet perse fout te zijn. Ik heb een bloedhekel aan timers en aan programma code in de main thread. Vooral als die code langdurig ergens mee bezig is en mensen met smerige Application->ProcessMessages() truken bezig zijn, of een timer 'misbruiken' om de basis van het programma in te bouwen.

Ik ben eerder benieuwd of de TS nou ondertussen snapt waarom het bij hem niet (zichtbaar) werkt...

[farlane]

remco_k schreef op donderdag 13 december 2007 @ 20:31:
Zoals jij het gebruik van een Sleep een designfout vind, vind ik het fout om kritieke processen in een timer te doen.

Ik krijg het idee dat jij het gebruik van een aparte thread een vervanging vindt van het gebruik van een timer, of een Sleep. Die twee staan compleet los van elkaar.
Een delay ( zoals de TS wil hebben ) in een andere thread zetten omdat voor die delay een Sleep wordt gebruikt en anders je mainthread blocked is gewoon fout ( Dat is waar jij mee komt als oplossing ) , simpel as that.

Jij komt vervolgens aanfietsen met verhalen over lange bewerkingen, en het afspelen van WAV files en weet ik niet wat ( alsof je me moet uitleggen waar threads voor dienen), maar daarvan is helemaal geen sprake hier, en slaat voor het probleem van de TS als een tang op een varken.

Kijk nog een goed naar de vraag, eigenlijk komt het neer op "ik wil 2 verschillende dingen 1 seconde na elkaar doen" en jij komt aan met "Gebruik een thread". Volgens mij ben jij degene die er niets van snapt.

[remco_k]

Ga jij effe lekker naar een ander zitten flamen.
Ik vermeld niet voor niets dat de thread oplossing nogal overkill is voor de TS.
Ik probeer alleen maar voort de borduren op zijn Sleep oplossing.

En nee, ik zie een thread totaal niet als vervanger van een Timer of Sleep.

[ Voor 11% gewijzigd door remco_k op 14-12-2007 12:26 ]

[bart0l0meus]

jongens, nou geen ruzie:D en heb nogsteeds geen oplossing gevonden, nog ideeen?

[remco_k]

De (quick en very dirty) oplossing is inmiddels allang genoemd. Namelijk het verwerken van de message queue op gezette momenten.

C++:

    RGB1 = clWhite;
    kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
    SEND1(Code1,ProgressBar1,cm,BR);
    Application->ProcessMessages(); // << ----- HINT HINT
    Sleep(1000);

    RGB1 = clBlue;
    kleur1(RGB1, edDec1,edHex1,edR1,edG1,edB1,edCode1,edTime1,lblBlok1,ScrollBar1);    //functie blok 1
    SEND1(Code1,ProgressBar1,cm,BR);
    Application->ProcessMessages(); // << ----- HINT HINT
   // .... enz

[bart0l0meus]

THNX:D
het werkt idd
het maak niet uit of het een vuile oplossing is, het gaat toch, en hier maakt het toch niet zo veel uit denk ik.

[remco_k]

Maar weet je ook waarom het nu werkt? Nee.
Dus krijg je hier een volgende keer weer last van? Ja.

Suc6 dan.

Maargoed, voor nu is je probleem 'gefixed'.

[ Voor 16% gewijzigd door remco_k op 16-12-2007 15:17 ]

[bart0l0meus]

jah ik denk dat ik weet waarom:P
Description
Call ProcessMessages to permit the application to process events that are currently in the queue.
Ik zou idd niet weten hoe ik het volgende keer fatsoendelijk zou moeten oplossen, maar misschien heb ik tegen die tijd genoeg kennis opgedaan dat ik wel weet hoe het echt moet.
bedankt allemaal;)