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.

[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

Delphi-Quellcode:

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.

[himitsu]

Da die gezeigte Codestelle definitiv keinen Fehler behinhaltet und wir nicht wissen was sonst noch für Code vorhanden ist, kann hier auch keiner Helfen.

- entweder du zeigst mehr
- oder du stellst eine Demoanwendung zur Verfügung, welche den Fehler reproduzierbar zeigt
- oder du kümmerst dich endlich mal selber um das Problem (*)

*)
- Hast du denn nun schonmal geschaut, ob alle beteiligten Variablen i.O. sind? (Self und ComboEdit nicht nil)

- Programm mit DebugDCUs kompilieren
- schauen wo es nun knallt
- und falls nötig, dann Haltepunkt auf den Aufruf und manuell Stück für Stück vorarbeiten, bis die Problemstelle gefunden wurde.

[hoika]

Hallo
Deine comboboxen heißen unterschiedlich!
Kann es sein dass du die einmal in der
Pas-Datei direkt geändert hast.
Dann stimmt der Name in der DFM-Datei
und in der Pas-Datei nicht überein
Schau dir deine DFM-Datei
mal im Notepad an.


Heiko

[himitsu]

Zitat:

Zitat von hoika (Beitrag 1176948)

Schau dir deine DFM-Datei
mal im Notepad an.

Hast du was gegen den OI? :angle2:

[hoika]

Hallo,

der OI geht davon aus,
dass alles über ihn geht.
Sollte aus Versehen direkt in der Pas ein Komponenten-Name geändert werden,
gibt es Ärger.

Deshalb der Hinwweis, sich die DFM mal im Notepad anzusehen.

Ich würde die betreffende ComboBox eh mal Löschen,
dann aus Delphi raus (Speichern) und wieder anlegen.


Heiko

[himitsu]

Im OI siehst du den Propertyinhalte wie sie in der DFM stehn, also auch den Namen, welchen du in der DFM sehn könntest und die PAS ist dem da relativ egal.

PS: Strg+Alt+F12 geht vom Formdesigner aus bestimmt auch schneller, als Notepad, wobei du da auch keinen anderen Namen findest, abgesehn davon, daß du den gewünschten Wert erstmal in der DFM finden mußt.

[ByTheTime]

Nein, habe keinen Fehler bei der Benennung der Komponente gefunden. Allerdings hat es nach dem Löschen funktioniert :thumb: Habe das ganze nochmal nue getippt und jetzt funktioniert es einwandfrei.