Funktion/Prozedur abbrechen?

[JulianT]

Hallo, hier mein Quellcode:

Code:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.Grids, System.Math;

type
  TForm1 = class(TForm)
    StringGrid1: TStringGrid;
    Edit1: TEdit;
    Edit2: TEdit;
    Label1: TLabel;
    Label2: TLabel;
    Edit3: TEdit;
    Label3: TLabel;
    Berechne: TButton;
    Abbruch: TButton;
    procedure AbbruchClick(Sender: TObject);
    procedure BerechneClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;
  Minpunkte : array [1..6] of Real;

implementation

uses Unit2;
{$R *.dfm}

procedure TForm1.AbbruchClick(Sender: TObject);
begin
close;
end;

procedure TForm1.BerechneClick(Sender: TObject);
var Schulnote,maxpunktzahl,schülerpunkte: Integer;
begin
  begin
    if Edit2.Text > Edit1.Text then ShowMessage('Invalide Eingabe');
  end;
  begin
    if Edit2.Text <= Edit1.Text then
        maxpunktzahl:=StrToInt(Edit1.Text);
        schülerpunkte:=StrToInt(Edit2.Text);
        Minpunkte[1]:=(maxpunktzahl/100)*96;
        Minpunkte[2]:=(maxpunktzahl/100)*80;
        Minpunkte[3]:=(maxpunktzahl/100)*60;
        Minpunkte[4]:=(maxpunktzahl/100)*40;
        Minpunkte[5]:=(maxpunktzahl/100)*20;
        Minpunkte[6]:=(maxpunktzahl/100)*0;
        StringGrid1.Cells[1,1]:=FloatToStr(Ceil(Minpunkte[1]));
        StringGrid1.Cells[1,2]:=FloatToStr(Ceil(Minpunkte[2]));
        StringGrid1.Cells[1,3]:=FloatToStr(Ceil(Minpunkte[3]));
        StringGrid1.Cells[1,4]:=FloatToStr(Ceil(Minpunkte[4]));
        StringGrid1.Cells[1,5]:=FloatToStr(Ceil(Minpunkte[5]));
        StringGrid1.Cells[1,6]:=FloatToStr(Ceil(Minpunkte[6]));

  begin
    if  (schülerpunkte >= Minpunkte[1]) then Edit3.Text:='1' else
    begin
      if (schülerpunkte >= Minpunkte[2]) then Edit3.Text:='2' else
      begin
        if (schülerpunkte >= Minpunkte[3]) then Edit3.Text:='3' else
        begin
          if (schülerpunkte >= Minpunkte[4]) then Edit3.Text:='4' else
          begin
            if (schülerpunkte >= Minpunkte[5]) then Edit3.Text:='5' else
            begin
              if (schülerpunkte >= Minpunkte[6]) then Edit3.Text:='6' else
            end;
          end;
        end;
      end;
    end;
  end;
end;
end;




procedure TForm1.FormCreate(Sender: TObject);
var i : integer;
begin
  StringGrid1.Cells[0,0]:='Note';
  StringGrid1.Cells[1,0]:='ab';
  for i :=1 to 7 do StringGrid1.Cells[0,i]:=IntToStr(i);
end;

end.

Ich habe die Anweisung jetzt so gelegt, dass wenn die zu erreichende Punktzahl kleiner als die des Schülers ist, ein ShowMessage ausgegeben wird.

Ich hätte es aber lieber so gemacht, dass am Anfang eine if then Schleife die Validität überprüft, mit "Abort" abbricht und dann ShowMessage ausgibt. Allerdings kam dann in diesem Fall die ShowMEssage und das Programm lief im Hintergrund weiter. Könnte mir da jemand mal einen Ansatz geben?

Danke im Vorraus!

[baumina]

Innerhalb einer procedure/function kannst du mit Exit rausspringen.

Beispiel:

Delphi-Quellcode:

procedure Irgendwas(Schalter : Boolean);
begin
  showmessage('innerhalb der procedure');
  if Schalter then
  begin
    showmessage('Schalter = true');
    Exit;
  end;
  showmessage('Schalter = false');
end;

[himitsu]

Ich sehe hier nirgendwo einen Grund für ein Exit, oder Dergleichen.
Du mußt einfach nur die "ELSE" richtig verschachteln.

Oder siehe Sir Rufo und du wirfst eine Exception.

www.if-schleife.de




Wobei die Codeformatierung auch nicht sonderlich gut ist, vorallem bezüglich der Einrückung.

Hier sieht es so aus, als wenn du was Anderes machen willst, als im Code da steht.

Delphi-Quellcode:

begin
    if Edit2.Text <= Edit1.Text then
        maxpunktzahl:=StrToInt(Edit1.Text);
        schülerpunkte:=StrToInt(Edit2.Text);
        Minpunkte[1]:=(maxpunktzahl/100)*96;

Zitat:

Edit2.Text > Edit1.Text

In den Edits stehen doch bestimmt Zahlen drin?
Wenn ja, dann ist ein Stringvergleich nicht sonderlich gut, denn '20' ist größer als '100'.

[Sir Rufo]

Wenn etwas überprüft werden soll, dann gibt es den Fall, dass es gültig oder ungültig ist.

Wenn etwas ungültig ist und man aber eben etwas gültiges benötigt um was auch immer zu verarbeiten/berechnen, dann habe ich eine Ausnahme-Situation. Das ist dann eine Exception.

Und genau so eine Exception wirft man in diesem Fall:

Delphi-Quellcode:

procedure TForm1.BerechneClick(Sender: TObject);
var 
  Schulnote, maxpunktzahl, schülerpunkte: Integer;
begin
  maxpunktzahl := StrToInt( Edit1.Text );
  schülerpunkte := StrToInt( Edit2.Text );

  if schülerpunkte > maxpunktanzahl then
    raise EArgumentOutOfRangeException.CreateFmt( 
      'Die Schülerpunkte (%d) dürfen nicht größer als die maximalen Punkte (%d) sein!',
      [schülerpunkte,maxpunktzahl] );
  
  // ab hier die normalen Berechnungen
end;

[bernau]

Zitat von Sir Rufo:

Wenn etwas überprüft werden soll, dann gibt es den Fall, dass es gültig oder ungültig ist.

Wenn etwas ungültig ist und man aber eben etwas gültiges benötigt um was auch immer zu verarbeiten/berechnen, dann habe ich eine Ausnahme-Situation. Das ist dann eine Exception.

Und genau so eine Exception wirft man in diesem Fall:

Ich habe mir in den letzten Jahren immer mehr angewöhnt mit Exceptions zu arbeiten und Exceptions sind eine tolle Sache. Ich würde aber in diesem Fall das etwas anders sehen.

Eine Exception werfe ich dann, wenn wenn etwas unerwartet ist. Etwas worauf ich nicht vorbereitet bin darauf zu reagieren.

In dem Beispiel kann man aber erwarten, daß auch mal etwas falsch oder in der falschen Reihenfolge eingegeben wird. Das würde ich klassisch mit einem If then else abfangen. Oder von mir aus auch mit einem If then Exit.

Je mehr ich vorher "bewusst" abfange, desto besser. Je weniger Exceptions ich auslöse, desto besser.

[himitsu]

Man dürfte ja erwarten, daß der Benutzer richtige Werte eingibt, also ist das schon ein bissl unerwartet.
Genauso wie die Exceptions bei StrToInt, wenn der Benutzer keine gültigen Zahlen eingibt.

[Sir Rufo]

Zitat von himitsu:

Man dürfte ja erwarten, daß der Benutzer richtige Werte eingibt, also ist das schon ein bissl unerwartet.
Genauso wie die Exceptions bei StrToInt, wenn der Benutzer keine gültigen Zahlen eingibt.

Nicht nur unerwartet, sondern auch unlösbar.

In diesem konkreten Fall können eben drei Exceptions auftreten

1. Edit1.Text kann nicht in einen Integer umgewandelt werden
2. Edit2.Text kann nicht in einen Integer umgewandelt werden
3. Die Punktzahl ist größer als die maximale Punktzahl

In jedem der drei Fälle immer das Gleiche passieren: Es erscheint ein Fenster mit dem Fehler.

Und womit knn ein Benutzer immer am einfachsten umgehen? Richtig, wenn immmer das Gleiche passiert.

[Sir Rufo]

Zitat von bernau:

Je mehr ich vorher "bewusst" abfange, desto besser. Je weniger Exceptions ich auslöse, desto besser.

Exceptions sollen so früh wie möglich und so oft wie nötig geworfen werden.

Bei der Implementierung einer Methode interessiert es mich nicht, was dort alles an Argumenten reinkommen könnte, sondern ausschliesslich, was diese Methode an Argumenten verarbeiten soll. Bei allen anderen Konstellationen werfe ich eine Exception. Dadurch bleibt die Methode klein und übersichtlich und macht genau das, was sie machen soll und verweigert ihren Dienst komplett, wenn ich dort Murks übergebe. So soll es sein.

[bernau]

Ich habe nicht geschrieben, daß der Nutzer nicht informiert werden soll.

Aber mit der Art der Information bin ich flexibel, wenn ich nicht direkt mit einer Exception draufhaue. Ein Label mit dem Fehlerhinweis ist schon mal besser als ein Dialog. Grade bei zwei oder mehr eingabefeldern wird ja bei dem ersten Tastendruck schon eine Exception ausgelöst. weil das Zweite Edit noch leer ist und keinen definierten Wert hat. Dann doch lieber abfangen und in einem Label dezent darauf hinweisen.

[Sir Rufo]

Zitat von bernau:

Ich habe nicht geschrieben, daß der Nutzer nicht informiert werden soll.

Aber mit der Art der Information bin ich flexibel, wenn ich nicht direkt mit einer Exception draufhaue. Ein Label mit dem Fehlerhinweis ist schon mal besser als ein Dialog. Grade bei zwei oder mehr eingabefeldern wird ja bei dem ersten Tastendruck schon eine Exception ausgelöst. weil das Zweite Edit noch leer ist und keinen definierten Wert hat. Dann doch lieber abfangen und in einem Label dezent darauf hinweisen.

Hmmm, da die Methode BerechnenClick heißt, impliziere ich jetzt mal, dass diese aufgerufen wird, wenn auf einen Button geklickt wird, und zu diesem Zeitpunkt müssen alle Werte korrekt eingegeben sein, oder es ist eben Murks -> Exception