Toon posts:

[Delphi] Dynamic werkt niet. BusyWaiting probleem?

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik ben sinds een paar dagen bezig met een zogenaamde MUD te maken. Hierbij loggen een x aantal users in op een server waarin ze dan via getypte commando's een spel kunnen spelen.

Alles goed en aardig het werkt prima, maar nu heeft elke gebruiker een eigen TTimer nodig. Die zal ik dynamisch moeten aanmaken want er is geen maximum aantal spelers.

Elke ingelogde speler wordt een TUser. Hierin zit onder andere een TTimer. Dit ziet er zo uit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  TUser = class
      // hier wat properties
      Timer: TTimer;
  private

  public
      // hier nog heel wat functies en procedures
      constructor Create(n: String; T: TIdPeerThread);
      procedure TimerExecute(Sender: TObject);
  end;

constructor TUser.Create(n: String; T: TIdPeerThread);
begin
   // wat statements
   Timer := TTimer.Create(nil);
   Timer.Interval := 1000;
   Timer.Enabled := True;
   Timer.OnTimer := TimerExecute;
   // en nog een paar
end;

procedure TUser.TimerExecute(Sender: TObject);
begin
   Output('{rTimer');  // debug statement uiteraard
{   case U.Fightstatus of
   _SWP: Sweep(U, U.FightingWith);
   _RNH: Roundhouse(U, U.FightingWith);
   end;
   Enabled := False; }
end;


Na debuggen ben ik erachter gekomen dat de TTimer zoals verwacht wel wordt aagemaakt, ook aan staat en het interval staat ook goed, in een andere procedure van TUser kan ik deze waardes ook aanpassen, heb ik ook getest. Nu vraag ik me alleen af waarom TimerExecute nooit wordt uitgevoerd.

Ik heb eens voor de gein een TUser onbuttonclick aangemaakt, grappig genoeg werkt de timer dan wel. Ik verwacht dan ook dat het zich om dit stukje code gaat.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
procedure TForm1.IdTelnetServer1Execute(AThread: TIdPeerThread);
var User: TUser;
begin
   User := FindUserByThread(AThread);

   if (User<>nil) and (User.Linkdead = True) then
      User.Reconnected(AThread);

   if User = nil then
   begin
      User := TUser.Create('[LoggingIn...]', AThread);
      AllThreads.Add(User);
      // inlogbegroeting
   end
   else
   case User.ConStatus of
   // inlogzooi
   IDLE:
      begin
         try
            cmd := User.Thread.Connection.ReadLnWait;
            ExecuteCommand(cmd, User);
            User.Showhud;
         except end;
      end
   end;
end;


En dan met name om deze regel:

code:
1
cmd := User.Thread.Connection.ReadLn;


Hier blijft de Thread namelijk steeds wachten op commando's. Na wat zoeken op google en in de search verwacht ik dat het hier gaat om een BusyWaiting probleem. Alleen ik heb geen idee hoe ik dit moet oplossen.

Wat ik heb geprobeerd is dit:
code:
1
2
3
            cmd := User.Thread.Connection.ReadLnWait;
            ExecuteCommand(cmd, User);
            User.Showhud;


vervangen door:
code:
1
2
3
4
5
            cmd := User.Thread.Connection.ReadLnWait('', 100); // timeout toegevoegd
            if not User.Thread.Connection.ReadLnTimedOut then
               ExecuteCommand(cmd, User);
               User.Showhud;
            end;


Hiermee was het probleem van de timer alleen niet opgelost. ;(

/me is ten einde wanhoop..

Hopelijk is er hier een guru die me kan helpen want ik heb die timer echt nodig.


Hmm, ik heb iets teveel geedit van mijn topictitel, kan een modje er misschien "[Delphi] Dynamic TTimer werkt niet. BusyWaiting probleem?" van maken?

[ Voor 4% gewijzigd door Verwijderd op 05-01-2005 11:37 ]


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Met een busy wait is je cpu heel druk bezig in een loop te controleren of aan een bepaalde conditie voldaan kan worden.

code:
1
2
3
4
5
6
7
while(pc.leeftijd<3)
begin
     ... doe niets..
end;

//als je hier komt is de computer 3 jaar of ouder.
pc.gooiInDePrullemand()


Dat is dus een busy wait en zorgt voor een cpuload van 100% en daar heb jij geen last van.


Ik heb verder de indruk dat er 1 algemene thread is die alle users bedient. Als deze thread ligt te maffen op de input van user 1, kunnen de andere users niet meer geholpen worden.

Het is denk ik handiger om gewoon gebruik te maken van een thread per user, en deze thread gewoon te laten maffen totdat de user invoer geeft. Op deze manier kunnen de threads onafhankelijk van elkaar werken/maffen.

Ik ben trouwens geen delphi programmeur :)

