"Nicolai Hansen" <nic@aub.dk> wrote in message
news:4040fa46$0$27400$edfadb0f@dread16.news.tele.dk...
> > Hvis man insisterer på at gøre livet surt for sig selv kan man da godt -
> det
> > var blot netop den slags, det var intentionen med OOP at undgå. Det
virker
> i
> > høj grad som om du vil programmere ustruktureret i et OOP-program, og
> heller
> > ikke vil bruge de instrumenter indenfor OOP som oprindelig var tiltænkt
> den
> > funktion, at de skulle gøre livet lettere for programmøren ift de
> klassiske
> > fejlkilder, som uværgerligt opstår ved ustruktueret programmering
>
> Jamen dog :) Jeg programmerer skam ret struktureret. Jeg åbner bare ikke
> mine programmer for unødvændige fejlkilder og gør alt for at synkronisere
> dem 100%. Det er vist god programmerings skik.
Ja - jeg påstår skam heller intet af slig slags overhovedet, det var bare et
interessant synspunkt du lagde for dagen.
> Lad mig give et OOC eksempel på det der er nævnt i den anden tråd:
> Du laver et rumskibsskydespil. Du har to knapper - en til at dreje
rumskibet
> mod højre, og en til at dreje det mod venstre. Du drejer begge retninger
vha
> en lille animation. Den tager tid, og du bruger
Application.ProcessMessages
> for at få skærmen optegnet.
Det ville jeg nu ikke....
> Du drejer mod højre. I dit objekt ligger der en "FGrader" som er din
vinkel
> .. denne incrementeres langsomt i dit loop indtil den når en fast værdi
(90
> grader). Du fortryder. Klikker på venstre knappen. Nu decrementeres din
> FGrader i objektet langsomt. Den når sit max udsving (-90 grader). Rutinen
> er færdig. Ryger tilbage til højre drejningen, og drejer helt over til +90
> grader igen.
> Det der BURDE være sket var enten at du drejede først helt til højre,
> dernæst helt til venstre.
>
> Bare et lille tænkt eksempel - ja der er smartere måder at gøre dette på.
>
Jeg forstår godt hvad du beskriver. Jeg ved ikke hvordan du ville
implementere det, men jeg ville have en særskilt tråd for keyboard/joystick,
whatever, som uophørligt aflæste brugerens input - lad os blot sige
keyboardstate. Ved siden af ville jeg jeg have en proces, en "styreoproces"
der tog imod input formidlet af denne tråd, evt eksekveret direkte som kald
eller via messages, i en kø, som foretager den bagvedliggende kontrol eller
logik. Skærmen opdateres blot kontinuerligt - f.eks på tid, lad os sige 2
gange i sekundet, hvadenten brugeren har foretaget et input eller ej. Flowet
i programmet ser således ud, SU er skærmopdatering
|-->aflæs evt input-->kald "styreproces" ->tæl ned/op=højre venstre-|
|<--------------------------------------------------------------------------
------------------|
SU SU SU SU
SU
Opdatering af skærm sker uafhængigt - "print"-rutinen danner skærmbilledet
ud fra værdier den læser på objekter, blandt andet styreprocessen og i
lookuplister. De enkelte input (højre/venstre) udelukker ikke hinanden -
højre/venstre ligger ikke i særskilte rutiner eller eksekveres separat - der
eksekveres blot fortløbende og øjeblikkeligt ordren til en kø om at gå til
højre eller venstre, og det ændrer blot en værdi, nemlig FGrader, i
styreprocessen - reaktionen ses først når skærmen opdateres. Hvordan det
virker eller "tager sig ud" ift din beskrivelse, afhænger så af den
reaktionshastighed man ønsker - man kan vælge at aflæse tastaturet med
standard repeatrate etc som det er, eller sætte den efter en
følsomhedsskala, endda én som brugeren måske kan få lov at indstille - det
samme mht joystick og mus. Det kan betyde, rent virkningsmæssigt/visuelt, at
rumskibet ikke reagerer præcis med det samme, men lissom' skal bruge energi
på at stoppe den allerede begyndte drejning og nu dreje modsat - men det kan
også præsenteres som om brugeren kan dreje og reagere knivskarpt og hurtigt,
hvis man sætter inputaflæsningshastigheden en smule ned, da mængden af
ordrer til køen dermed bliver mindre.