Deklaration oder nicht?

[Delbor]

Hi zusammen

Ich arbeite zwar unter Delphi Alexandria, aber zur Zeit unter einem Beispielprogramm, das höchstens mit Delphi 10 kompiliert wurde. Mein Stolperstein ist folgendes:

Delphi-Quellcode:

procedure PrintBitmap(Printer: TPrinter; Bitmap: TBitmap);

Dies ist nicht etwa die Deklaration im Interface, sondern der Prozedurkopf im implementation-Teil. Nach den neuen Deklarationsregeln (Deklaration von Variablen bei Erstgebrauch) könnte ich mir vorstellen, dass ähnliches auch für Prozeduren gilt.
Aber dieses Beispielprogramm gibt es schon seit vielen Jahren, und es muss auch mit älteren Versionen lauffähig sein.
Hier das Embarcadero-Wikki und seine Aussagen zur Deklaration unter Delphi 11 Alexandria.

Meines Wissens war es unter Pascal seit Jahrzehnten möglich, Prozeduren zu verwenden, die nicht innerhalb einer (Form-)Klasse deklariert sind, sondern zB. kurz vor oder nach der Formvariablen (beliebig im interface-Teil?).

Aber dass eine Prozedur gar nicht deklariert ist, kann ich mir schlicht nicht vorstellen.
Was hab ich übersehen? Wie lange gibt es mittlerweile die neuen Deklarationsregeln?

Gruss
Delbor

[Sherlock]

Kurz: Das war schon immer so. Im Prinzip mußt Du im Interface nur deklarieren, was auch außen (also außerhalb der Unit) sichtbar/verwendbar sein soll.

Sherlock

[Delbor]

Hi Sherlock

Zitat:

Kurz: Das war schon immer so. Im Prinzip mußt Du im Interface nur deklarieren, was auch außen (also außerhalb der Unit) sichtbar/verwendbar sein soll.

Und woher bekam dann Delphi seinen Ruf der Typsicherheit? Ich verstehe unter Typsicherheit nicht nur den sicheren Umggang mit Variablen, sondern auch den mit Prozeduren und Funktionen..

Gruss
Delbor

[jaenicke]

Wenn du einen Prozedurtyp

Delphi-Quellcode:

TExample = procedure(...)

hast, kannst du einer Variable dieses Typs auch nur Prozeduren zuweisen, deren Signatur dazu passt.
Das ist kurz gesagt Typsicherheit: Du kannst verschiedene Typen nicht einfach so untereinander zuweisen.

Ob die Prozedur im Interface der Unit nach außen veröffentlicht wurde oder ob die Variable im Prozedurkopf oder inline im Code deklariert wurde, spielt dabei keine Rolle.

[Benmik]

Gehe ich recht in der Annahme, dass ihr alle trotzdem jede Prozedur auch im Interface deklariert, auch wenn sie nur in der Unit verwendet wird?

[jaenicke]

Zitat:

Zitat von Benmik (Beitrag 1517131)

Gehe ich recht in der Annahme, dass ihr alle trotzdem jede Prozedur auch im Interface deklariert, auch wenn sie nur in der Unit verwendet wird?

Das wäre mir viel zu unübersichtlich. Wenn etwas für andere Units direkt veröffentlicht werden soll, verwende ich Klassenmethoden, damit man beim Aufruf im Quelltext sieht, wo die Methode herkommt. Ich mag global verfügbare einfache Prozeduren nicht in eigenem Code. Deshalb stehen lose Prozeduren bei mir in aller Regel nur unter implermentation.

[Delbor]

Hi zusammen

Zitat:

Gehe ich recht in der Annahme, dass ihr alle trotzdem jede Prozedur auch im Interface deklariert, auch wenn sie nur in der Unit verwendet wird?

Zumindest ich gehöre zu dieser Fraktion. Inlinedeklarationen gewöhne ich mir nicht an, auch wenn dies eine ganz bestimmte Schreibweise im Code voraussetzt, die von diesem deutlich abweicht. Kurz zum Interfaceteil/Prozedurkopf wechseln und zurück ist auch dank Delphis IDE kein Problem.

Ich hab das erst so verstanden, dass ich dich gründlich missverstanden habe, bzw. dass ich mit meiner ungenügenden Beschreibung zu einem Missverständnis verleitet habe.