[ Voor 20% gewijzigd door Alarmnummer op 05-01-2005 11:47 ]


Verwijderd

Topicstarter
Alarmnummer schreef op woensdag 05 januari 2005 @ 11:45:
Met een busy wait is je cpu heel druk bezig in een loop te controleren of aan een bepaalde conditie voldaan kan worden.

code:
1
2
3
4
5
6
7
while(pc.leeftijd<3)
begin
     ... doe niets..
end;

//als je hier komt is de computer 3 jaar of ouder.
pc.gooiInDePrullemand()


Dat is dus een busy wait en zorgt voor een cpuload van 100% en daar heb jij geen last van.


Ik heb verder de indruk dat er 1 algemene thread is die alle users bedient. Als deze thread ligt te maffen op de input van user 1, kunnen de andere users niet meer geholpen worden.

Ik ben trouwens geen delphi programmeur :)
Ik weet wat BusyWaiting is :) Het probleem is dat ik niet weet of ik met dat probleem nu zit. En ja er is een algemene thread voor iedereen... maar het werkt al multiplayer dat is het probleem echt niet :)

Het grappig is overigens, wat ik nog erbij wil vermelden, dat een statische timer die erop zit voor de zogenaamde "ticks" wel goed werkt...

  • whoami
  • Registratie: December 2000
  • Laatst online: 21:23
Ik denk trouwens dat het 'gevaarlijk' is om op deze manier met Timers te werken. Het aantal timers dat tegelijkertijd kan bestaan is nl. niet ongelimiteerd. Dit is OS afhankelijk.

https://fgheysels.github.io/


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Als jij een BusyWait hebt zou je cpuload 100% moeten zijn. Heb jij dat?
Het probleem is dat ik niet weet of ik met dat probleem nu zit. En ja er is een algemene thread voor iedereen... maar het werkt al multiplayer dat is het probleem echt niet :)
Hoezo? Als die algemene thread ligt te wachten op de input van 1 user.. dan kunnen andere users niet geholpen worden. Dat is denk ik de reden dat jouw systeem vast zit.. jouw enigste thread is aan het slapen op de input van 1 user.

Wat jij nodig bent is een thread-per-user. Heb jij dat? (Ik ben geen delphi kenner)
Het grappig is overigens, wat ik nog erbij wil vermelden, dat een statische timer die erop zit voor de zogenaamde "ticks" wel goed werkt...
Zo lang die statische timer niet ligt te slapen op de input van een user.. tja.. zal die wel goed gaan.

Verwijderd

Topicstarter
whoami schreef op woensdag 05 januari 2005 @ 11:49:
Ik denk trouwens dat het 'gevaarlijk' is om op deze manier met Timers te werken. Het aantal timers dat tegelijkertijd kan bestaan is nl. niet ongelimiteerd. Dit is OS afhankelijk.
Nou, ik heb het hier over 1 statische... en (ff om te testen) 2 timers voor 2 ingelogde users (localhost en mijn ip)....

Ik heb trouwens om te benchmarken 3000 timers dynamisch gecreate onformactivate (ja dan werkt het weer wel... maar dan heb ik er niks aan)... en mijn cpu load kwam toen op 50%... aangezien er nooit 3000 users inloggen is dat het probleem ook niet :P Maar thnx voor het meedenken.

  • LordLarry
  • Registratie: Juli 2001
  • Niet online

LordLarry

Aut disce aut discede

Een TTimer werkt dmv Windows Messages. Dat betekend dat je de applicatie wel de tijd moet gunnen om de events af te handelen. Dat gebeurt niet als je maar heel druk code blijft executen of als je de mainthread blocked. Dat laatste doe je bijvoorbeeld met ReadLn aangezien Indy blocking is. De oplossing is of threads gaan gebruiken, maar dan moet je ook zorgen dat je code thread safe is. Een andere oplossing is een TIdAntiFreeze componentje in je applicatie aanmaken of regelmatig zorgen dat je Application.ProcessMessages aanroept. Bijvoorbeeld:

Delphi:
1
2
3
4
5
6
7
cmd := User.Thread.Connection.ReadLnWait('', 100); // timeout toegevoegd
if not User.Thread.Connection.ReadLnTimedOut then
  ExecuteCommand(cmd, User);
  User.Showhud;
end
else
  Application.ProcessMessages;


/edit
Het is geen busy waiting probleem, maar gewoon een thread blocking probleem.

[ Voor 7% gewijzigd door LordLarry op 05-01-2005 11:54 ]

We adore chaos because we like to restore order - M.C. Escher


Verwijderd

Topicstarter
Alarmnummer schreef op woensdag 05 januari 2005 @ 11:51:
Als jij een BusyWait hebt zou je cpuload 100% moeten zijn. Heb jij dat?
Nope. Geen BusyWaiting dus, maar wat dan?
Hoezo? Als die algemene thread ligt te wachten op de input van 1 user.. dan kunnen andere users niet geholpen worden. Dat is denk ik de reden dat jouw systeem vast zit.. jouw enigste thread is aan het slapen op de input van 1 user.

Wat jij nodig bent is een thread-per-user. Heb jij dat? (Ik ben geen delphi kenner)
Het IS thread by user. :P Daar zorgt de IdTelnetServer voor kerel. Zoals ik al zei, thread gebeuren werkt prima.
Zo lang die statische timer niet ligt te slapen op de input van een user.. tja.. zal die wel goed gaan.
Die andere timer wacht ook niet op input van de user...


Aanvulling trouwens. Ik heb ook al de priority van de thread lager te zetten, maar dat maakte ook geen verschil. Ik neem nu dus aan dat het geen BusyWaiting is.

Verwijderd

Topicstarter
LordLarry schreef op woensdag 05 januari 2005 @ 11:53:
Een TTimer werkt dmv Windows Messages. Dat betekend dat je de applicatie wel de tijd moet gunnen om de events af te handelen. Dat gebeurt niet als je maar heel druk code blijft executen of als je de mainthread blocked. Dat laatste doe je bijvoorbeeld met ReadLn aangezien Indy blocking is. De oplossing is of threads gaan gebruiken, maar dan moet je ook zorgen dat je code thread safe is. Een andere oplossing is een TIdAntiFreeze componentje in je applicatie aanmaken of regelmatig zorgen dat je Application.ProcessMessages aanroept. Bijvoorbeeld:

Delphi:
1
2
3
4
5
6
7
cmd := User.Thread.Connection.ReadLnWait('', 100); // timeout toegevoegd
if not User.Thread.Connection.ReadLnTimedOut then
  ExecuteCommand(cmd, User);
  User.Showhud;
end
else
  Application.ProcessMessages;


/edit
Het is geen busy waiting probleem, maar gewoon een thread blocking probleem.
Application.ProcessMessages did the trick :) Thanks.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op woensdag 05 januari 2005 @ 11:56:
[...]

Nope. Geen BusyWaiting dus, maar wat dan?
Een slapende thread.
Het IS thread by user. :P Daar zorgt de IdTelnetServer voor kerel. Zoals ik al zei, thread gebeuren werkt prima.
a) schijnbaar gaat het niet prima.. anders had je dit topic niet geopend.
b) ook al heeft telnet voor ieder user een thread. Als jij in je timer constructie maar 1 thread actief hebt die users aan het vragen is voor invoer (en blokkeerd als die er nog niet is), heb jij een probleem. Jouw systeem is niet responsive.
Die andere timer wacht ook niet op input van de user...
Idd.. het gevolg van vragen om input is dat de thread blokkeerd. Daar heeft die ene timer geen last van want hij vraagt niets -> dus alles gaat goed. Die andere timer vraagt wel.. -> systeem 'slaapt'.

[ Voor 11% gewijzigd door Alarmnummer op 05-01-2005 12:08 ]


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

LordLarry schreef op woensdag 05 januari 2005 @ 11:53:
Een TTimer werkt dmv Windows Messages. Dat betekend dat je de applicatie wel de tijd moet gunnen om de events af te handelen. Dat gebeurt niet als je maar heel druk code blijft executen of als je de mainthread blocked. Dat laatste doe je bijvoorbeeld met ReadLn aangezien Indy blocking is. De oplossing is of threads gaan gebruiken, maar dan moet je ook zorgen dat je code thread safe is.
Meestal maak ik een queue waarin alle invoer van de users gepost kan worden. Achter deze queue ligt 1 thread te slapen mbv een semafoor en die invoer (en andere messages) kan verwerken. Hierdoor heb je dus niets meer met concurrency control te maken.
Het is geen busy waiting probleem, maar gewoon een thread blocking probleem.
Pcies.

