Delphi 7 - Kompiliertes Programm startet nicht

[DeddyH]

Einfach mal in der IDE F7 drücken und schauen, was passiert, das würde ich zuerst versuchen.

[TERWI]

Eben das auch nicht: Kein Gemotze von Windoof, keine Meldungen.
Steht auch nichts in der Taskleiste wie ein minimiertes Fenster.
"Sieht" aus wie Fenster auf und gleich wieder zu - aber so schnell, das man nix sieht.
Ich zitiere Heinz Erhardt: "Wie sie sehen, sehen sie nix !"

Debugger ..... jetzt bekomme ich bestimmt Haue, weil ...
Seit es Delphi gibt, habe ich noch NIEMALS damit gearbeitet und selbst die dicksten Projekte jelativ problemlos gestemmt.
Ich hab mir schon vor vielen Jahren so eine Art kleinen Logger gebastelt, den ich immer in meiner Programme mir reinhänge. Finde ich wesentlich praktischer. Jedem Tierchen sein Pläsierchen ....

Das dieses Projekt noch nicht so riesig ist, werde ich erstmal div. Formen und Units "kaltstellen".
Irgendwo wird der Hammer kreisen.

[Union]

Zitat von TERWI:

Debugger ..... jetzt bekomme ich bestimmt Haue, weil ...
Seit es Delphi gibt, habe ich noch NIEMALS damit gearbeitet und selbst die dicksten Projekte jelativ problemlos gestemmt.

Dann ist Dir nicht zu helfen. Programmierer die nicht debuggen kommen in die Hölle. Viel Spass mit Deinem Logger.

[cookie22]

Zitat von TERWI:

Debugger ..... jetzt bekomme ich bestimmt Haue, weil ...
Seit es Delphi gibt, habe ich noch NIEMALS damit gearbeitet und selbst die dicksten Projekte jelativ problemlos gestemmt.

Wie überpfrüfst du denn dein Programm auf Fehler ohne das du Debugst. Mit F9 startest du ja schon den Debugger. Mit F7 und F8 kannst du durch das Programm springen.

Dir wird wohl nix anderes übrig bleiben als den Debuggen zu Nutzen.

[TERWI]

@Union
Nix für ungut ... aber wer Stück für Stück mit KnowHow programmiert, bei dem halten sich (dubiose) Fehler (meist) in Grenzen. Wie bei mir z.B. ...

@cookie22
A) in dem ich kontrolliert progge und nicht alles gleichzeitig tippe oder planlos irgendwelchen Code kopiere und
B) ... mit meinem eigenen Logger halt.
Oder wenn es elementare Dinge zu meckern gibt, sagt mir die IDE schon "Bescheid".
Zu 99,5% sehe ich aus dem Ablauf und der Fehlermeldung, welchen Bockmist ich gebaut habe.
Wo ist dann auch nicht schwer zu ermitteln, wenn man weiss, was man (eben) gemacht hat.

Der Debugger ist in der IDE hier übrigends überwiegend abgeschaltet.
Nur in Notfällen wie jetzt mache ich da mal wieder ausnahmsweise den Haken rein.
... Wenn ich das schon sehe, wenn ich das Stepweise mit F7 durchrutsche (-n soll) und die Anzahl der geladenen Forms & Units nimmt exorbitant zu ..... wo ist da ne Übersicht ?


Ich habs übrigens raus >>> Es war mein eigener Logger !

Mit diesem unkontrolliertem "Affengriff" heute Mittag scheint sich da eine Zeile eingeschlichen zu haben, die den Logger selbst noch vor vollständiger Initialisierung aufgerufen hat.
So was kenne ich zwar ala "ungültige Adresse aufgerifen/beschrieben" - aber hier scheint's gleich das ganze Programm vollständig aus der Kurve gehauen zu haben.
Hatte ich bisher noch nicht - in mehr als 20 Jahren mit Pascal und Delphi.

[Perlsau]

Zitat von TERWI:

Nix für ungut ... aber wer Stück für Stück mit KnowHow programmiert, bei dem halten sich (dubiose) Fehler (meist) in Grenzen. Wie bei mir z.B. ...