Missverständnis hin oder her ich zeig das mal am besten am konkreten Beispiel. Hier habe ich von einer Bitmap geschrieben, die ich mit einem Fremdprogramm einer PDF hinzugefügt habe (Bezahlt-Stempel). Dieser Stempel wird in meinem Programm nicht angezeigt, in einer Demo des Herstellers meiner PDF-Komponenten hingegen schon.
Da ich verständlicherweise wissen will, woran das liegt, habe ich damit begonnen, den Code zu klonen (damit ich nichts überlese).

Und in eben dieser Demo ist die gezeigte Prozedure ohne wirkliche Deklaration enthalten:

Delphi-Quellcode:

procedure PrintBitmap(Printer: TPrinter; Bitmap: TBitmap);
var
  InfoHeaderSize, ImageSize: DWORD;
  InfoHeader: PBitmapInfo;
  Image: Pointer;
begin
   xxx
end;

Die drei x stehen für einige Zeilen Code, die hier nicht interessieren. Diese Prozedur wird aus verschiedenen Routinen aufgerufen.
Eine Suche in der aktuellen Datei über den Suchen-Dialog erzeugt folgende Rückmeldung:

Zitat:

F:\Embarcadero Project Corner\Delphi Alexandria Corner\Delphi Alex Winsoft Demos 5-2\Viewer\Main.pas [2]
F:\Embarcadero Project Corner\Delphi Alexandria Corner\Delphi Alex Winsoft Demos 5-2\Viewer\Main.pas [2]
F:\Embarcadero Project Corner\Delphi Alexandria Corner\Delphi Alex Winsoft Demos 5-2\Viewer\Main.pas(518): procedure PrintBitmap(Printer: TPrinter; Bitmap: TBitmap);
F:\Embarcadero Project Corner\Delphi Alexandria Corner\Delphi Alex Winsoft Demos 5-2\Viewer\Main.pas(607): PrintBitmap(Printer, Bitmap);

Ein Code-Ausschnitt rund um die in der Meldung genannte Zeile 607:

Delphi-Quellcode:

            if Pdf.FormFill then
            begin
              Bitmap := Pdf.RenderPage(0, 0, Printer.PageWidth, Printer.PageHeight, ro0, [rePrinting]);
              try
                PrintBitmap(Printer, Bitmap);  // <= Zeile 607:
              finally
                Bitmap.Free;
              end;
            end

Es gibt in dieser Unit auch keinen entsprechenden Prozedur-Typ.

Interessant ist, dass die CloneForm, mit deren Hilfe ich ermitteln will, wieso dieses Demoprogramm meine Pdfs mt dem Stempel anzeigt, mein eigenes Programm aber nicht, die Prozedur PrintBitmap und deren Aufruf(e) enthält, aber schon ohne Kompilierung als unbekannt kennzeichnet. Das bedeutet, dass eine Deklaration im Original vorhanden ist, aber weder von Delphi geschweige denn von mir gefunden wird...

Als Info vielleicht noch wichtig: Das Programm verwendet die DLL PDFium...

Gruss
Delbor

[himitsu]

Und was ist nun mit der Zeile 518?
Was ist da drumrum?




Es gibt "Methoden" in Klassen (und auch in Records).

Dort ist in der Typdeklaration immer eine "Forward"-Deklaration vorhanden (egal ob im Interface oder der Implementation)
und dann in der Implementation die eigentlich Deklaration der Methode.




Einzelne Prozeduren/Funktionen (nicht in einer Klasse) stehen ebenfalls immer in der Implementation
und man kann optional auch vorher eine Forward-Deklaradion angeben.

Entweder im Interface, oder auch in der Implementation (hier aber mit

Delphi-Quellcode:

forward;

markiert).




Auch Klassen und und Zeigertypen kann man als Forward, vor dem eigentlichen Typen deklarieren, so lange es innerhalb des selben TYPE-Blocks steht.




Über ein "Interface" kann man auch getrennt, sogar in einer anderen Unit, für eine Klasse alles quasi als abgetrenten "Forward" deklarieren,
ebenso wie über eine Vererbung als

Delphi-Quellcode:

virtual; abstract;

eine Methode forwarden.

[Delbor]

Hi himitsu

Zitat:

Über ein "Interface" kann man auch getrennt, sogar in einer anderen Unit, für eine Klasse alles quasi als abgetrenten "Forward" deklarieren,

Sogar in einer andern Unit? Oder DLL?

Muss morgen mal sehen - vielleicht ist mir gerade ein Licht aufgegangen...

Gruss
Delbor

[himitsu]

via COM/ActiveX auch in einer anderen EXE oder gar in einem anderen PC.

[jaenicke]

Zitat:

