Routine mit Namen aufrufen

[himitsu]

Man kann natürlich aus einer Mücke einen Elefanten machen.

Statt var s: string; nimmt man ein TRichEdit,
bzw. statt einer TStringList nimmt man ein TMemo
und statt TPersistent eine ganze Form, (wenn schon, dann maximal ein TDataModul)
statt TBitmap/TPicture nimmst du ein TImage,
statt mit dem Smart machst du deinen Freitagseinkauf mit einem 80-Tonner
usw.

[BadenPower]

Zitat von himitsu:

(wenn schon, dann maximal ein TDataModul)

Fuss von Schlauch hochheb.

Ja klar, ein Datenmodul geht ja auch.

Es wird beim Programmstart auch automatisch erzeugt und es muss auch in Form1 nie etwas geändert werden, da ja die Units mit den Funktionen nicht in Form1 bekannt gemacht werden müssen.

Bei Erweiterungen des Programms entweder ein Datenmodul oder eben eine Form, wenn die Funktionen in einem Fenster enthalten sind, welches sowieso benutzt wird.

Würde der TE etwas anderes benutzen, dann müsste er immer selbst dafür sorgen, dass der entsprechende Container auch erzeugt wird.

So kann er einfach ein neues Fenster oder Datenmodul erstellen und braucht an keiner anderen Stelle etwas zu ändern.

Unit3 als Datenmodul:

Delphi-Quellcode:

unit Unit3;

interface

uses
  SysUtils, Classes, Dialogs;

type
  TDataModule3 = class(TDataModule)
    procedure Job1();
    procedure Job2();
    procedure Job3();
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  DataModule3: TDataModule3;

implementation

{$R *.dfm}

procedure TDataModule3.Job1();
begin
  ShowMessage('DataModule3 - Job1');
end;

procedure TDataModule3.Job2();
begin
  ShowMessage('DataModule3 - Job2');
end;

procedure TDataModule3.Job3();
begin
  ShowMessage('DataModule3 - Job3');
end;

end.

zum Test dieses noch in den Constructor Form1.Create der Form1 hinzufügen

Delphi-Quellcode:

  ListBox1.Items.Add('DataModule3/Job1');
  ListBox1.Items.Add('DataModule3/Job2');
  ListBox1.Items.Add('DataModule3/Job3');

und man sieht, es geht selbstverständlich auch.

[Sigi55]

Zitat von BadenPower:

Zitat von himitsu:

(wenn schon, dann maximal ein TDataModul)

und man sieht, es geht selbstverständlich auch.

Hi,
und wie das geht, ist das jetzt der Ansatz den himitsu meinte ??

Gruß

Sigi

[BadenPower]

Zitat von Sigi55:

und wie das geht, ist das jetzt der Ansatz den himitsu meinte ??

himitsu's Ansatz wäre noch weniger Speicherplatz zu verbrauchen, also mit der Klasse zu arbeiten, welche selbst am wenigsten Speicher belegt.

Hätte allerdings einen erhöhten Programmieraufwand zur Folge und dies immer dann, wenn Du auf Funktionen in einer neuen Klasse zugreifen wolltest. Und ob dies dann wirklich weniger Speicher benötigt ist eher ungewiss.

Mit dem Datenmodul ist es ein sehr guter Kompromiss, da das DM weniger Speicher belegt, als eine extra Form, wenn Du die Form selbst eigentlich nicht benötigst.

Wie gesagt: einfach neues Datenmodul oder neue Form mit den Proceduren anlegen und fertig.

[Sigi55]

Zitat von BadenPower:

Mit dem Datenmodul ist es ein sehr guter Kompromiss, da das DM weniger Speicher belegt, als eine extra Form, wenn Du die Form selbst eigentlich nicht benötigst.

Wie gesagt: einfach neues Datenmodul oder neue Form mit den Proceduren anlegen und fertig.

Hi,

seh ich auch so, hab ich getest und löppelt super
Für mich als "DummProgger" gerade richtig

Dann werd ich mal an's umbauen gehn ...

Danke nochmal.

Sigi

[BUG]

Kann man über diesen Weg auch z.B. Destroy aufrufen*? Das konnte spaßig sein

* Sry, kein Delphi zur Hand.

[BadenPower]

Zitat von BUG:

Kann man über diesen Weg auch z.B. Destroy aufrufen*? Das konnte spaßig sein
[/SIZE]

Standardmäßig nicht, da der Destructor nur "public" ist.


Wenn Du das aber möchtest dann so:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    procedure Job1();
    procedure Button1Click(Sender: TObject);
  private
    procedure ExecuteJobs();
    procedure ExecuteRoutine(AInstance: TObject; AName: string);
  public
  published
    procedure Destroy;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

type
  TExecute = procedure of object;

procedure TForm1.Destroy;
begin
  inherited Destroy;
end;

[Dejan Vu]

Das Problem bei Ansätzen dieser Art(*) erblickt in seiner ganzen Wucht in dem Augenblick das Licht der Welt, in dem die Namen der aufzurufenden Prozeduren abgespeichert werden und anschließend ein Refactoring der Prozedurnamen erfolgt (= Methode umbenennen). Dann funktioniert nämlich gar nichts mehr.

Angenommen im Beispiel des TE kommt jemand auf die Idee, das '_' in Prozedurnamen ein NoGo sind (was nicht abwegig ist, denn sie sind es ). Eben wurde gespeichert, das 'Hello_World' aufgerufen werden soll, dann wird umbenannt und dann geht gar nichts mehr und im ungünstigsten Fall werden die abgespeicherten Aufrufe (als String) komplett unbrauchbar.

Alternativen? Z.B. Methodenattribute einführen, d.h. 'Hello_World' wird mit dem Attribute 'HELLOWORLD' dekoriert. Dann ist das Verfahren immun gegen Refactorings. Natürlich: Wer Attributparameter verändert, hat selbst schuld.

Mit Sicherheit gibt es bessere Ideen für eine robustere Umsetzung der Anforderung.

(*) Ein anderer Ansatz der gleichen Art: 'FindComponent'

[hanvas]

Zitat von Dejan Vu:

Mit Sicherheit gibt es bessere Ideen für eine robustere Umsetzung der Anforderung.

Das war es doch was ich schon ansatzweise beschrieben (und den größten Teil des Überbaus gleich mitgeliefert) habe, indem man das Objekt welches die später aufzurufende(n) Methoden bereistellt diese selbst bei einer zentralen Instanz registrieren (und gff. deregistrieren) lässt, kann man die Methoden unter einem beliebigen Namen aufrufen, die Methode ist immun gegen Refactorings, relativ einfach und benötigt außer einer Liste keine weiteren Ressourcen, außerdem ist es nicht nötig das man die Objekte die Methoden bereitstellen von TForm oder TDataModule ableitet, möglich ist es natürlich trotzdem.

cu Ha-Jö

[Dejan Vu]

Oder so. Hab ich doch glatt überlesen.