Was nervt euch so, während der Programmierung oder so allgemein

[jaenicke]

Zitat:

Zitat von Aphton (Beitrag 1111025)

Ich hasse Turbo Delphi mittlerweile. Es gibt aber nichts "besseres" momentan >.>

Du meinst wohl kostenlos...
Denn die XE Starter halte ich trotz der Einschränkungen für besser, auch wenn man im Vergleich zu Turbo Delphi leider Abstriche z.B. in der Codenavigation und dem Debuggen machen muss (2 Einschränkungen schießen da übers Ziel hinaus, aber was solls).
Und 150€ sind für das Produkt trotzdem angemessen.
So viel ist das dann auch nicht. Wenn man sich alleine anschaut was manche für Handys bezahlen... Oder was manche für einen angebissenen Apfel auf einem Produkt mehr als für normale Produkte bezahlen... Oder für andere Hobbys...

Zitat:

Zitat von Stevie (Beitrag 1111039)

Internal Errors sind im Grunde Assertions, die niemals auftreten sollten (in etwa so wie eine nicht gehandelte Exception in deinem Programm, die dem Endbenutzer entgegen kommt) und die Zahlen deuten auf die Stelle im Code hin und sind demnach für die Devs bei Emba nützlich um den Fehler zu finden.

Nichtsdestotrotz wäre eine Liste sehr hilfreich, in der zumindest grob drinsteht was an der Stelle abgefangen wird...
Dass das dann nicht immer zum Fehler führt und dass es nicht immer möglich ist viel zu einer solchen Codestelle zu schreiben, ist klar, aber zumindest bei einigen Fehlern wären sicher Hinweise möglich.

Reproduzierbare Fälle sind ja kein so großes Problem, die kann man melden, aber bei welchen, die nicht einmal auf anderen PCs mit dem gleichen Projekt reproduzierbar sind...
Es ist echt nicht lustig dann per Assembler und Process Monitor zu debuggen. Oft lässt es sich dann zwar lösen, aber es kostet extrem Zeit, wenn man nicht einmal einen Ansatz hat wonach man suchen könnte...

Wo wir gerade beim Compiler sind: An der Stelle wäre auch ein Debuglog interessant, in dem man sehen kann welche Dateien in welchen Pfaden in welcher Reihenfolge abgearbeitet wurden, damit man da nicht im Process Monitor suchen muss.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1111059)

Zitat:

Zitat von Stevie (Beitrag 1111039)

Internal Errors sind im Grunde Assertions, die niemals auftreten sollten (in etwa so wie eine nicht gehandelte Exception in deinem Programm, die dem Endbenutzer entgegen kommt) und die Zahlen deuten auf die Stelle im Code hin und sind demnach für die Devs bei Emba nützlich um den Fehler zu finden.

Nichtsdestotrotz wäre eine Liste sehr hilfreich, in der zumindest grob drinsteht was an der Stelle abgefangen wird...
Dass das dann nicht immer zum Fehler führt und dass es nicht immer möglich ist viel zu einer solchen Codestelle zu schreiben, ist klar, aber zumindest bei einigen Fehlern wären sicher Hinweise möglich.

Reproduzierbare Fälle sind ja kein so großes Problem, die kann man melden, aber bei welchen, die nicht einmal auf anderen PCs mit dem gleichen Projekt reproduzierbar sind...
Es ist echt nicht lustig dann per Assembler und Process Monitor zu debuggen. Oft lässt es sich dann zwar lösen, aber es kostet extrem Zeit, wenn man nicht einmal einen Ansatz hat wonach man suchen könnte...

Wo wir gerade beim Compiler sind: An der Stelle wäre auch ein Debuglog interessant, in dem man sehen kann welche Dateien in welchen Pfaden in welcher Reihenfolge abgearbeitet wurden, damit man da nicht im Process Monitor suchen muss.

Zur einer "Dokumentation" zu den Internals hat Allen mal was gesagt und erwähnt, dass dies ein administrativer Overhead wäre, der nicht viel nützen würde. Die Info Build No + Internal Error No ist genug Information für die Devs.

Ich persönlich hatte noch nie einen nicht reproduzierbaren Internal, von daher kann ich nichts dazu sagen.

Zum Debugger Log kann ich nur zustimmen, das würde auch das reporten der Internals etwas vereinfachen. Denn wenn er wie bei dir mal nicht reproduzierbar ist, ist es schwer einen QC zu erstellen, wenn man keine Beschreibung zum Reproduzieren geben kann. Vielleicht sollten sie madExcept oder EurekaLog in die dcc reinpacken ;)

[jaenicke]

Zitat:

Zitat von Stevie (Beitrag 1111068)

Zur einer "Dokumentation" zu den Internals hat Allen mal was gesagt und erwähnt, dass dies ein administrativer Overhead wäre, der nicht viel nützen würde. Die Info Build No + Internal Error No ist genug Information für die Devs.

Dass das für die Entwickler ausreichende Informationen sind um die Codestelle zu finden, ist klar. Aber das nutzt mir nichts, wenn ich ein Projekt mit einer älteren Delphiversion bearbeiten muss, da da nichts mehr gefixt wird. ;-)