Zitat von Delbor (Beitrag 1517136)

Interessant ist, dass die CloneForm, mit deren Hilfe ich ermitteln will, wieso dieses Demoprogramm meine Pdfs mt dem Stempel anzeigt, mein eigenes Programm aber nicht, die Prozedur PrintBitmap und deren Aufruf(e) enthält, aber schon ohne Kompilierung als unbekannt kennzeichnet. Das bedeutet, dass eine Deklaration im Original vorhanden ist, aber weder von Delphi geschweige denn von mir gefunden wird...

Du hast ja sowohl den Aufruf als auch die Funktion selbst gepostet. Mehr wird nicht gebraucht.

Logischerweise musst du die Prozedur in der Unit oberhalb des Aufrufs einfügen.

[dummzeuch]

Zitat:

Zitat von Benmik (Beitrag 1517131)

Gehe ich recht in der Annahme, dass ihr alle trotzdem jede Prozedur auch im Interface deklariert, auch wenn sie nur in der Unit verwendet wird?

Nein. Das ist das gleiche wie mit private deklarierten Methoden: Was außerhalb nicht benutzt wird, braucht auch nicht exportiert zu werden. Es ist schon schlimm genug, dass private Methoden in der Klassendeklaration im Interface auftauchen, die haben da eigentlich nichts zu suchen.

[himitsu]

Oberhalb ist es

Zitat:

F:\...\Main.pas(518): procedure PrintBitmap(Printer: TPrinter; Bitmap: TBitmap);
F:\...\Main.pas(607): PrintBitmap(Printer, Bitmap);

Aber
* Schreibfehler
* oder falscher Gültigkeitsbereich

[Delbor]

Hi zusammen

Um mal die Sache mit PrintBitmap aufzuklären:
in zeile 518 befindet sich im Original die "ominöse" Prozedure PrintBitmap uund in Zeile 607 der Aufruf derselben - wie jeanicke schrieb, die als Deklaration gültige propzedur und darunter deren Aufruf.
In meinem Clon war das genau umgekehrt, weshalb die beiden Zeilen sofort angemeckert wurden. Das hab ich geändert und gut ist.

Die Sache mit dem Stempel, der nicht angezeigt wird, ist zwar zurzeit ungelöst. Mal sehen, ob mir gestern das richtige Liccht aufgegangen ist...

Ich gebe auf jeden Fall bescheid.

Gruss
Delbor

[jaenicke]

Zitat:

Zitat von Delbor (Beitrag 1517176)

wie jeanicke schrieb, die als Deklaration gültige propzedur und darunter deren Aufruf.
In meinem Clon war das genau umgekehrt, weshalb die beiden Zeilen sofort angemeckert wurden. Das hab ich geändert und gut ist.

Hintergrund:
Delphi ist ein One-Pass Compiler und kann dementsprechend nicht weiter unten in einer Unit nach der Prozedur suchen und zurückkehren. Deshalb ist der Compiler so schnell.

[Delbor]

Hi jaenicke


Danke für die Info!
Was mein Licht betrifft - das hat sich im Winternebel verloren.

Genauer: das Demoprogramm bindet in der Mainunit die Unit PDFium ein, mein Unitclone nicht. Eben habe ich mein project geöffnet: Die Mainform und der Pdf-BasisFrame binden diese Unit ebenfalls ein; beide haben über diese Unt zugriff auf die Pdfium-DLL. Meine Suche geht also weiter...

Gruss
Delbor

[Benmik]

Zitat:

Zitat von dummzeuch (Beitrag 1517147)

Es ist schon schlimm genug, dass private Methoden in der Klassendeklaration im Interface auftauchen, die haben da eigentlich nichts zu suchen.

Immer wieder interessant die Bandbreite der Ansichten und Emotionen. Ich habe mir angewöhnt, in die Klassenmethoden einer Form ausschließlich den Verweis auf eine Routine zu schreiben, der ich dann einen aussagekräftigeren Namen geben kann als Button1Click, und diese Routinen im Code getrennt von den "autochthonen" Klassenmethoden zu halten. Allerdings habe ich diese Routinen dann auch immer als Methoden implementiert. Macht das eigentlich irgendeinen Unterschied (außer der einfachereren Referenzierbarkeit von Formkomponenten), ob man Methoden oder einfache Prozeduren verwendet?

[peterbelow]

Zitat:

Zitat von Benmik (Beitrag 1517223)

Zitat:

Zitat von dummzeuch (Beitrag 1517147)

