Entwickler-Ecke

Delphi Language (Object-Pascal) / CLX - Proceduren in Unit auslagern


uli - Di 21.01.03 10:09
Titel: Proceduren in Unit auslagern
Hallo Leute,

ich möchte Druckfunktionen in eine separate Unit auslagern.
Der Vereinbarungsteil sieht folgendermaßen aus:


Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
unit Drucken;

interface

uses
     Printers;
Type
   TDrucken=class(TObject)
    procedure InitPrinter;
    procedure PrintNachweise;
   end;

var
   DruckerHandle: Integer;
   DruckString: String;
   x,y: Integer;          //Druckkoordinaten

implementation


Im Hauptformular steht folgender Code:

Quelltext
1:
2:
3:
4:
procedure THauptForm.BitBtn1Click(Sender: TObject);
begin
        PrintNachweise;
end;


Beim Compilieren bekomme ich die Fehlermeldung

Undefinierter Bezeichner:'PrintNachweise'.

Wer kann mir sagen, wo der Fehler liegt?

Gruß Uli.


smiegel - Di 21.01.03 10:45

Hallo,

als 1., sofern noch nicht geschehen, in der Uses-Klauses die unit Drucken aufnehmen.

Die Procedure PrintNachweise ist eine Methode deines Drucken-Objekts. Wo wird das Objekt initialisiert bzw. erzeugt?


Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
var
  MyDruckObj:TDrucken;

// in der OnCreate des Hauptformulars:
  MyDruckObj:=TDrucken.Create;

// Zugriff auf die Methode
procedure THauptForm.BitBtn1Click(Sender: TObject); 
begin 
  MyDruckObj.PrintNachweise; 
end;


Daran denken, dass das DruckObjekt in der OnDestroy des Hauptformulars mit MyDruckObj.Free wieder freigegeben wird.


uli - Di 21.01.03 11:46

Hallo smiegel,

danke für die Antwort.
Jetzt funktioniert die Sache.
Mir ist aufgefallen, dass manche Objekte mit Create initialisiert werden
müssen und manche nicht.
Was ist da der Unterschied?
Und noch eine Frage.
Muss ich in einer Unit in jedem Fall eine Klasse deklarieren oder kann ich auch nur die in der Unit zusammen gafassten Proceduren in den Interface-Teil schreiben und dann von einer Anwendung nur über den Procedur-Namen auf die Proceduren zugreifen?

Gruß Uli.


smiegel - Di 21.01.03 11:49

Hallo uli,

ein Objekt muss immer mit Create erzeugt werden, sofern es sich von TObjekt ableitet. Ohne wenn und aber.

Sorry, aber Deine weiter Frage verstehe ich nicht :-(


uli - Di 21.01.03 12:04

Ich lege eine Unit an und packe dort alle Proceduren rein, die ich im Hauptprogramm irgendwann mal zum Drucken brauche.
z.B. so:


Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
unit Drucken; 

interface 

uses 
     Printers;
 
Type 
    procedure InitPrinter; 
    procedure PrintNachweise; 

var 
   DruckerHandle: Integer; 
   DruckString: String; 
   x,y: Integer;          //Druckkoordinaten 

implementation 

procedure InitDrucker;
begin
        //Drucker wird initialisiert
end;

procedure PrintNachweise; 
begin
        //Nachweis drucken
end;



Dann habe ich meine Unit vom Hauptformular,
dort trage ich die Unit im Uses-Teil ein und kann dann auf die Proceduren in der Unit zugreifen.
z.B. so:


Quelltext
1:
2:
3:
4:
5:
procedure THauptForm.BitBtn1Click(Sender: TObject); 
begin
        InitDrucker; 
        PrintNachweise; 
end;



Gruß Uli.


foxy - Di 21.01.03 12:05

ich denke ich habe sie verstanden, er meint denke ich wie er die proceduren und Functionen in der Unit deklarieren soll , das er sie aufrufen muss

das iss eigentlich schnuppe achte nur darauf, also ich schreibe die immer in den Interface Teil, dann brauch ich nur die werte weiter zu geben egal von welcher unit du drauf zugreifst und dann brauchst du auch nicht mehr drucken.xxx(xxx,xxx); zu schreiben sonder dann nur noch xxx(xxx,xxx); wenn du die entsprechende Unit als Uses deklariert hast :wink:


smiegel - Di 21.01.03 12:08

Hallo uli,


Quelltext
1:
2:
3:
Type 
    procedure InitPrinter; 
    procedure PrintNachweise;


das geht so nicht. Lass Type weg, dann müsste es gehen.


uli - Di 21.01.03 14:33

Ich habe Type weggelassen und es funktioniert prima.
Wenn man sein Programm nur mal übersichtlicher aufbauen will ist die zweite Sache einfacher.
Wie ich festgestellt habe braucht man das mit der Klasse deklarieren nur, wenn man Methoden nutzen will, die man von einer anderen Klasse erbt und damit in der eigenen neuen Klasse nutzen kann. :idea:
Oder liege ich da falsch :?:

Gruß Uli.


foxy - Di 21.01.03 15:51

uli das iss nur eine Möglichkeit ein Programm übersichlicht zu machen eine andere iss die sache dll ... das iss ne gute sache :wink:


uli - Di 21.01.03 16:11

Hallo Heiko,

ich muss mich erstmal mit den alltäglichen Sachen im Delphi befassen und da gibt es noch eine ganze Menge, denn solange programmiere ich noch nicht mit Delphi.:wink:
Aber Danke für den Tip, irgendwann werde ich warscheinlich auch um Dll's nicht rum kommen.

Gruß Uli


smiegel - Di 21.01.03 18:12

Hallo,

foxy schrieb:
Zitat:

dll ... das iss ne gute sache


Finde ich nicht. Der Aufwand DLL's zu pflegen ist weitaus größer als normale Delphi-Units. Bei jeder Änderung DLL übersetzen, das Programm, dass die DLL benötigt neu starten ob zu überprüfen ob die Änderungen auch wirksam waren, usw...

Was mit DLL's alles passieren kann und dass das nicht das Ei des Kolumbus ist --> siehe Windows!!