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

[himitsu]

Zitat:

Zitat von NamenLozer (Beitrag 1031733)

Derzeit nervt mich besonders folgendes Fenster, das immer beim Starten meiner Projekte aus der IDE erscheint:

Schau mal Nach, wie es bei dir mit MSXML aussieht.
Ich kenn diesen Fehler auch.
(Wenn man den Windows-Installer-Service nicht automatisch starten läßt, dann reagierte nach [Abrechen] die IDE für 2-5 Minuten garnicht mehr.)

Bei mir half es den MSXML 4.0 (muß aber nicht genau dieser sein) manuell aus der Registrie zu entfernen und später mal Windows neu zu installieren.



OK und der coolste Bug im TDE-Compiler ist das nette Speicherleck, beim Kompilieren ... nach ein paar dutzend/huntert Kompilierungen stürzt die IDE mit 'nem OutOfMemory ab.

[mleyen]

1. Jegliche Form von unnötiger Ablenkung.
2. Zitat:

   Zitat von blackfin (Beitrag 1031696)

   2) Zugriffsverletzung in coreide.

   Den kenn ich nur zugut. (aber ich glaub der kommt von einem Addon bzw. Kombinationen von Addons, meist wenn ich mit Formularen arbeite)
   
3. Wenn meine Hand weh tut.... :? (Ist aber eher seltend der Fall)

Und hier noch was ich mag:
Bugs :-D

[cookie22]

Zitat:

Zitat von hathor (Beitrag 1031727)

Die SANDUHR, die häufig beim Klicken im Editor erscheint!!!

oh ja.

Zitat:

Mindestens genau so nervig finde ich die zahlreichen anderen Bugs in TurboDelphi - gestern z.B. hätte ich wieder fast einen Anfall bekommen, weil auf einmap pro Sekunde 1000 mal so viele Fehlermeldungen aufpoppten als ich hätte schließen können. Passiert leider nicht gerade selten Kaum zu fassen, dass die gleiche IDE in besserer Austattung zu Summen jenseits von 1000€ verkauft wurde - ziemlich hoher Preis für ein Programm dass sich anfühlt wie eine Pre-Alpha. Kein Programm stürzt bei mir so oft ab wie TurboDelphi.

kennst du delphi 2005? :stupid:

[Namenloser]

Zitat:

Zitat von cookie22 (Beitrag 1031736)

kennst du delphi 2005? :stupid:

Ja, leider :lol:

[Meflin]

Zitat:

Zitat von NamenLozer (Beitrag 1031733)

Case nur für ordinale Typen. Das ist wohl dadurch bedingt, wie der Compiler solche Cases optimiert, aber ich finde, mich als Programmierer hat die interne Umsetzung des Compilers nichst zu interessieren. Es wäre kein Problem, ein Case mit nicht-ordinalen Typen intern in einen Haufen verketteter If-Abfragen umzuwandeln. Wenn man wollte, könnte man z.B. bei Strings auch noch mit Hashmaps o.ä. optimieren.

Case für strings habe ich in meinen Anfangsjahren auch sehr vermisst. Mittlerweile weis ich, dass aus softwarearchitektureller Sicht schlicht und ergreifend kein sinnvoller Einsatzzweck dafür besteht. Für schnelle Quick & Dirty Hacks mag es ja ganz nett sein. In ernsthaftem Code sind Stringvergleiche nur sehr selten angebracht, und schon garnicht so, wie man sie mit einem case verwenden würde (case edit1.text of...). Will man irgendwelche Eingaben auf interne Logik mappen, nimmt man dafür z.B. ein Dictionary (welches in vielen Delphiversionen allerdings leider auch fehlt...).

[Namenloser]

Zitat:

Zitat von Meflin (Beitrag 1031745)

Case für strings habe ich in meinen Anfangsjahren auch sehr vermisst. Mittlerweile weis ich, dass aus softwarearchitektureller Sicht schlicht und ergreifend kein sinnvoller Einsatzzweck dafür besteht.

Doch, z.B. für Parser wäre das recht praktisch. Letzlich ist Case für Strings genau so sinnvoll bzw. unsinnig wie Case für ordinale Werte.

Zitat:

Zitat von Meflin (Beitrag 1031745)

Will man irgendwelche Eingaben auf interne Logik mappen, nimmt man dafür z.B. ein Dictionary (welches in vielen Delphiversionen allerdings leider auch fehlt...).

Bei TurboDelphi kann ich von sowas wie Dictionaries nur träumen...

[hboy]

Was mich gerade nervt sind meine Nachbarn, die lautstark unter Höllenqualen zu leiden scheinen, während sie sich dem Sportfernsehen hingeben. Warum? Es ist nach 01:30 und viel zu heiß, um das Fenster zu schließen ...

[blackfin]

Zitat:

Höllenqualen

....

Zitat:

Sportfernsehen

.....

Zitat:

01:30

hust....bist du dir sicher, dass das auch wirklich das Sportfernsehen ist? :oops:

[Namenloser]

Zitat:

Zitat von blackfin (Beitrag 1031792)

Zitat:

Höllenqualen

....

Zitat:

Sportfernsehen

.....

Zitat:

01:30

hust....bist du dir sicher, dass das auch wirklich das Sportfernsehen ist? :oops:

Naja, wahrscheinlich so "Sport"-Fernsehen wie DSF :lol:

[idefix2]

Was bei mir mit ganz grossem Vorsprung in Führung ist beim Wettbewerb um das nervigste Ärgernis ist die absolut unzureichende oder unverständliche Dokumentation von vielen Programmen und Tools.

In der Liste ganz vorne steht die Open Office API, die ist zwar sehr umfangreich, aber zumindest für mich völlig unverständlich - ich habe bis jetzt zweimal ansatzweise versucht, da hineinzusteigen, und habe es beide Male wieder frustriert "zurückgestellt".

Bei der Firebird Doku nervt mich vor allem, dass es kein Dokument gibt (oder ich es nicht gefunden habe), in dem alle Sprachfeatures zu finden sind, sondern man muss erst einmal die alte Interbase Dokumentation und danach die Release Notes für die verschiedenen Firebird Versionen durchstöbern, wenn man wissen will, ob und wie etwas funktioniert.

Die Delphi Dokumentation selbst ist unter jeder Kritik, eine derart unübersichtliche und unsystematisch aufgebaute Sprachreferenz ist mir noch nirgends untergekommen, dazu Delphi und C++ auf das unübersichtlichste vermengt - die kontextsensitive Delphi Hilfe liefert prinzipiell auch alle reinen C++ Topics zum jeweiligen Schlüsselwort. Informationen zu vielen Einzelheiten fehlen komplett, dann bleibt nur das zeitaufwändige Ausprobieren. Den Aufbau der Klassendokumentation könnte man schwer noch unübersichtlicher konzipieren, und bei der stereotypen Erklärung "das ist xyz, eine Methode/Eigenschaft der Klasse abc" als einzige Erklärung könnte ich die Wände hochklettern.