Horst-Dieter - Do 08.02.18 10:41
Titel: Patience 4 (Spider Solitaire)

---

Spider Solitaire ist eine schwierige Patience, die in der Regel fast
nie aufgeht. Gespielt wird eigentlich mit allen 4 Farben. Das
vorliegende Spiel startet allerdings nur mit einer Farbe, damit der
Spieler wenigstens eine Chance hat. Die schwierigeren Einstellungen
mit 2 bzw. 4 Farben lassen sich im Menü wählen.

Gespielt wird mit 2 Spielen zu je 52 Blatt. Ein Spiel wird ausgeteilt.
Die unterste Reihe liegt offen. Mit einem Doppelklick können aus
dem rechts unten liegenden Haufen weitere Karten angefordert
werden.

Das Programm ist in Delphi 7 geschrieben. Alle Komponenten werden mitgeliefert.

Delphi-Laie - Do 08.02.18 18:28

---

Der erste Eindruck ist gut, allerdings habe ich auch gleich etwas zu bemerken.

Erstmal ist das Spiel ein wenig "zäh". Liegt ihm evtl. FMX als Bibliothek zugrunde? Würde das erklären.

Weiterhin klickte ich auf den Stapel unten rechts, um neue Karten aufdecken zu lassen. Es reagierte nicht sogleich (die schon monierte Langsamkeit), also schickte ich "zur Sicherheit", ja fast schon reflektorisch, gleich noch einen Mausklick hinterher. Daraufhin wurden die nächsten Karten oben auf die Stapel verteilt, es kam aber auch eine "Access Violation". Genaue Reihenfolge weiß ich nicht mehr. Das Spiel läßt sich nach dem Wegklicken derselben aber weiterspielen.

Edit: Man benötigt wohl generell einen Doppelklick (ich kann diese winzigweiche "Erfindung" nicht ausstehen) zum neuen Aufblättern. Ändert aber nichts daran, daß ich diese Fehlermeldung hatte.

Edit 2: Erneutes Auftauchen der Fehlermeldung nach Doppelklick, diesmal habe ich sie "gesichert" (Anhang).

Edit 3: Delphi 7, also VCL-basiert...

Edit 4: Ich moniere einen recht unsauberen Quelltext. Überflüssige Variablen und Wertezuweisungen sowie nichtlokale Schleifenvariablen müssen nun wirklich nicht sein, denn die zu beseitigen, hilft der Compiler vorbildlich. Auch andere Compilermeldungen sind verhinderbar.

Edit 5: Vergleiche auf true und false sind redundant und unelegant. Ein einfaches "if" bzw. "if not" reicht.

Horst-Dieter - Do 15.02.18 10:21

---

1. Also: dass man einen Doppelclick für das Aufdecken benötigt, steht schon oben in meiner Ankündigung und außerdem in der Spielregel. Sollte man also lesen, ehe man etwas moniert.

2. Anders ist das mit der Fehlermeldung. Ich kann zur Zeit nicht sagen, woran das liegt. Ich habe das Spiel auf meinem Rechner inzwischen fast 100-mal getestet und die Fehlermeldung ist nicht auftetaucht. Ich suche aber weiter.

3. Das Spiel ist in Delphi 7 geschrieben. Hätte ich wohl sagen sollen. Wurde leider vergessen.

Delphi-Laie - Do 15.02.18 15:33

---

Horst-Dieter hat folgendes geschrieben :

1. Also: dass man einen Doppelclick für das Aufdecken benötigt, steht schon oben in meiner Ankündigung und außerdem in der Spielregel. Sollte man also lesen, ehe man etwas moniert.

Meine Abneigung / Aversion gegenüber (erst recht unnötigen) Doppelklicks steht in keiner Beziehung dazu, ob "schon oben in meiner Ankündigung" etwas dazu steht oder nicht und von mir gelesen wurde oder nicht.

Delphi-Laie - Mi 21.03.18 23:23

---

So, Horst-Dieter, ich habe jetzt so lang per Delphi-7-IDE mit Deinem Spiel gespielt, bis dieser beim ungeliebten Doppelklick leider nur äußerst sporadisch auftretende Fehler endlich mal wieder erschien. Der Debugger zeigte mir neben der Art der Ausnahme auch die entsprechende Zeile an (Anhang 1). Leider weigerte er sich nach dem Wegklicken der Meldung jedoch, den Wert einiger Variablen preiszugeben (Anhang 2).

Mehr kann ich nun wirklich nicht für Dich tun.

