Programm stoppt

[Fallenzer]

Tut mir Leid, aber Delphi.Narium's Tipp hat nicht geklappt...

[Delphi.Narium]

Ok, mit 14 Jahren muss Du noch nicht allzuviel Erfahrung haben Das kommt schon mit der Zeit.

Was mich ein bisserl irritiert:((Image1.Top=imagetop+(50*6)) or (Image1.Top=imagetop+(50*5)) or (Image1.Top=imagetop+(50*4)) or (Image1.Top=imagetop+(50*3)) or (Image1.Top=imagetop+(50*2)) or (Image1.Top=imagetop+(50*1)))) then
50 * 6 ist immer 300
50 * 5 ist immer 250
50 * 4 ist immer 200
50 * 3 ist immer 150
50 * 2 ist immer 100
50 * 1 ist immer 50
und
50 * 0 ist immer 0

Statt jedesmal rechnen zu lassen, schreib dort einfach jeweils die Ergebnisse hin. Spart (vermutlich) Rechenzeit (ein bisserl ) und macht den Quelltext lesbarer.

Kannst Dafür aber auch Konstanten definieren, die Du dann im ganzen Programm benutzen kannst. Sollte dann mal eine Änderung nötig sein, so musst Du nur die Konstanten ändern und nicht im ganzen Programm nach den Stellen im Quelltext suchen, in denen Du letztlich immer die gleichen Berechnungen vorgenommen hast. Sollte es also mal erforderlich sein, statt der 50 eine 60 zu nehmen, so kannst Du einfach Deine Konstanten ändern und musst nicht nach "tausenden" 50 im Programm suchen und sie durch 60 ersetzen.

Bei der VCL immer de Standardnamen zu verwenden, kann man so machen. Das hab' ich mir aber längst abgewöhnt. Label heißen bei mir z. B. immer lbEineaussagekräftigeBezeichnung. Desgleichen für Edits, Buttons ...
Ich will halt beim Lesen des Quelltextes auch bei Controls der VCL immer wissen, wofür sie da sind und nicht erst immer im Formular nachschauen müssen oder mir merken wofür Label1 ist, wofür Label2 ist. Spätestens wenn man mal in mehreren Programmen "unterwegs" ist, kann man sich die Standardnamen und ihren Verwendungszweck nicht mehr merken. Ist jetzt Label1 in diesem Programm für Aufgabe X oder war das in dem anderen Programm so und hier ist es für Aufgabe Y ...

Wenn die Labels aufhören sich zu bewegen, ist dann im Taskmanager noch zu sehen, ob das Programm arbeitet oder ist dort die CPU-Last niedrig.

Könnte es sein, dass bei den Berechnungen irgendwann ein Punkt erreicht ist, bei dem die Berechnungsergebnisse einfach nicht mehr zu einer Bewegung der Labels führen?

[Uwe Raabe]

Zitat von Delphi.Narium:

Statt jedesmal rechnen zu lassen, schreib dort einfach jeweils die Ergebnisse hin. Spart (vermutlich) Rechenzeit (ein bisserl ) und macht den Quelltext lesbarer

Das ist gar nicht nötig - das erledigt bereits der Compiler (übrigens auch wenn die 50 als Konstante deklariert ist).

[Delphi.Narium]

Ok, keine Rechenzeit gespart (nur (marginal?)) Kompilierzeit

Aber der Gewinn an Lesbarkeit dürfte erhalten bleiben

[haentschman]

Moin...

Zitat:

1. Falsches Forum

damit meint er nicht die DP...da bist du schon richtig, sondern das Unterforum.

Du hast es in "Neuen Beitrag zur Code-Library hinzufügen" eingestellt. Besser wäre aber "Programmieren allgemein"...oder so.

Zitat:

Ok, mit 14 Jahren muss Du noch nicht allzuviel Erfahrung haben

...alles wird gut. Trotzdem kannst du dir mal die wichtigsten Programmierregeln durchlesen:

DRY: https://de.wikipedia.org/wiki/Don%E2...epeat_yourself
KISS: https://de.wikipedia.org/wiki/KISS-Prinzip
Später SOLID: https://de.wikipedia.org/wiki/Prinzi...LID-Prinzipien

[Jumpy]

Keine Idee ob das das Problem löst, aber in der Timer-Prozedur fehlt das "labelmove(Label2);" das analog für alle anderen Labels vorhanden ist.

