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

[himitsu]

Zitat von jaenicke:

Das kann ich bei mir nicht sagen, bei mir ist es ziemlich deutlich zu sehen:

Nach einer Weile ist der Baum recht weit aufgeklappt, dann such mal diese kaum sichtbare Markierung.
Mit ScrollBar hoch und runter.
(immer blau, auch in der Projektverwaltung, wäre viel praktischer)

Total frustrierend isses, wenn man dann noch mitbekommt, daß man das garnicht finden konnte, weil auch noch vergessen wurde den Baum so aufzuklappen, daß diese Komponente überhaupt sichtbar ist.
Wenn wenig bis nix aufgeklappt ist, dann schafft es das Ding öfters das richtige Anzuzeigen.
Nur unpraktisch, daß es sowas wie "alles zusammenklappen" nicht gibt.

Minutenlang jeden Unterknoten einzeln zusammen zusammenklappen, dann auf die Komponente in der Fom klicken, dann hatte ich zu 90% das richtige finden können (nur noch ein biss scrollen, aber die einzigste tiefste aufgeklappte Stelle läßt noch recht leicht finden )

[jaenicke]

Zitat von himitsu:

Minutenlang jeden Unterknoten einzeln zusammen zusammenklappen, dann auf die Komponente in der Fom klicken, dann hatte ich zu 90% das richtige finden können (nur noch ein biss scrollen, aber die einzigste tiefste aufgeklappte Stelle läßt noch recht leicht finden )

Da geht Formular schließen und wieder öffnen vermutlich schneller.
Aber du hast schon Recht, wenn nicht automatisch gescrollt wird, findet man das anders nicht so einfach.

Hmm, da sollte sich doch eigentlich per Addon etwas ändern lassen...

// EDIT:
Die Struktur-Suche in Andreas Hausladens DDevExtensions springen ja schon bei einem Klick auf ein Suchergebnis zum Ergebnis. Da müsste ja was in der Richtung möglich sein.

[Delphi-Laie]

Tja, es stört so allerhand.

Z.B. in Windows ein viel zu kleines und nicht zoombares ("resizable") Fenster bzw. Formular "Ordner suchen", das z.B. dann erscheint, wenn man E-Mail-Dateianhänge aus Outlook Express speichern möchte.

Und/oder in Delphi, konkret dessem Compiler, eine teils zu pedantische, teilweise (oder nur ausnahmsweise) aber auch unachtsame Überwachung, ob Variablen initialisiert wurden ("Variabe xyz wurde wahrscheinlich nicht initialisiert"). Diese springt (fast) regelmäßig dann an, wenn eine Variable zuerst in einer der beiden Alternativen einer if-Anweisung (bzw. dessen Blöcken) erstmalig einen Wert zugewiesen bekommt, auch dann, wenn es in beiden Alternativen geschieht (also auch im else-Teil). Benutzt man diese Variable aber konsequent erst dann, wenn bzw. nachdem ihr ein Wert zugewiesen wurde, dann ist diese Compilerwarnung überflüssig. Aber wehe, diese Warnung versagt einmal, d.h., es wird ein Wert in einer solchen Alternativanweisung benutzt, ohne vorher initialisiert worden zu sein: Das hatte ich auch schon einmal und verursacht (einen) nur mühsam zu entdeckende(n) Fehler.

Also, um den Compiler zu beruhigen, um des lieben Friedens Willen: Die Variablen bekommen dann regelmäßig ihre Initialisierung, kann mir aber den Grund dazu als Kommentar daneben niederzurschreiben nie verkneifen.

[EWeiss]

Wie das zum Beispiel..
Nervt mich auch.

Delphi-Quellcode:

       {$if CompilerVersion > 21} // Delphi XE or later
        if i = -1 then
          testDeviceID := MIDI_MAPPER
        else
          testDeviceID := i;
        FError :=
          midioutGetDevCaps(UIntPtr(testDeviceID), @midioutCaps, sizeof(TmidioutCaps));
       {$else}
        testDeviceID := i;
        FError :=
          midioutGetDevCaps(testDeviceID, @midioutCaps, sizeof(TmidioutCaps));
       {$ifend}

wie soll man es denn sonst machen ?
testDeviceID wahrscheinlich nicht initialisiert

gruss

[Furtbichler]

Komisch, kann ich nicht nachvollziehen:

Delphi-Quellcode:

Var
  i : Integer;