Verwijderd

Je doet het verkeerd imo. Zowieso is er een max aan het aantal timers wat je kunt gebruiken, dus loop je tegen problemen aan.

Normale mudcode gebruikt 1 timer, en laat alle users hier gebruik van maken. Als je bv. om de 30 seconden de regeneration etc. wilt doen, heb je 1 globale timer die een 'tick' doorgeeft aan alle users.

Ik denk dat je beter naar zoiets toe kunt gaan werken. Waarom zou je uberhaupt alle spelers een eigen timer willen geven?

Verwijderd

Topicstarter
Verwijderd schreef op woensdag 05 januari 2005 @ 13:53:
Je doet het verkeerd imo. Zowieso is er een max aan het aantal timers wat je kunt gebruiken, dus loop je tegen problemen aan.

Normale mudcode gebruikt 1 timer, en laat alle users hier gebruik van maken. Als je bv. om de 30 seconden de regeneration etc. wilt doen, heb je 1 globale timer die een 'tick' doorgeeft aan alle users.

Ik denk dat je beter naar zoiets toe kunt gaan werken. Waarom zou je uberhaupt alle spelers een eigen timer willen geven?
Ja, dat zijn de standaard muds, waarbij het vechtsysteem zwaar zuigt ;). In mijn mud typ je elke aanval/verdediging zelf in, waarna een delay komt en dan wordt de aanval/verdediging uitgevoerd/gestopt. Dit maakt de mud veel interessanter. En trouwens zoals al eerder gezegd kan ik makkelijk 3000 timers aan.... en zoveel spelers zijn NOOIT online, kan mijn verbinding niet eens aan :P.

Ik heb btw ook een globale tick timer ;) (ook eerder gezegd).

[ Voor 4% gewijzigd door Verwijderd op 05-01-2005 14:54 ]


Verwijderd

Nog steeds denk ik dat je beter 1 tick timer kan hebben die de timing van alle events regelt. Dat wil niet meteen zeggen dat je niet per gebruiker aparte ticks kan hebben, alleen dat ze door 1 thread afgehandeld worden.

Op die manier voorkom je race condities verderop in je code.

Verwijderd

Verwijderd schreef op woensdag 05 januari 2005 @ 14:53:
Ja, dat zijn de standaard muds, waarbij het vechtsysteem zwaar zuigt ;). In mijn mud typ je elke aanval/verdediging zelf in, waarna een delay komt en dan wordt de aanval/verdediging uitgevoerd/gestopt.
Hoe moet ik me dat voor me zien?

'normaal mud':

code:
1
2
3
4
5
6
7
> kill womble
the womble tickles you with its hit
you PULVERIZE the womble with your 4 slashes
..
the womble tickles you with its hit
you NEGATE the womble with your 4 deadly slashes
the womble is dead, R.I.P


Bij jou dus:

code:
1
2
3
4
5
6
> slash womble
you slash the womble
> slash womble
you slash the womble
> poke womble in eye
you poke the womble in the eye


?

Wordt een langdradig mud dan, als je elke slag moet intypen?

Verwijderd

Topicstarter
Verwijderd schreef op woensdag 05 januari 2005 @ 15:10:
[...]


Hoe moet ik me dat voor me zien?

'normaal mud':

code:
1
2
3
4
5
6
7
> kill womble
the womble tickles you with its hit
you PULVERIZE the womble with your 4 slashes
..
the womble tickles you with its hit
you NEGATE the womble with your 4 deadly slashes
the womble is dead, R.I.P


Bij jou dus:

code:
1
2
3
4
5
6
> slash womble
you slash the womble
> slash womble
you slash the womble
> poke womble in eye
you poke the womble in the eye


?

Wordt een langdradig mud dan, als je elke slag moet intypen?
Jep, maar dan met verdedigingen erbij en delays, zodat je tijd hebt om je te verdedigen. Geloof me dit is veel leuker dan kill womble intikken en dan wachten tot een van de twee dood is.

Dit vechtsysteem is onmogelijk met maar 1 timer. Dus voorstellen om 1 timer te gebruiken zijn nutteloos voor mij.

Verwijderd

Verwijderd schreef op woensdag 05 januari 2005 @ 15:25:
Jep, maar dan met verdedigingen erbij en delays, zodat je tijd hebt om je te verdedigen. Geloof me dit is veel leuker dan kill womble intikken en dan wachten tot een van de twee dood is.
Dat hoeft dan ook niet. Je kunt vluchten, je laten summonen, teleporteren, magie toepassen, enzovoort. Het mud waar ik altijd speelde was het zeker niet een geval van wachten tot een van beide dood was, je was continu bezig met de strijd. Zeker als je avatar werd, en je het goto commando kreeg. De avatar mobs die enige spullen hadden waar je wat aan had, moest je echt een heel plan voor hebben om ze om zeep te helpen, de juiste wapens en spreuken op de juiste tijd, en was je meerdere runs bezig om 'm dood te krijgen.

Maar goed, dat is weer een heel andere discussie :P

Verwijderd

Topicstarter
Verwijderd schreef op woensdag 05 januari 2005 @ 15:28:
[...]


Dat hoeft dan ook niet. Je kunt vluchten, je laten summonen, teleporteren, magie toepassen, enzovoort. Het mud waar ik altijd speelde was het zeker niet een geval van wachten tot een van beide dood was, je was continu bezig met de strijd. Zeker als je avatar werd, en je het goto commando kreeg. De avatar mobs die enige spullen hadden waar je wat aan had, moest je echt een heel plan voor hebben om ze om zeep te helpen, de juiste wapens en spreuken op de juiste tijd, en was je meerdere runs bezig om 'm dood te krijgen.

Maar goed, dat is weer een heel andere discussie :P
Hier dit is een log van een andere mud waar ik ook aan heb meegewerkt.
*klik* veel meer actie.. veel meer variatie... teminste wat skill wat je moet hebben, ik heb ook zulke muds gespeeld met magie enzo... maar die zijn saai :P echt als je dit hebt gespeeld wil je niet meer anders, maargoed is inderdaad een andere discussie.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

En ben je intussen al achter de fout?

Verwijderd

En 1 enkele timer weerhoudt je er ook niet van om verschillende delays te laten plaatsvinden op acties.

Je kunt bijvoorbeeld actie Aanval schedulen voor over 3 seconden, en actie Verdedig voor over 2 seconden met een een duur van 2 seconden, om maar iets te noemen.

Ik denk dat jouw systeem eerder een probleem heeft als mensen meerdere opdrachten na elkaar ingeven, want hoe ga je daarmee om?

Elke keer de timer resetten en alleen het laatste commando uitvoeren?

Verwijderd

Topicstarter
Verwijderd schreef op woensdag 05 januari 2005 @ 15:32:
En 1 enkele timer weerhoudt je er ook niet van om verschillende delays te laten plaatsvinden op acties.

Je kunt bijvoorbeeld actie Aanval schedulen voor over 3 seconden, en actie Verdedig voor over 2 seconden met een een duur van 2 seconden, om maar iets te noemen.

Ik denk dat jouw systeem eerder een probleem heeft als mensen meerdere opdrachten na elkaar ingeven, want hoe ga je daarmee om?

Elke keer de timer resetten en alleen het laatste commando uitvoeren?
@Alarmnummer:
Allang lees maar terug... Application.ProcessMessages heeft het opgelost.

@OnofBorg:
Je kunt maar 1 ding tegelijk doen in een gevecht of blokkeren of aanvallen als je blokkeerd terwijl je aanvalt word je aanval geannuleerd :)

Als je een timer daarvoor gebruikt kun je niet op ELK precies moment een aanval kunt beginnen, omdat je aanval pas begint op de onTimer van de globale timer....

Maargoed het werkt nu :) als je het wil uitproberen typ je dit in bij uitvoeren
"telnet 84.28.12.69 6666" maar stel je er nog niet teveel bij voor... is nog een alfa versie, ben er pas 3 dagen mee bezig.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op woensdag 05 januari 2005 @ 15:40:
[...]
@Alarmnummer:
Allang lees maar terug... Application.ProcessMessages heeft het opgelost.
Ik heb niet bepaald de indruk dat je begrijpt wat er fout gaat (of dat je begrijpt wat er eigelijk onder de grond gebeurt). Dus vandaar mijn vraag: ben je al achter de fout? en niet: heb je het probleem opgelost?

Verwijderd

Topicstarter
Alarmnummer schreef op woensdag 05 januari 2005 @ 15:48:
[...]

