Problem mit if-Befehl

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

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 von himitsu:

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 von ByTheTime:

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.

[Furtbichler]

Senf:
Asserts sind dazu da, Programmier(er)fehler zu finden. Im Produktivcode existieren die Asserts ja nicht mehr.

Es ist wichtig, die Fehlermeldung zu verstehen: Wenn dort irgendwas mit Adressen in der Nähe von 0x000000** steht, handelt es sich eigentlich immer um ein Nil-Pointer Problem.

[ByTheTime]

OKay, aber warum ist dann ComboDis nicht initalisiert. Also das ganze steht im OnChange-Event des ComboDis. Und wenn man hier 'Variante 1' auswählt erscheint ein Panel.

Delphi-Quellcode:

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

Wenn ich es so mache geht es ja, und ich kann mir nciht erklären, was jetzt die dazukommenden 2 Zeilen hervorrufen/ändern.

[mkinzler]

Versuch mal

Delphi-Quellcode:

if (Sender as TComboBox).Text = 'Variante 1' then
    CalloutPower.Visible := true; //Semikolon noch dahinter
else
  CalloutPower.Visible := false;

[ByTheTime]

Nein, immer noch das selbe Hier ist mal ein Bild imAnhang, was passiert, wenn ich ohne Debbuger compiliere.

Aber ich Überlege mir das ganze einfach zu lassen mit dem Text im ComboEdit... Damit habe ich nur Probleme und muss für jedes ComboEdit im OnClick-Event ComboEdit.SelectAll; und im OnExit

Delphi-Quellcode:

if ComboEdit.Text = '' then
   ComboEdit.Text := 'Beschriftung'

Da kann ich einfach auch alles mit Labels machen. Ich finde zwar somit sieht es schöne aus, aber ich ahbe nur Probleme und muss immer so Kleinigkeiten in den ganzen Events coden.