[C++/CLI]Threading Timer probleem

[BlackBurn]

Ik ben een applicatie aan het bouwen, waarbij het de bedoeling is dat er een timer gaat lopen en elke keer als de timer een "tick" geeft, dat dan de waarde van de trackbar veranderd. Dit zou je dus visueel moeten zien in de GUI.

Echter heb ik het eerst geprobeerd met een gewone Timer (Windows::Forms), alleen hierdoor wordt de applicatie mega traag en ook de opbouw van de GUI is niet om over naar huis te schrijven.

Nu heb ik e.a. af gezocht en ben tot de conclusie gekomen, dat dit komt omdat de timer en de gui beide in dezelfde thread zitten. Nu zou de oplossing moeten zijn om deze te scheiden en de timer van de bibliotheek threading te gebruiken.

Nu ben ik daar mee begonnen alleen loop ik een beetje vast en kan ik zo 1,2,3 niet vinden waar ik nu verder moet zoeken, kijken, dus als iemand mij hier een duwtje in de goede richting kan geven, graag

Ik doe het volgende:

Ik heb 2 objecten aangemaakt een TimerCallback en een Timer.

C++:

    Threading::TimerCallback ^tmrCallBack;
    Threading::Timer ^tmrThread;

Bij de load methode van het form wil ik deze objecten initialiseren en dit doe ik als volgt.

C++:

    tmrCallBack = gcnew Threading::TimerCallback(Form1, Form1::updateGUI());
    tmrThread = gcnew Threading::Timer(tmrCallBack, null, 0, 100);

Het is de bedoeling dat om de 100 miliseconden de trackbar geupdate wordt en dit wil ik doen in de methode updateGUI.

Nu geeft visual studio netjes deze foutmelding:

code:

Error   4   error C3364: 'System::Threading::TimerCallback' : invalid argument for delegate constructor; delegate target needs to be a pointer to a member function

Echter als ik er een & voor zet wat voor zover ik weet het teken is van een pointer, krijg ik weer een andere foutmelding.

code:

Error   4   error C2102: '&' requires l-value

Iemand die mij een zetje in de goede richting kan geven?

[leuk_he]

afgezien van je compile probleem. Hoe update je de taskbar? Door een method aan te roepn in de gui thread (of die eem message naar de gui thread stuurt) ?

Dan heb je weer het zelfde probleem. toch?

[BlackBurn]

leuk_he schreef op maandag 28 mei 2007 @ 22:23:
afgezien van je compile probleem. Hoe update je de taskbar? Door een method aan te roepn in de gui thread (of die eem message naar de gui thread stuurt) ?

Dan heb je weer het zelfde probleem. toch?

De trackbar wordt geupdate, doordat de property value veranderd.
Deze property wordt geupdate binnen het timerobject.

Volgens mij ontstaat het probleem, omdat de timer om de 100msec. e.a. controlleert en evt. de trackbar update. Op het moment dat de timer dit doet, moet de gebruiker bijv. wachten voordat de GUI weer beschikbaar is.

[Verwijderd]

Nogal omslachtig om een timer in een aparte thread te doen. Dit zou gewoon in dezelfde thread moeten kunnen als de GUI. Volgens mij doe je gewoon iets fout.

[Verwijderd]

Verwijderd schreef op dinsdag 29 mei 2007 @ 02:06:
Volgens mij doe je gewoon iets fout.

Geniale tip!

BlackBurn, als je 10x per seconde de timer af laat gaan moet je er wel voor zorgen dat in 't tick event heel weinig gebeurt. Een database verbinding opbouwen, query uitvoeren, gegevens verwerken en DB connectie weer afsluiten is dan bv. niet handig. Dat legt je GUI dan gegarandeerd plat.

[BlackBurn]

Hmm zoveel gebeurd er eigenlijk ook niet in de timer tick event.

Ik heb een aparte control klasse, waar een secondarybuffer (directsound) een bestand afspeelt.
In elke tick vraag ik playposition op en aan de hand daarvan enable of disable ik wat knoppen en verschuift de status van de trackbar.

Het enige wat ik me voor kan stellen is, dat de playposition ophalen te lang duurt? Iemand hier ervaring mee of hoe ik het op een nette manier kan debuggen om te zien waar het fout gaat en waarom het zo lang duurt?

[.oisyn]

BlackBurn schreef op maandag 28 mei 2007 @ 22:08:

C++:

    tmrCallBack = gcnew Threading::TimerCallback(Form1, Form1::updateGUI());

Hier klopt iets niet. De ene parameter moet een instance naar je object zijn, de ander een member function pointer. Ik weet niet wat Form1 is, maar voor een instance gebruik je natuurlijk een variabele, en voor een member function pointer gebruik je een type:

C++:

ref class A
{
public:
    void foo();
};

int main()
{
    A ^ aInstance = gcnew A;

    // aInstance is de instance, &A::foo is de member funtion pointer
}

[BlackBurn]

Ik ben al iets wijzer, misschien dat het vele geheugengebruik ook iets met de traagheid te maken heeft.

Ik laad nml. complete wav-files in een buffer, omdat ik hier e.a. aan bewerkingen op doe. Ik ga eerst kijken of ik het geheugengebruik wat kan minimaliseren. Echter op dit moment wil dat nog niet lukken, als ik het object vernietig blijft het geheugen even vol ? Maar we gaan even zoeken, daarna ga ik weer kijken wat de timer doet.

[.oisyn]

Is je compile error nou opgelost?

[BlackBurn]

.oisyn schreef op dinsdag 29 mei 2007 @ 13:35:
Is je compile error nou opgelost?

Ik ben het nu eerst met een "gewone" Timer (windows::forms) aan het proberen of het goed gaat, omdat mensen hierboven er van overtuigd waren dat, dat ook goed zou moeten gaan en als dit zo is lijkt het me een mooiere oplossing dan een aparte thread.

Alleen zit ik eerst nog met wat geheugen optimalisaties.

[farlane]

Kun je die DirectSound posities asynchroon laten binnenkomen? Dan kun je met dat event een Property updaten en hoef je in de timertick alleen deze af te vragen.

Je zult je update routine wel zo moeten schrijven dat alleen de progressbar een update krijgt en niet het hele scherm.

Een aparte thread voor een ui update is een no-go omdat je em toch weer moet synchromiseren met je gui thread.

[ Voor 16% gewijzigd door farlane op 29-05-2007 15:00 ]

[BlackBurn]

farlane schreef op dinsdag 29 mei 2007 @ 14:59:
Kun je die DirectSound posities asynchroon laten binnenkomen? Dan kun je met dat event een Property updaten en hoef je in de timertick alleen deze af te vragen.

Je zult je update routine wel zo moeten schrijven dat alleen de progressbar een update krijgt en niet het hele scherm.

Een aparte thread voor een ui update is een no-go omdat je em toch weer moet synchromiseren met je gui thread.

Volgens mij moet dat geen probleem zijn, het is maar om met een trackbar ong. te laten zien waar het bestand zich bevind met afspelen, als dit iets achter loopt, is dat jammer, maar niet erg.

Stomme vraag misschien maar als ik de value van de trackbar verander, dan veranderd sowieso toch alleen de trackbar en niet de gehele gui?

Ik hoop dat ik vanavond niet te laat thuis ben, kan ik weer e.a. proberen.

[leuk_he]

BlackBurn schreef op dinsdag 29 mei 2007 @ 15:31:
[...]

Stomme vraag misschien maar als ik de value van de trackbar verander, dan veranderd sowieso toch alleen de trackbar en niet de gehele gui?

Nee, maar als jij een propterty zet die als gevolg heeft dat dat dat stukje scerm moet veranderen stuur dat onderwater een WM_SETTEXT naar de gui thread diee dat elemet vervolgens een repaint opdracht geeft van dat stukje.

[farlane]

BlackBurn schreef op dinsdag 29 mei 2007 @ 15:31:
Stomme vraag misschien maar als ik de value van de trackbar verander, dan veranderd sowieso toch alleen de trackbar en niet de gehele gui?

Normaal gesproken werkt dat wel zo ja ... om zeker te weten waar nou de tijd in gaat zitten zou je eigenlijk even een voor een de belangrijke stukken eruit moeten halen en kijken wanneer die vertraging precies weggaat. Dan pas kun je gericht gaan kijken hoe je het op zou kunnen lossen. Alleen van een timer wordt je applicatie nl niet mega traag.

[BlackBurn]

Even een update, ik heb het probleem gevonden en het had uiteindelijk (inderdaad) niks te maken met de timer.

Ik haalde het aantal bufferbytes op uit de secondarybuffer (directsound) en verdeelde het aantal stapjes van de trackbar hiermee in, echter als er een groot bestand geladen is, dan kan dit getal groter zijn dan 50.000 en dan wordt de schermopbouw een beetje traag. Als deze eenmaal ingeladen is verloopt het soepel. Ben er nu uiteraard mee bezig om te zorgen dat deze belachlijk grote indeling niet meer nodig is

Verder merk ik wel dat ik me toch nog iets meer in het Threading gebeuren moet gaan verdiepen, dus dat word me volgende taak Als er nog iemand goede tutorials heeft, altijd welkom.

Iedereen bedankt voor de hulp.