Ik heb niet bepaald de indruk dat je begrijpt wat er fout gaat (of dat je begrijpt wat er eigelijk onder de grond gebeurt). Dus vandaar mijn vraag: ben je al achter de fout? en niet: heb je het probleem opgelost?
Ik weet wat de fout WAS. De message van de timer werd niet afgehandeld, en nu checkt ie elke 10ms of er messages zijn en die handelt ie nu af. ;)

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op woensdag 05 januari 2005 @ 15:52:
[...]


Ik weet wat de fout WAS. De message van de timer werd niet afgehandeld, en nu checkt ie elke 10ms of er messages zijn en die handelt ie nu af. ;)
Maar snap je ook waarom die messages niet werden afgehandeld? Snap je wat LordLarry heeft toegevoegd dat het probleem heeft opgelost? Dus snap je het verschil tussen jouw aanpak en zijn aanpak?

Kijk... als goeie developer heb je met dit soort problematiek niet behoefte aan een oplossing, maar aan begrip. Threading kan echt godsellendig complex zijn, maar hoeft het niet altijd te zijn. Het gaat mij erom dat mensen zitten zo van ohhhhh... en ahhhhh... twas niet zo eng als het eruit zag.

Trouwens lordlarry zijn oplossing is ook niet perfect. Stel dat je 100 users hebt, en maar 1 van die users doet iets. Dan zal het gemiddeld 100x10ms = 1 seconde duren voordat hij een commando kan invoeren. Dus op het moment dat jouw server door veel mensen gebruikt gaat worden is de kans erg groot dat hij onresponsive gaat worden.

[ Voor 22% gewijzigd door Alarmnummer op 05-01-2005 16:04 ]


Verwijderd

Topicstarter
Alarmnummer schreef op woensdag 05 januari 2005 @ 15:59:
[...]


Maar snap je ook waarom die messages niet werden afgehandeld? Snap je wat LordLarry heeft toegevoegd dat het probleem heeft opgelost? Dus snap je het verschil tussen jouw aanpak en zijn aanpak?

Kijk... als goeie developer heb je met dit soort problematiek niet behoefte aan een oplossing, maar aan begrip. Threading kan echt godsellendig complex zijn, maar hoeft het niet altijd te zijn. Het gaat mij erom dat mensen zitten zo van ohhhhh... en ahhhhh... twas niet zo eng als het eruit zag.
Ik snap het wel hoor, ik had al een soortgelijke oplossing geprobeerd (zie topicstart), maar daar had ik niet application.processmessages bij gezet. Ik snap het wel hoor don't worry ik programmeer al 4 jaar in delphi en heb al meer dan genoeg gemaakt ;) Zelfs betaald. Zelfs ervaren programmeurs kijken wel eens ergens overheen.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op woensdag 05 januari 2005 @ 16:02:
[...]
Ik snap het wel hoor, ik had al een soortgelijke oplossing geprobeerd (zie topicstart), maar daar had ik niet application.processmessages bij gezet. Ik snap het wel hoor don't worry ik programmeer al 4 jaar in delphi en heb al meer dan genoeg gemaakt ;) Zelfs betaald. Zelfs ervaren programmeurs kijken wel eens ergens overheen.
*is Java aap*... Er zijn ook genoeg professionele java apen die ook nog steeds niets met threading kunnen. Een thread opstarten is simpel.. maar om een goed ontwerp op te zetten.. vooruit kunnen kijken om de consequenties te kunnen overzien is een 2e. Threading voegt een nieuwe dimensie van problemen toe waar maar weinig mensen kaas van hebben gegeten.

Verwijderd

Topicstarter
Alarmnummer schreef op woensdag 05 januari 2005 @ 16:04:
[...]

*is Java aap*... Er zijn ook genoeg professionele java apen die ook nog steeds niets met threading kunnen. Een thread opstarten is simpel.. maar om een goed ontwerp op te zetten.. vooruit kunnen kijken om de consequenties te kunnen overzien is een 2e. Threading voegt een nieuwe dimensie van problemen toe waar maar weinig mensen kaas van hebben gegeten.
Mjah is ook de eerste keer dat ik een applicatie in delphi maak met threads. Heb ik wel op school al mee gewerkt maar dat was in c/c++, is toch wat anders. Maargoed. Ik heb gewoon weer wat nieuws erbij geleerd ;).
Pagina: 1