Es ist schon schlimm genug, dass private Methoden in der Klassendeklaration im Interface auftauchen, die haben da eigentlich nichts zu suchen.

Immer wieder interessant die Bandbreite der Ansichten und Emotionen. Ich habe mir angewöhnt, in die Klassenmethoden einer Form ausschließlich den Verweis auf eine Routine zu schreiben, der ich dann einen aussagekräftigeren Namen geben kann als Button1Click, und diese Routinen im Code getrennt von den "autochthonen" Klassenmethoden zu halten. Allerdings habe ich diese Routinen dann auch immer als Methoden implementiert. Macht das eigentlich irgendeinen Unterschied (außer der einfachereren Referenzierbarkeit von Formkomponenten), ob man Methoden oder einfache Prozeduren verwendet?

Meines Erachtens sollte man einer "gedropten" Komponente immer sofort einen aussagekräftigen Namen geben, dann haben auch die von der IDE erzeugten Eventhandler vernünftige Namen. Es macht aber oft durchaus Sinn, den Löwenanteil des Kodes in einer eigenen Methode zu implementieren, vor allem, wenn man diese von verschiedenen Stellen aus benötigt.

[jaenicke]

Zitat:

Zitat von peterbelow (Beitrag 1517243)

Meines Erachtens sollte man einer "gedropten" Komponente immer sofort einen aussagekräftigen Namen geben, dann haben auch die von der IDE erzeugten Eventhandler vernünftige Namen.

Wenn man diese später umbenennt, benennt Delphi diese Eventhandler analog um. Dennoch ist die sofortige Benennung natürlich sinnvoller.

Zitat:

Zitat von peterbelow (Beitrag 1517243)

Es macht aber oft durchaus Sinn, den Löwenanteil des Kodes in einer eigenen Methode zu implementieren, vor allem, wenn man diese von verschiedenen Stellen aus benötigt.

Das macht grundsätzlich immer Sinn, wenn es nicht absolut trivial ist. Denn ein XyzClick sagt nur, dass auf Xyz geklickt wurde. Ruft man darin aber z.B. ShowCalendar auf, weiß man sofort, was dort passieren soll, ohne den Code dahinter anzuschauen (und festzustellen, dass dieser einen Kalender anzeigt).

[dummzeuch]

Zitat:

Zitat von peterbelow (Beitrag 1517243)

Meines Erachtens sollte man einer "gedropten" Komponente immer sofort einen aussagekräftigen Namen geben, dann haben auch die von der IDE erzeugten Eventhandler vernünftige Namen.

Das sehe ich genauso und deshalb ist der (automatisch aufgerufene) Rename Component Expert in GExperts bei mir der am zweithäufigsten benutzte Experte, nach dem Code Formatter. Meine Kollegen bekommen immer metaphorisch eins hinter die Löffel, wenn ich in eingechecktem Sourcecode irgendwo Default-Namen sehe.

Zitat:

Zitat von peterbelow (Beitrag 1517243)

Es macht aber oft durchaus Sinn, den Löwenanteil des Kodes in einer eigenen Methode zu implementieren, vor allem, wenn man diese von verschiedenen Stellen aus benötigt.

Insbesondere kann man diesen Code dann auch deutlich leichter aus dem Formular in eine andere Unit / eine andere Klasse verschieben. Und spätestens dann merkt man, wenn man in ihm auf Controls im Formular zugreift, wo man es besser vermeiden sollte.

[Benmik]

Zitat:

Zitat von jaenicke (Beitrag 1517244)

Denn ein XyzClick sagt nur, dass auf Xyz geklickt wurde. Ruft man darin aber z.B. ShowCalendar auf, weiß man sofort, was dort passieren soll, ohne den Code dahinter anzuschauen...

Genau! :thumb: Bei mir als Privatkodierer dürfen die Bezeichnungen auch noch auf Deutsch sein, mit Umlauten (wozu eigentlich wurde die IDE unicodefähig gemacht?) und gern länger, wenn's der Wahrheitsfindung äh der Klarheit dient.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1517244)

Denn ein XyzClick sagt nur, dass auf Xyz geklickt wurde. Ruft man darin aber z.B. ShowCalendar auf, weiß man sofort, was dort passieren soll, ohne den Code dahinter anzuschauen (und festzustellen, dass dieser einen Kalender anzeigt).

Da hatte ich doch mal was zu geschrieben: When, What, Why!

[jaenicke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1517301)

Da hatte ich doch mal was zu geschrieben: When, What, Why!

:thumb: