Deklaration oder nicht?

[jaenicke]

Zitat von Delbor:

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 von 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?

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 von Delbor:

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 von dummzeuch:

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 von Benmik:

Zitat von dummzeuch:

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 von peterbelow:

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 von peterbelow:

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 von peterbelow:

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 von peterbelow:

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.