Variable ist plötzlich anders

[Blup]

Wenn ein String-Paramerter innerhalb der Methode nicht verändert werden soll, vereinbart man den am besten als "const"-Paramter.

Delphi-Quellcode:

FirstKundenSuchen(const KundenNummer: String{ ...})
.

Für die Rückgabe kann man zwar "var"-Parameter verwenden, aber eigentlich sollten es hier "out"-Parameter sein.
"var" bedeuted die Parameter müssen auch vor dem Aufruf sinnvoll belegt sein, da die vorherigen Werte intern benötigt werden.
"out" den Parameter-Variablen muss vor dem Aufruf nichts zugewiesen werden.

Die ganzen Rückgabewerte gehören doch zusammen und bilden ein fachliches Object. Warum dann nicht auch eine Klasse benutzen oder zumindst einen Record?

Delphi-Quellcode:

type
  TKundeRec = record
    Nummer,
    Name1, 
    Name2, 
    Strasse, 
    Land, 
    PLZ, 
    Ort, 
    Telefax, 
    Email, 
    Vertreter, 
    RnEmail: String
  end;

  procedure TUKunden.FirstKundenSuchen(const KundenNummer: String; out Kunde: TKundeRec);
  {oder}
  function TUKunden.FirstKundenSuchen(const KundenNummer: String): TKundeRec;

Deine Klasse heist "TUKunden" und hat direkten Zugriff auf alle internen Felder und Objekte.
Die Variable "UKunden" ist vermutlich eine globale Variable die dich innerhalb der Klasse überhaupt nicht interessiert.
Streich mal überall in der Methode "UKunden.", dann wird das etwas übersichlicher und eine Fehlerquelle ausgeschlossen.

Hast du die Optimierung für das Compilieren angeschalten? Das sollte man nicht wenn man debuggen will.
Das Programm läuft zwar normal, aber der Debugger zeigt dann nicht mehr richtig an.

Vieleicht hast du auch mehrere Variablen die Kundennummer heißen. Eine lokal in der Methode und eine weitere in der Klasse.

[ConnorMcLeod]

Zitat von Blup:

Wenn ein String-Paramerter innerhalb der Methode nicht verändert werden soll, vereinbart man den am besten als "const"-Paramter.

Vollkommen richtig. Ich fände es nur interessant (und korrigierenswert), zu wissen, was passiert

[H.Bothur]

Zitat von Blup:

Wenn ein String-Paramerter innerhalb der Methode nicht verändert werden soll, vereinbart man den am besten als "const"-Paramter.
FirstKundenSuchen(const KundenNummer: String{ ...}) Für die Rückgabe kann man zwar "var"-Parameter verwenden, aber eigentlich sollten es hier "out"-Parameter sein.
"var" bedeuted die Parameter müssen auch vor dem Aufruf sinnvoll belegt sein, da die vorherigen Werte intern benötigt werden.
"out" den Parameter-Variablen muss vor dem Aufruf nichts zugewiesen werden.

Oh ... wieder was gelernt ... das kannte ich noch nicht. bringt aber leider keine Änderung (und immer noch keine Exception)

Zitat von Blup:

Die ganzen Rückgabewerte gehören doch zusammen und bilden ein fachliches Object. Warum dann nicht auch eine Klasse benutzen oder zumindst einen Record?

Record bekomme ich hin - Klasse nicht weil ich (trotz mehrerer Anläufe) das Konzept von OOP nicht verstanden habe - und das was ich kann eigentlich für das bisschen was ich mache reicht.

Zitat von Blup:

Deine Klasse heist "TUKunden" und hat direkten Zugriff auf alle internen Felder und Objekte.
Die Variable "UKunden" ist vermutlich eine globale Variable die dich innerhalb der Klasse überhaupt nicht interessiert.
Streich mal überall in der Methode "UKunden.", dann wird das etwas übersichlicher und eine Fehlerquelle ausgeschlossen.

OK - das mache ich mal - mal sehen was passiert. Da melde ich mich - allerdings hatte ich ab und zu das Thema das bei bestimmten Sachen das geschrieben werden MUSS

Zitat von Blup:

Hast du die Optimierung für das Compilieren angeschalten? Das sollte man nicht wenn man debuggen will.
Das Programm läuft zwar normal, aber der Debugger zeigt dann nicht mehr richtig an.

Nein, habe ich nicht - jedenfalls nicht bewusst. Und debuggen kann ich ja !

Zitat von Blup:

Vieleicht hast du auch mehrere Variablen die Kundennummer heißen. Eine lokal in der Methode und eine weitere in der Klasse.

Nein - es gibt wirklich nur einmal diese Variable

Hans

*So - heute gibt es keine Rückmeldung mehr - sonst bekomme ich Ärger mit meiner Regierung

[H.Bothur]

Zitat von Blup:

Wenn ein String-Parameter innerhalb der Methode nicht verändert werden soll, vereinbart man den am besten als "const"-Paramter. ... Für die Rückgabe kann man zwar "var"-Parameter verwenden, aber eigentlich sollten es hier "out"-Parameter sein.

Blöde gefragt - demzufolge sollte man immer entweder const, out oder var in den Methodenkopf schreiben ? Und "schlichte"
procedure IchTuWas(XYZ: String); gar nicht schreiben ?

Wie dem auch sei - das habe ich entsprechend umgesetzt und alle Aufrufe entsprechend gemacht.

[Jasocul]

Mit der Angabe von Const kann der Parameter auch innerhalb der Procedure/Function nicht verändert werden. Außerdem kann der Compiler besser optimieren.

Etwas ausführlicher:
Delphi-Hilfe

[H.Bothur]

So .. ganz viele Anworten auf einmal

Zitat von stahli:

Benutzt Du sonst irgendwo Application.ProcessMessages?

Nee ... nutze ich nicht.

Zitat von SneakyBagels:

bzgl: -< und hier ist der Inhalt von KundenNummer plötzlich
das verstehe ich nicht. Wie kann "Kundenummer" in einer Zeile plötzlich einen anderen Wert haben, wenn du "Kundennummer" gar nicht vergleichst?

Das sehe ich im debugger und wenn ich entsprechende Stop-Punkte setze. Das mache ich dann immer so:

Delphi-Quellcode:

if KundenNummer = '12652' then
begin
  beep;
end;

Zitat von himitsu:

Sicher, dass sich der Inhalt ändert, oder zeigt der Debugger nur nicht mehr das Richtige an?
Inhalt manuell irgendwo ausgeben (Logdatei, ShowMessage, ...)

Hab ich gemacht - steht aber leider auch der falsche Wert

Zitat von himitsu:

Einzige Ausnahme für das NIEMALS: BufferOverflow oder Dergleichen. Danach sieht es in dem gezeigten Code aber auch nicht aus.
du hast ein massives Speicherproblem und jemand (du) überschreibt irgendwo willkürlich deinen RAM. (aber schon komisch, dass dabei rein zufällig ein "korrekter" String mit einer schönen "Nummer" als Text entsteht)

Ich gehe ja auch davon aus ... wobei ich nicht weiß wieso. Aber ich gebe Dir recht das ich das auch komisch finde und immer noch glaube das ich da unwillkürlich einen Overflow generiere der nur keine Exception auslöst. ... ODER ... ich mache schon vorher massiven Murks - was ja auch nicht unwahrscheinlich ist.

Was ich auch noch nicht verstehe ... und vielleicht ergibt das ja den BufferOverflow ... eigentlich dürfte diese Zeile hier gar nicht funktionieren sondern müsste - wenn ich mich nicht täusche - eine Exception auslösen:

MahnForm.OPTabelleSG.Cells[CKundenNummer, MahnForm.OPTabelleSG.RowCount] := Copy(EinleseZeile, 1, Position -1);
Ich kann doch gar nicht in Cells.[1, Grid.RowCount] schreiben ... es müsste eigentlich doch Cells.[1, Grid.RowCount -1] heißen, oder ? Aber warum wird dann keine Exception ausgelöst ??

Hans

[H.Bothur]

Ich werde jetzt drei Sachen umsetzen:

1) wo möglich const- und out-Parameter nutzen
2) Die eine Schleife von RowCount auf RowCount -1 setzen
3) Versuchen die TKunden. usw. rausnehmen.

Ich melde mich was dann passiert.

Hans

[Jasocul]

Zitat von H.Bothur:

Ich kann doch gar nicht in Cells.[1, Grid.RowCount] schreiben ... es müsste eigentlich doch Cells.[1, Grid.RowCount -1] heißen, oder ? Aber warum wird dann keine Exception ausgelöst ??

An des Phänomen kann ich mich erinnern. Das geht tatsächlich ohne Exception!
Habe gerade mal eine Mini-Test-Anwendung gebastelt. Es war völlig unproblematisch "außerhalb" des StringGrids Einträge zu machen. Werden natürlich nicht angezeigt.

[H.Bothur]

Zitat von Jasocul:

Zitat von H.Bothur:

Ich kann doch gar nicht in Cells.[1, Grid.RowCount] schreiben ... es müsste eigentlich doch Cells.[1, Grid.RowCount -1] heißen, oder ? Aber warum wird dann keine Exception ausgelöst ??

An des Phänomen kann ich mich erinnern. Das geht tatsächlich ohne Exception!
Habe gerade mal eine Mini-Test-Anwendung gebastelt. Es war völlig unproblematisch "außerhalb" des StringGrids Einträge zu machen. Werden natürlich nicht angezeigt.

Komisch - gibt es denn den Speicherbereich dann schon oder wird das "wild" irgendwohin geschrieben ??

Hans

[H.Bothur]

Aktueller Status: es scheint zu funktionieren ... wir testen das mal weiter und ich melde mich dann noch mal !

Hans