Edit: Doch, kann ich. Nochmals ausprobiert, der Fehler trat recht bald wieder auf. Mit F7 (vermutlich auch mit F acht) kam ich zunächst nicht weiter. Es kam stattdessen das akustische Signal der Exception, das dazugehörige Meldungsfenster entdeckte ich hinter dem Editorfenster. Weggeklickt. Daraufhin war im Editor keine Zeile mehr markiert. Es ließ sich also nicht weiter "durchsteppen".

Delphi-Laie - Do 22.03.18 17:44

---

Ich bin mir jetzt einigermaßen sicher, wo der Fehler zu lokalisieren ist bzw. eher, wo er nicht zu lokalisieren ist.

Einfache am Anfang der heiklen Prozedur "Endablage" verraten, wann diese aufgerufen wird und wann nicht. Nebenbei lasse ich vor der Zeile, an der die Ausnahme auftritt,



ausgeben (da dieses Programm nicht die normale Formulartitelleiste nutzt). Doch bisher gab es keine weitere Ausnahme, so daß diese ausgegebenen Werte nichts im Sinne der Fehlerdetektion aussagen.

Meine Beobachtung ist, daß es beim Doppelklick eben normalerweise nicht piept, bisher tat es das jedenfalls nicht. Demnach vermute ich, daß diese Endablage-Prozedur in seltenen Fällen beim Doppelklick fehlerhafterweise aufgerufen wird.

Delphi-Laie - Do 22.03.18 18:32

---

So, letzter Beitrag, zumindest vorerst. Meine Aussage zuvor stimmte nicht ganz, manchmal piept es doch nach dem Doppelklick, ohne daß eine Ausnahme auftritt. Doch jüngst hat es wieder voll zugeschlagen (Anhang), außerdem sind jetzt auch die drei Variablenwerte im Toplevel sichtbar.

Delphi-Laie - Do 22.03.18 23:17

---

So, Fehler - wahrscheinlich - gefunden. Ist recht bequem, nur ein wenig zeitaufwendig: Spielen und dabei warten.....

Der erste Anhang zeigt, daß der Index nr, benutzt für den Ausdruck Karte[nr], 0 ist. Das kann bei einem Array ab 1 natürlich nicht funktionieren. Das läßt den Verdacht auf die Funktion "Zielkartennummer" lenken.

Vor dem nächsten Auftreten einen Breakpoint beim Aufruf der "Zielkartennummer" gesetzt, beim Erreichen dort hineingesprungen, und - voilà / heureka - sie liefert am Ende tatsächlich 0 zurück!

Wundert mich, daß der Fehler bei Dir niemals aufgetreten ist.

Delphi-Laie - Fr 23.03.18 14:38

---

Die Funktion "Endablage" liefert in seltenen Fällen 0 zurück, das ist der Grund für die Fehlermeldungen. Warum sie 0 zurückliefert, weiß ich nicht.

Der nächste Fehler trat im Spielverlauf auf: Der Stapel mit den verdeckten, noch nicht aufgedeckten Karten war auf einmal "verunglückt" (s. Anhang). Anklicken ließ er sich in diesem Zustande nicht mehr.

Ergänzung: Nach dem Minimieren und dann Wiederaufrufen war er verschwunden (Anhang 2), er war wohl schon abgebaut. Dann wäre das nur eine Darstellungsfrage.

Delphi-Laie - Fr 23.03.18 18:01

---

Um das nun abzuschließen, hätte ich noch zwei Bemerkungen bzw. Anregungen:

1. Das Spiel gestaltet sich auf meinem sicher nicht mehr taufrischen Laptop etwas zäh, außerdem werden die Karten(stapel) beim Umlegen nicht gut erkannt, man muß schon recht genau zur Zielposition schieben, damit sie angenommen werden. Beides kommt mir bei Deinem Spiel Yukon [https://www.entwickler-ecke.de/viewtopic.php?t=116926] besser (gelöst) vor. Das verwundert mich insofern ein wenig, weil die Graphik und sehr wahrscheinlich auch etliches "unter der Haube" gleich bzw. prinzipiell dasselbe ist. Edit: Könnte evtl. daran liegen, daß ich das Spiel die meiste Zeit aus der IDE heraus startete.

2. Zur Spiellogik: Neue Karten kann man nur austeilen, wenn alle Leerpositionen mit Karten(stapeln) gefüllt sind. Ich weiß nicht, ob so die Regeln sind, aber diese sind keine Naturgesetze, sondern Menschenwerk und damit änderbar. Es sind nämlich m.E. Spielsituationen möglich (wohl ziemlich selten, mir jedenfalls noch nicht untergekommen), daß gar nicht mehr genug Karten dafür vorhanden sind, weil die Karten so günstig konstelliert waren, daß schon reichlich abgebaut werden konnte -> Spiel kann nicht enden.