Niemand ist unfehlbar! Wie willst du ohne Debugger den aktuellen Zustand deiner Anwendung herausfinden? Ein Logger ist nur ein primitiver Ersatz für den Debugger. Mit Hilfe des Debuggers findest du dubiose Fehler weitaus schneller als mir irgend welchen Logdateien ...

Zitat von TERWI:

A) in dem ich kontrolliert progge und nicht alles gleichzeitig tippe oder planlos irgendwelchen Code kopiere und
B) ... mit meinem eigenen Logger halt.
Oder wenn es elementare Dinge zu meckern gibt, sagt mir die IDE schon "Bescheid".
Zu 99,5% sehe ich aus dem Ablauf und der Fehlermeldung, welchen Bockmist ich gebaut habe.
Wo ist dann auch nicht schwer zu ermitteln, wenn man weiss, was man (eben) gemacht hat.

Offenbar wußtest du im vorliegenden Fall eben nicht, was du eben gemacht hattest. Hier helfen Breakpoints ungemein. Auch ein weiterer "Trick" sei dir nicht vorenthalten: Wenn dir sowas nochmal passiert, daß du irgendwie auf der Tastatur abrutschst und sich dadurch fehlerhafter Code in deine Anwendung einschleicht, gehe folgendermaßen vor:

1. Kopiere den gesamten Code der jewweiligen Unit, die du gerade zu untersuchen gedenkst, in eine Textdatei (Ctrl-A im Delphi-Editor, danach Ctrl-C, danach im Notepad o.ä. Ctrl-V und abspeichern.
2. Arbeite dich mit der Rückgängig-Funktion durch deine Unit und du erhältst einen genauen Verlauf deiner Tipp-Aktionen in dieser Unit.
3. Am Ende den abgespeicherten Code wieder einfügen.
4. Falls du den Fehler beim durcharbeiten mit der Rückgängig-Funktion gefunden hattest, kannst du jetzt die Korrektur vornehmen. Sämtliche nach dem Vertippen editierten Zeilen bleiben dir ja erhalten.

Zitat von TERWI:

Der Debugger ist in der IDE hier übrigends überwiegend abgeschaltet.
Nur in Notfällen wie jetzt mache ich da mal wieder ausnahmsweise den Haken rein.
... Wenn ich das schon sehe, wenn ich das Stepweise mit F7 durchrutsche (-n soll) und die Anzahl der geladenen Forms & Units nimmt exorbitant zu ..... wo ist da ne Übersicht ?

Du scheinst dich von der Verwendung des Debuggers durch die Anzeige von System-Units abschrecken zu lassen. Letzteres kannst du jedoch unterbinden, indem du in den Projekt-Optionen das Debuggen externer Units nicht zuläßt.

Zitat von TERWI:

Ich habs übrigens raus >>> Es war mein eigener Logger !
Mit diesem unkontrolliertem "Affengriff" heute Mittag scheint sich da eine Zeile eingeschlichen zu haben, die den Logger selbst noch vor vollständiger Initialisierung aufgerufen hat.
So was kenne ich zwar ala "ungültige Adresse aufgerifen/beschrieben" - aber hier scheint's gleich das ganze Programm vollständig aus der Kurve gehauen zu haben.
Hatte ich bisher noch nicht - in mehr als 20 Jahren mit Pascal und Delphi.

Und wie hast du das jetzt rausgefunden? Würde mich wirklich interessieren!

Auch würde mich interessieren, wie man mit einem versehentlichen Tastatur-Verrutscher eine ganze Zeile Code in eine Unit einfügen kann, der auch noch Gültigkeit besitzt und keinen Compiler-Fehler auslöst ...

[TERWI]

Zitat:

Auch würde mich interessieren, wie man mit einem versehentlichen Tastatur-Verrutscher eine ganze Zeile Code in eine Unit einfügen kann, der auch noch Gültigkeit besitzt und keinen Compiler-Fehler auslöst ...

Wenn ich darauf ne Antwort hätte, wüsste, ...

Zitat:

Und wie hast du das jetzt rausgefunden? Würde mich wirklich interessieren!

In dem ich logisch vorgehe - ala deinem Vorschlag mit CTRL-Z. Was hab ich zuletzt gemacht, eingebunden, verändert ?
Bei meinem Logger war das einfach, den auszuklinken - in der dpr ausmarkieren und jede Unit/Form, die den benutzt, hat bei mir so was wie einen "Sammel-Call" an den Logger, den ich auch nur per Unit einmal aushaken muss.

Dein CTRL-Z-Beispiel und dazugehöriges ist ehrlich gesagt ein uralter Hut hier.
Das sind so ganz allgemeine Dinge, die ich als erstes teste.
Allerdings: Bei mir ist Ctrl-Shift-S schon ein so "eingesesener" Handgriff, dass ich mich immer beherschen muss, das nicht automatisch zu machen.
Denn: Zumindestens in meiner Delphi 7 Professional Version ist da nix mehr mit Rückgängig nach Speichern !

Ich hab übrigends eben den Debugger wieder abgeschaltet.
Wenn ich z.B. was mit try ... except prüfe und es bewusst mal im laufenden Programm ausprobieren will, haut mir dieses Teil ewig dazwischen und ich muss erst mal wieder mit Ctrl-F2 den Sarotti resetten.
Wahrscheinlich kann man das irgendwo auch abstellen, aber wie gesagt bin ich bisher auch immer gut ohne damit klar gekommen.

[cookie22]

Zitat von TERWI:

...Ich hab übrigends eben den Debugger wieder abgeschaltet...

Zitat von TERWI:

...in mehr als 20 Jahren mit Pascal und Delphi...

Denn: Zumindestens in meiner Delphi 7 Professional Version ist da nix mehr mit Rückgängig nach Speichern !

Dir ist in 20 Jahren Pascal und 10 Jahren Delphi 7 nicht aufgefallen, dass es da diese geheime Option gibt, mit der man Rückgänig nach Speichern hat?

[Perlsau]

Zitat von TERWI:

In dem ich logisch vorgehe - ala deinem Vorschlag mit CTRL-Z. Was hab ich zuletzt gemacht, eingebunden, verändert ?
Dein CTRL-Z-Beispiel und dazugehöriges ist ehrlich gesagt ein uralter Hut hier.
Das sind so ganz allgemeine Dinge, die ich als erstes teste.

Also das kommt mir nun doch langsam alles sehr merkwürdig vor: Du hast dir also meinen Vorschlag zu Herzen genommen und bist deine letzten Veränderungen im Quelltext durchgegangen. Soweit so gut. Dann jedoch bezeichnest du meinen Vorschlag plötzlich als alten Hut, der angeblich zu den ganz allgemeinen Dingen gehöre, die du als erstes zu testen vorgibst. Es stellt sich doch hier die Frage, weshalb du es in diesem Fall dann nicht gleich gemacht hattest, insbesondere da du ja im Eingangsposting schreibst:

Zitat:

Habe seit ca. 1 Stunde ein Prob, was ich mir nicht erklären kann

und etwas später:

Zitat:

Hab schon alles 5x rauf und runter kontrolliert

In meinem Gemüt entsteht langsam der Eindruck, du möchtest dich irgendwie profilieren als jemand, der absolut keine Fehler macht:

Zitat:

Seit es Delphi gibt, habe ich noch NIEMALS damit gearbeitet und selbst die dicksten Projekte jelativ problemlos gestemmt.

oder:

Zitat:

Nix für ungut ... aber wer Stück für Stück mit KnowHow programmiert, bei dem halten sich (dubiose) Fehler (meist) in Grenzen. Wie bei mir z.B. ...

oder:

Zitat:

in dem ich kontrolliert progge und nicht alles gleichzeitig tippe oder planlos irgendwelchen Code kopiere

Natürlich mußt du auf dieses doch eher persönliche Posting nicht antworten, wenn es dir peinlich ist

[Union]

So etwas hab ich schon mal kennengelernt, ich hab tatsächlich den Bericht noch gefunden:

Zitat von Interner Bericht:

Fachliche Mängel

Hält sich nicht an vereinbarte Konventionen
Checkt Programme nicht aus vor dem Bearbeiten. Folge: Von anderen Programmierern durchgeführte Änderungen werden rückgängig gemacht.
Verwendet nicht die vorgegebenen Werkzeuge
Weigerte sich lange, einen Debugger zu benutzen. Folge: Findet seine Programmierfehler nicht oder braucht unangemessen lange dafür. Die eingebauten Bildschirmnachrichten zur Fehlersuche werden nach Beendigung der Arbeiten teilweise nicht entfernt und erscheinen dann auch im fertigen Produkt.

Benutzt einen eigenen Editor
Setzt undokumentierte Fremdprogramme ein, die dann auch in die Produktion gelangen, informiert aber erst auf Rückfrage, worum es sich bei diesen handelt.

Testet nicht
Folge: Der Funktionale Test muss durch die Endbenutzer erfolgen. In einigen Fällen auch durch die Kollegen, wenn diese von ihm fehlerhafte geänderte oder erstellte Programmroutinen mitbenutzen.
In einem Fall ließ sich ein von Ihm geändertes Programm nicht einmal mehr compilieren.

Dokumentiert mangelhaft
Es ist teilweise nicht nachvollziehbar (außer durch Vergleich mit einem RCS) welche Änderungen wann und von wem durchgeführt wurden. Andere Programmierer haben dadurch Probleme, von ihm bearbeitete Programm zu verstehen. Dies resultiert evtl. in Folgefehlern, mindestens aber in einem erhöhten Zeitaufwand.

Übersieht nicht den Arbeitsumfang
Verschafft sich keinen Überblick über die Art und Auswirkung der übernommenen Aufgaben. Betreibt keine Forderungsanalyse. Dadurch kommt es z.B. in vom ihm überarbeiteten Programmteilen zu Verlusten in der Funktionalität im Gegensatz zu vorher: Bei der Überarbeitung eines Programmes ließ er die Hälfte aller Bearbeitungsoptionen weg. Das läßt darauf schließen, dass er den zu ändernden Sourcecode vor der Bearbeitung nicht analysiert.

Arbeitet schlampig
Korrigiert nicht die von anderen übernommenen Testdaten und Konfigurationen. Dadurch verändert er ggf. dann Daten anderer Programmierer oder in der Produktion.

Kommunikative Mängel
Berichtet nicht über seinen Arbeitsfortschritt, dies verunsichert die Leitung. Nimmt Vorschläge und Kritik nicht auf, dadurch macht er mehrmals die gleichen oder gleichartige Fehler.

Zeigt offen sein Desinteresse
Bei fachlichen Gesprächen, die normalerweise sein Interesse wecken sollten, hört er, wenn überhaupt, nur sehr kurz zu und beschäftigt sich dann mit etwas anderem. Ist er gezwungen, weiterhin teilzunehmen, z.B. in einem per Termin angesetzen Meeting, so kann er sein Schlafbedürfnis kaum zügeln.

Sitzt oft mit auf die Hand gestütztem Kinn vor seinem Rechner und tut beobachtbar nichts für längerere Zeit.
Übernimmt generell keine Supportfälle, wird er dazu genötigt so läßt er den Hilfesuchenden zuerst aufwändig sein Problem schildern und gibt dann den Hörer ohne Reaktion an einen Kollegen weiter.
Übernimmt keine Telefonate, auch wenn er allein im Büro ist.

Beispiele

7.2.2xxx Schläft während der Arbeit. Durch Abspielen einer sehr lauten Trompete auf dem Computer wird er durch die Kollegen geweckt.
1.3.2xxx Kompiliert Programm und sieht Fehlermeldung auf dem Bildschirm. Kopiert danach ohne Überprüfung die alte Version. Dies wurde dann vom Fachbereich beim Testen festgestellt.
12.3.xxx Hat die geringste Anzahl an Programmänderungen bearbeitet, aber die höchste Anzahl an Fehlern. Insgesamt 47 Fehlermeldungen, davon 26 für ihn. Alleine eine Anforderung musste 8 mal korrigiert werden und läuft bis heute nicht. Die in den Routinen enthaltenen Fehler führten im Test zu einem nahezu kompletten Datenverlust, so daß der Test komplett neu aufgesetzt werden musste. Alle von den Fachabteilungen erarbeiteten und vorbereiteten Daten gingen verloren bzw. wurden unbrauchbar gemacht.