Problem mit if-Befehl

[ByTheTime]

Hallo,
ich habe ein kleines Problem. Kann es mir nicht erklären:

Delphi-Quellcode:

  if ComboDis.Text = 'Variante 1' then
     CalloutPower.Visible := true;

Funktioniert Fehlerfrei!

Delphi-Quellcode:

if ComboDis.Text = 'Variante 1' then
   CalloutPower.Visible := true
 else
   CalloutPower.Visible := false;

Ich bekomme nach dem Compilieren einen Fehler: Zugriffsverletzung in ComboDis.Text! Ich kann mir nicht erklären was da jetzt falsch ist :/

Lukas

[mkinzler]

In diesem Code kann ich keinen Fehler erkennen. Möglicherweise liegt der woanders.

[himitsu]

Jupp, dieser Code hat keinen Fehler, abgesehn von einer logischen Unoptimalheit.

Delphi-Quellcode:

 if ComboDis.Text = 'Variante 1' then
   CalloutPower.Visible := true
 else
   CalloutPower.Visible := false; 

 CalloutPower.Visible := ComboDis.Text = 'Variante 1';

Und ComboDis iist doch keine ComboBox?
Es ist nicht so gut, auf Texte der GUI zuzugreifen, womit hier ItemIndex wohl besser ist.

PS: Es gibt Viele die z.B. auf die Caption von MenuItems zugreifen und sich dann wundern, wenn die Texte nicht übereinstimmen.
Und dazu kommt noch, daß man so keine guten Aussichten hat, sollte man mal seine GUI lokalisieren/übersetzen will.



Wie genau lautet denn die Fehlermeldung? (Tipp: Strg+C)
Und warum muß man ständig alle danach fragen?

Welches Zielsystem? (muß man seit XE2 ja auch noch fragen)

Und was sagt der Debugger? (mit einer Architekt sollte man auch locker mal die VCL debuggen können)

[sx2008]

Also ich würde den Code so umschreiben:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender:TObject);
begin
  // self ist in diesem Kontext das Formular
  // sollte self = NIL sein, dann ist alles zu spät
  // deshalb wird dies mit der Assert-Anweisung geprüft
  Assert(Assigned(self));

  // wir sind etwas paranoid und gehen lieber auf Nummer Sicher
  Assert(Assigned(ComboDis));
  Assert(Assigned(CalloutPower));

  // mit der Klammersetzung wird der Leser mit der Nase darauf gestossen
  // dass zuerst eine Auswertung eines boolschen Ausdrucks stattfindet
  // und dann das Ergebnis dem Property Visible zugewiesen wird
  CalloutPower.Visible := (ComboDis.Text = 'Variante 1');

PS: wann immer eine Zugriffsverletzung auftritt dann kann Assert() helfen.
Man braucht nur an die richtigen Stellen im Code einige Asserts platzieren und schon hat man den Fehler eingefangen.
Zugriffsverletzungen sind die Krankheit und Asserts das Medikament dagegen.

[himitsu]

Asserts sind nur der Virentest.

Sie verhindern "einige" unkontrolierte Fehlbehandlungen, aber sie lösen dennoch selber Exceptions aus, womit das Programm dennoch nicht funktionsfähig wird.

Und Asserst bringen nur dort was, wo man weiß, daß irgendwann Fehler auftreten könnten, auf welche man "gezielt" hingewiesen werden möchte.
Hier ist es aber schon zuspät, da man weiß daß definitiv etwas falsch läuft.
Und das Selbe was hier ein Assert macht, kann man auch selber machen ... man muß nur mal den Debugger benutzen.

[ByTheTime]

Ich weiß ja das alles richitg ist, aber er sagt mir ja das dort eine Zugriffsverletzung eintritt.

Delphi-Quellcode:

if ComboDis.Text = 'Variante 1' then
   CalloutPower.Visible := true; //Simikolon noch dahinter
 //else
   //CalloutPower.Visible := false;

So geht es.