Begin
  if now>1 then
    i := 1 
  else 
    i := 2;
  if i=1 then showmessage('idiotencode');
end;

[Delphi-Laie]

Mich stört, daß man generell mehr als nötig schreiben muß. Damit meine ich aber nicht die Schlüsselwörter Begin und end statt der beiden Klammern in C & Konsorten, das ist ein Klacks. Ich bin auch kein Freund extrem komprimierter Anweisungen in C & Co. (in denen mehr als eine Sache (fast) gleichzeitig passiert), obwohl das Lesen derselben letztlich auch nur eine Übungsangelegenheit ist.

Nein, es geht um etwas anderes. In C & Co. muß man logische Ausdrücke ja einklammern: if (a=b) then... . Wie schön, daß man darauf in Pascal verzichten kann. Nur, warum man mit den Einklammern beginnen muß, wenn man mehr als einen zu verarbeitenden Audruck hat und diese miteinander verknüpfen muß, also z.B. if (a=b) and {oder or} (c=d) then..., erschließt sich mir bis heute nicht. Soll das ein zusätzlicher Zwang zur Übersichtlichkeit sein? Ich weiß nicht, wieviel Zeit mir während meines Programmierens verlorenging, nur, um nicht logische Fehler in den Boolschen Ausdrücken an sich, sondern in deren (m.E. unnötig aufgezwungener) Klammerlogik aufzuspüren.

[Bummi]

Delphi-Quellcode:

var
 a,b,c:variant;
 d:Variant;
begin
  a := 1;
  b := 2;
  c := 3;
  d := a=(b or c);
  Showmessage(d);
  D := (a = b) or c;
  Showmessage(d);
  D := a = b or c;
  Showmessage(d);
end;

[Gausi]

Naja, AND ist nicht nur ein boolscher Operator, sondern auch ein bitweises AND. Und in der Prioritätenliste kommen diese Operatoren vor den Vergleichsoperatoren (was generell sinnvoll ist, wie ich finde).

Aus if a=b and c=d then wird also zuerst ein if a = e = d then , und daraus ein if (Bool) = d then . Und das schmeckt einer typentreuen Sprache wie Delphi nicht so gut (wenn a,b,c,d Integer o.Ä. sind). Daher muss man bei sowas klammern.

[himitsu]

Zitat von Delphi-Laie:

z.B. if (a=b) and {oder or} (c=d) then..., erschließt sich mir bis heute nicht.

Das ist ganz einfach.

Es gibt eine Reihenfolge/Rangfolge der Verarbeitung, bzw. die Operatoren haben unterschiedliche Prioritäten.

http://de.wikibooks.org/wiki/Program...al:_Operatoren
siehe Rangfolge der Operatoren
[edit]Das unäre + und - wurde in der Liste nicht mit aufgenommen, also das Vorzeichen einer Zahl, aber diese kann man sich auch gerne an Position 0 vorstellen, noch vor dem NOT.[/edit]

Das steh zwar auch nochmal in der OH, aber solche Einträge findet man dort nicht so einfach


Ich weiß nicht was du hast ... es geht doch? Man kann Klammern weglassen.

Delphi-Quellcode:

if ((not a) = (b and c)) then

if not a = b and c then

Man muß nur die Rangfolge beachten



[edit]

Zitat von Gausi:

Aus if a = b and c = d then wird also zuerst ein if a = e = d then

Vorher wird daraus erstmal ein if a = (b and c) = d then

Praktisch ist aber, daß man nur ein = haben kann, innerhalb eines Auswertungspfades. Manchmal aber auch unpraktisch, aber hier praktisch, da man so eine Fehlermeldung bekommt.
Bei if a = b and c then , aka if a = (b and c) then , würde es anders aussehn, da es eben nicht zu if (a = b) and c then wird.

[p80286]

Zitat von Delphi-Laie:

Die Variablen bekommen dann regelmäßig ihre Initialisierung, kann mir aber den Grund dazu als Kommentar daneben niederzurschreiben nie verkneifen.

Ist wohl eine Frage des Alters, Alle Variablen sind zu initialisieren!

Da mach ich mir keine Gedanken mehr darüber ob denn bei welcher Bedingung aber nur wenn ausgenommen.....
Wenn result ein -1 hat und nur 0 oder 1 kommen dürften, dann sitzt der Fehler wieder mal vor der Tastatur.

Gruß
K-H