Bist du bereit was zu lernen und für Vorschläge wie man "sauberer" programmiert offen?
Dein Code würde kürzer und übersichtlicher werden und solche Fehler würden schneller auffallen.

Beispiel:
Diesen Block verwendest du (nur mit einem anderen Label) immer wieder im der Timer-Prozedur:

Delphi-Quellcode:

 
  begin
    Label1.Left:=labelspace;
    Label1.Font.Color:=clblack;
    punktetemporär:=punktetemporär + 10;
    Label16.Caption:=' ' + inttostr(punktetemporär);
    zufallslabel:=random(14)+1;
  end;

das könnte man in eine Prozedur auslagern und muss dass nicht immer wiederholen:

Delphi-Quellcode:

 
  procedure ResetLabelAndIncreasePoints(labe:TLabel)
  begin
    Labe.Left:=labelspace;
    Labe.Font.Color:=clblack;
    punktetemporär:=punktetemporär + 10;
    Label16.Caption:=' ' + inttostr(punktetemporär);
    zufallslabel:=random(14)+1;
  end;

und in der TimerProzedur stünde z.B.:

Delphi-Quellcode:

//...
if zufallslabel=1 then
    begin
    labelmove(Label1);
    if ((((Label1.Left <= imagespace) and (Label1.Left >= (imagespace-32)))) and 
       ((Image1.Top=imagetop+(50*8)) or (Image1.Top=imagetop+(50*7)))) then
     begin
     ResetLabelAndIncreasePoints(label1)
     end;
    end;

Nur als erster Ansatz einer Verbesserung.
Noch einfacher würde es im nächsten Schritt, wenn du alle Labels in einer Liste oder einem Array speicherst (bei Programmstart) und dann kannst du über einen Index auf ein Label zugreifen und die TimerProzedur sähe nur noch so aus:

Delphi-Quellcode:

//...
zufallszahl:=random(14)+1;  //eigentl. auch neue Prozedur ala GenerateNextZufallszahl
//...
zufallslabel:=TLabel(ListeMitLabels[zufallszahl]);
if movelabel(zufallslabel) then  //movelabel wird Funktion die True zurückgibt wenn Spielende noch nicht erreicht
  begin
  if SeltsameBedingungErfüllt then 
    begin
    ResetLabel;
    IncreasePoints;
    DisplayPoints;
    zufallszahl:=random(14)+1;
    end;
  end
else
  begin
  SendGameOverMessage;
  ResetGame;
  end;

Sorry für das Denglisch

[Fallenzer]

Genauere Daten zum if-then-Befehl:

Wenn das Label an einer bestimmten Position und das Image ebenfalls auf der MÖGLICHEN Höhe (daher auch die vielen [or]s) ist, erfolgt eine Punkthochzählung und die Generierung einer neuen Zufallszahl für die Auswahl eines neuen Labels...

Übrigens: den einen Tipp mit dem Kürzen durch eine Prozedur habe ich erfolgreich angewendet. Danke für alle Ratschläge...

...aber dennoch ist mein Problem immer noch nicht gelöst: Ich schicke euch nun eine Bildschirmaufnahme, damit ihr wisst, was für ein Problem ich genau meine....

[stahli]

Mal eine grundsätzliche Frage: Nutzt Du Haltepunkte, überwachte Ausdrücke und Debugging (schrittweise Programmausführung).

Wenn nicht, schau Dir das mal genauer an.

Du kannst auch "OutputDegugString()" verwenden, um irgendwelche Zwischenwerte oder Abläufe in der Konsole nachzuvollziehen.

Der Anfang ist halt mühsam und man muss erst mal einen Angriffspunkt finden (wie beim Tapete ablösen ).
Aber wenn Du Interesse hast, dann wird das schon...


Deine Frage ist hier derzeit etwas unkonkret.
Wenn Du genauere Fragen enger umreißen kannst, wirst Du auch mehr Hilfe bekommen.
Lass Dich nicht entmutigen, wenn es anfangs etwas holprig läuft.

[DieDolly]

Der Fehler wäre meiner Meinung nach fast sofort ersichtlich, wenn das Programm mit dem KLEINEN grünen Dreieck (mit Debugger, "Start F9" steht da im Hint) ausgeführt würde statt mit dem großen.