Das sind die Fehler:
1. Erste Gelegenheit für Exception bei $005B3F28. Exception-Klasse $C0000005 mit Meldung 'access violation at 0x005b3f28: read of address 0x00000000'. Prozess TPManager.exe (7936)

2. Erste Gelegenheit für Exception bei $755AB9BC. Exception-Klasse EReadError mit Meldung 'Fehler beim Lesen von ComboDiscipline.Text: Zugriffsverletzung bei Adresse 005B3F28 in Modul 'TPManager.exe'. Lesen von Adresse 00000000'. Prozess TPManager.exe (7936)

Der 2. Fehler wird dann auch im Programmfenster angezeigt (bzw. das Error-Fenster ist das einzige was man sieht, dannach stürzt es ab)

Zu den Fragen:

In XE2, für Win(7). Allerdings in Firemonkey, da sieht das ganze etwas anders aus (will es mal ausprobieren). Das ganze ist mittlerweile ein sogennantes "ComboEdit" also man kann auch selbst reinschreiben. Das mit dem ItemIndex wird problematisch, da ich die Text-Eigenschaft nur benuzte um das Feld für den Nutzer zu beschreiben, also das was ich normallerweise im Label habe, steht dort drin. Allerdings frag ich mich selbst ob das sinnvoll ist, den am Ende weiß keiner mehr, für was das Feld zuständig war, und Hints habe ich auch noch nciht entdeckt.

Delphi-Quellcode:

CalloutPower.Visible := ComboDis.Text = 'Variante 1'; //Geht aber auhc nicht...

>.< Daran habe ich davor noch gedacht, ist dann aber in meinem Gedankenschlachfeld untergegangen...

[sx2008]

Zitat:

Zitat von himitsu (Beitrag 1176918)

Und das Selbe was hier ein Assert macht, kann man auch selber machen ... man muß nur mal den Debugger benutzen.

Das sehe ich etwas anderst.
Asserts werden einmal hingeschrieben und halten Wache solange der Code benützt wird.
Breakpoints und Watches im Debugger sind dagegen eine mehr oder weniger einmalige Geschichte.

Asserts sind ein extrem nützliches Werkzeug; vorallem dann wenn die Codebasis sehr gross ist.
Wenn der Benutzer eine Zugriffsverletzung meldet, dann weiss der Entwickler nur dass irgendwo in dem Programm wahrscheinlich ein nil-Zeiger dereferenziert wurde.
Eine Assert-Exception meldet dagegen die Unit, die Zeilennummer und ggf. noch einen Hinweis:

Delphi-Quellcode:

// Assert mit zusätzl. Meldungstext
Assert(Assigned(QueueManager), 'QueueManager nicht initialisiert');

Bei hunderten von Units macht das einen riesigen Unterschied zu wissen wo man das Problem zu suchen hat.

Bevor man defekten Code zum Laufen bringt muss man wissen wo der Fehler liegt.
Dazu leisten Asserts einen guten Beitrag.
Wenn man den Fehler dann gefunden und behoben hat möchte man präventiv verhindern, dass der Fehler in ähnlicher Weise wieder auftritt.
Auch hier helfen Asserts.

[ByTheTime]

Mit dem Assert bekomme ich nun einen EReadError mit dem Hinweis, das die Assertion fehlgeschlagen ist.

[Dalai]

Zitat:

Zitat von ByTheTime (Beitrag 1176924)

Mit dem Assert bekomme ich nun einen EReadError mit dem Hinweis, das die Assertion fehlgeschlagen ist.

Mit welchem Assert? Im Beispiel von sx2008 stehen mehrere.

MfG Dalai

[WM_CLOSE]

@ByTheTime:
Womit das Problem eigentlich aufgeklärt seim müsste: ComboDis ist nil (nicht initialisiert).
Darum ist das Assert da.
Es prüft, ob eine Bedingung erfüllt ist und löst ansonsten eine Exception aus.
Ideal an solchen Stellen, an denen man gewisse Dinge voraussetzt, z.B. dass eine Variable > 0 ist oder ein Objekt initialisiert ist.

PS: ich ging davon aus dass es ComboDis ist.