Ich versuche ja jetzt alles mit XE zu machen, aber bei manchen Projekten geht das eben nicht. Denn es wurde leider u.a. ein Feature bezüglich Sets entfernt (nämlich Include mit Variablen), das ich auch in diversen meiner Open Source Projekte genutzt habe. Mit der Folge, dass die auf XE so nicht mehr kompilierbar sind. Und da ich keinen (sinnvoll nutzbaren) Workaround gefunden habe und auch keine Zeit dafür habe, muss ich da erst einmal bei Delphi 2006 bleiben.

Und dass man kommerzielle Projekte nicht mal so eben umstellen kann, versteht sich von selbst.

Was die Reproduzierbarkeit angeht:
Da habe ich auch gerade einen "lustigen" Fehler. XE zeigt immer wieder mal (aber nicht immer, nicht bei allen Projekten, und auch bei Projekten, die auf anderen PCs problemlos kompilieren...) beim ersten Kompilieren einen internen Fehler an. Beim zweiten geht alles. (Leider habe ich den Fehler aber noch nicht beim Durchsteppen erwischt, immer wenn ein Debugger attached war schien es zufälligerweise normal zu laufen.)

[Aphton]

Zitat:

Zitat von jaenicke (Beitrag 1111059)

Zitat:

Zitat von Aphton (Beitrag 1111025)

Ich hasse Turbo Delphi mittlerweile. Es gibt aber nichts "besseres" momentan >.>

Du meinst wohl kostenlos...

Jup.

Zitat:

Denn die XE Starter halte ich trotz der Einschränkungen für besser, auch wenn man im Vergleich zu Turbo Delphi leider Abstriche z.B. in der Codenavigation und dem Debuggen machen muss (2 Einschränkungen schießen da übers Ziel hinaus, aber was solls).

Könntest du mir die zwei Einschränkungen bitte nennen?

[jaenicke]

Zitat:

Zitat von Aphton (Beitrag 1111072)

Könntest du mir die zwei Einschränkungen bitte nennen?

Drüben im DF hat Christian eine Review erstellt, in dessen Rahmen es eine Diskussion zu dem Thema gab:
http://www.delphi-forum.de/viewtopic...er=asc&start=0

Die Auswertung von Variablen beim Debuggen durch ein Darüberhalten der Maus scheint ebensowenig zu gehen wie die Navigation von der Implementierung zur Deklaration bei Methoden mit Strg + Shift + Pfeil hoch. Diese beiden Sachen sind finde ich zu viel des Guten was Einschränkungen angeht, da beide auch bei kleinen Quelltexten sehr nützlich sind.

Die anderen Einschränkungen sind größtenteils durchaus sinnvoll, wenn auch manche Features jemandem fehlen mögen, der sie aus gekauften Versionen oder Turbo Delphi kennt, zum Beispiel die Klassenvervollständigung oder die mitgelieferten Quelltexte. Aber dass diese Features fehlen, damit kann man leben, denn es kommen ja stattdessen im Vergleich massig Sprachfeatures wie Generics, Unicode usw. dazu.

Zitat:

Zitat von Aphton (Beitrag 1111072)

Zitat:

Zitat von jaenicke (Beitrag 1111059)

Zitat:

Zitat von Aphton (Beitrag 1111025)

Ich hasse Turbo Delphi mittlerweile. Es gibt aber nichts "besseres" momentan >.>

Du meinst wohl kostenlos...

Jup.

Dann wirst du wohl was Object Pascal angeht letztendlich mit Lazarus vorlieb nehmen müssen, wenn dir Delphi kein Geld wert ist. ;-)
Irgendwann in ein paar Jahren wird Lazarus ja vielleicht mal besser als das alte Turbo Delphi werden... (auch wenn der Rückstand zu aktuellen Delphiversionen mit Riesenschritten größer wird...)

[Aphton]

Nun... ich wünsche mir eig. nicht viel mehr als eine stabile IDE mit denselben Eigenschaften.
Alles andere ist für mich nur Luxus und nicht wirklich nötig. Aber ich bin ja noch ein Student =P

[himitsu]

Ich schaff es TDE durchschnittlich alle 30 Minuten zum Absturz zu bringen ... wenn es bei dir länger durchhält, dann bist'e noch sehr gut dran.

[jaenicke]

Das habe ich bei Turbo Delphi nie geschafft, abgestürzt ist es bei mir nur relativ selten. Und ich nutze es für meine Open Source Projekte ja auch noch heute.

Exceptions kommen aber schon häufiger, wenn ich die CnWizards installiert habe.

[divBy0]

Ausfall der Kaffeemaschine...

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1111071)

Ich versuche ja jetzt alles mit XE zu machen, aber bei manchen Projekten geht das eben nicht. Denn es wurde leider u.a. ein Feature bezüglich Sets entfernt (nämlich Include mit Variablen), das ich auch in diversen meiner Open Source Projekte genutzt habe. Mit der Folge, dass die auf XE so nicht mehr kompilierbar sind. Und da ich keinen (sinnvoll nutzbaren) Workaround gefunden habe und auch keine Zeit dafür habe, muss ich da erst einmal bei Delphi 2006 bleiben.

"Feature entfernt" klingt eher nach "das Verhalten war ein Bug und wurde gefixt". Das wär neu, dass Features entfernt werden. Worum genau handelte es sich denn?

P.S. Mich nervt der "F2084 Internal Error: O780", der erst weggeht, wenn man Delphi neustartet :evil: