Delphi 7 - Kompiliertes Programm startet nicht

[TERWI]

Habe seit ca. 1 Stunde ein Prob, was ich mir nicht erklären kann:
Bin vorhin mal beim Speichern mit CTRL-Shift-S irgendwie "affglischt" und hab irgendwas anderes gedrückt.
Seit dem habe ich den Effekt, das mittels F9 anscheinend wohl neu kompiliert wird (man siehts an der sich ändernden Zeit der EXE), aber nicht startet !

Habe auch schon alles im Projektverzeichnis bis auf dpr, pas und dfm gelöscht. Tut sich nix.
Interessanterweise lässt sich auch die EXE nicht starten ....

Lade ich mal ein älteres Projekt, geht wieder alles wie gewohnt ?!

Was um Himmels Willen hab ich da angestellt ?

EDITH: OS ist XP. Kann das an AntiVir liegen oder hab ich was in WinDoof "blockiert" ?

[cookie22]

Schon mal versucht die exe via Doppelklick zu starten?

[TERWI]

Zitat:

Zitat von TERWI (Beitrag 1222498)

... Interessanterweise lässt sich auch die EXE nicht starten ....

Ja, natürlich.
Ich finde in der Registry nichts, im Antivir sehe ich so auch nix - auch den Scanner abschalten bringt nix.
Auch habe ich mal das Projekt umbenannt - keine Änderung.
Wenn ich die EXE lösche (das geht), wird immer eine neue erezugt - aber wie gesagt nicht gestartet, auch nicht manuell.

[Union]

Hast Du mal in der .dpr geschaut, ob dort überhaupt was passiert? z.b. Application.Run? Vielleicht hast Du es aus Versehen gelöscht.

[TERWI]

Hab schon alles 5x rauf und runter kontrolliert ... Die dpr ist auch ok.
Wie gesagt: Es kommt ja eine EXE zu Stande, aber:
- Delphi kompiliert ja normal, aber führt sie nicht wie gewohnt aus
- und manuell per Hand aus dem Projektverzeichnis lässt sie sich auch nicht starten.

... Wenn ich nur wüsste, was ich da aus Versehen gedrückt habe .... aaaargh.
Als wenn irgendwas auf dem Rechner sagt: Jede andere gammelige Datei, aber EBEN GENAU DIE NICHT ....

[Union]

Dann solltest Du mal debuggen ;)

[gammatester]

Hast Du den Computer schon mal komplett neu gestartet?

[TERWI]

.... rate mal, wie oft schon ... :evil:

Das völlig verrückte ist ja auch: Andere Projekte oder auch ein neu angelegtes tun es wie normal.

[gammatester]

Was heißt denn genau Läßt sich nicht starten? Sagt Windows Du, Du! Das darfst Du nicht! oder Es passiert absolut gar nichts (was erhält man über Eigenschaften, hat die Exe normale Größe?) oder Die Exe wird gestartet und termimiert sofort? (vgl. Frage was passiert beim Debuggen)

[rweinzierl]

vielleicht hilft dir ja der process monitor weiter wenn du die Anwendung ohne IDE startetst. Da solltest du zumindest sehen ob die Anwendung überhaupt losläuft,

mfg

Reinhold

[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:

Zitat von TERWI (Beitrag 1222535)

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:

Zitat von TERWI (Beitrag 1222535)

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. ...8-)

@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 ! :shock: :oops:

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:

Zitat von TERWI (Beitrag 1222554)

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. ...8-)

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:

Zitat von TERWI (Beitrag 1222554)

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:

Zitat von TERWI (Beitrag 1222554)

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:

Zitat von TERWI (Beitrag 1222554)

Ich habs übrigens raus >>> Es war mein eigener Logger ! :shock: :oops:
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:

Zitat von TERWI (Beitrag 1222562)

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

:stupid::stupid::stupid:

Zitat:

Zitat von TERWI (Beitrag 1222562)

...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:

Zitat von TERWI (Beitrag 1222562)

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. ...8-)

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 :twisted:

[Union]

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

Zitat:

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.

[Furtbichler]

Also Leute, es gibt doch tatsächlich Programmierer, die nur mit Notepad und ohne Debugger hervorragende Programme schreiben können. Ich hatte mal einen Kollegen, der aus der Java-Welt kam und dann anfing, C# zu programmieren. Da er mit diversen Threads rumhantierte, ist ihm der VS-Debugger ständig in die Quere gekommen, hat das System aufgehängt usw. Kennt man ja von Delphi.

Also hat er einfach weitergemacht, wie bisher: Loggen mit Log4Net, sonst nix.

Sein Code gehört mit zu dem aufgeräumtesten Zeugs, was ich jemals gelesen habe. Minimalistisch, robust, klar, verständlich, kommentiert. Er findet jeden Fehler beim Kunden, indem er seine Logdateien auswertet. Was will man eigentlich mehr?

Er hat natürlich seine Schwächen (Kommunikation, Kritikfähigkeit), aber wenn man auf ihn eingeht... Wahnsinn. Den Typen würde ich jeder Firma empfehlen. Allerdings verwendet er eben keinen Debugger, außer, man zwingt ihn.

Jeder hat seine eigene Methodik des Programmiererns und Fehler-findens. Ein Debugger und Breakpoints ist eine Sache (ganz praktisch), aber Logging ist eben auch nicht zu verachten. Und seien wir mal ehrlich: Powerlogging ist immer noch die beste Möglichkeit, sporadische Fehler in produktivem Code zu finden, wenn nicht sogar die einzige.

Zitat:

Zitat von TERWI (Beitrag 1222562)

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, ...

Strg-V fällt mir auf Anhieb ein. Irgendwie sowas jedenfalls. Und wenn's das nicht war, der 'unendlich viele Affen tippen wahllos und einer schreibt eben zufällig Shakespear's Lear'-Effekt.

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1222600)

der 'unendlich viele Affen tippen wahllos und einer schreibt eben zufällig Shakespear's Lear'-Effekt.

So viele Affen gibt's gar nicht :twisted:

[Furtbichler]

Zitat:

Zitat von Perlsau (Beitrag 1222617)

Zitat:

Zitat von Furtbichler (Beitrag 1222600)

der 'unendlich viele Affen tippen wahllos und einer schreibt eben zufällig Shakespear's Lear'-Effekt.

So viele Affen gibt's gar nicht :twisted:

http://de.wikipedia.org/wiki/Infinite-Monkey-Theorem

Oder in Delphi

Delphi-Quellcode:

Procedure _;
begin
  Halt;
End;

...

_; // Hupsa

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1222633)

Zitat:

Zitat von Perlsau (Beitrag 1222617)

Zitat:

Zitat von Furtbichler (Beitrag 1222600)

der 'unendlich viele Affen tippen wahllos und einer schreibt eben zufällig Shakespear's Lear'-Effekt.

So viele Affen gibt's gar nicht :twisted:

http://de.wikipedia.org/wiki/Infinite-Monkey-Theorem

Zitat aus dem Link: "... geht von einer unendlichen Anzahl von Affen aus ..."

... und so viele Affen gibt's halt in der Tat nicht :stupid: ... nicht mal, wenn man alle bisher gewesenen und in Zukunft noch seienden Affen hinzuzählt :angel:
Ich frag mich sowieso: Wieso gerade Affen? Und was soll uns diese – meiner Überzeugung nach pseudophilosophische – Philosophie (nein, nicht deine Philosophie, sondern die in Wikipedia dargestellte) eigentlich sagen? Daß alles Zufall ist? Und was ist mit der Evolutionstheorie? Und den Evolutionssprüngen? ...

Aber bevor du jetzt völlig am Boden zerstört bist: Der Gedankengang mit dem Ctrl-V leuchtet durchaus ein :thumb:

[Furtbichler]

Du hast das nicht verstanden, glaube ich. Es kann auch ein einzelner Affe Shakespear tippen, nur ist das eben sehr (um nicht zu sagen: sehr) unwahrscheinlich.

Dessenungeachtet bin ich aber eh am Boden zerstört. ;-) Per se.

Aber so viele Affen benötigt man eh nicht, um '_;' zu tippen. Außerdem tut es manchmal ein einziger!.