Office: References/Verweise

Hallo zusammen,

aus zahlreichen Beiträgen habe ich entnommen, dass eine gute Fehlerbehebung für jegliche Probleme mit Verweisen das Late Binding ist. Ich habe daher in meinem Projekt alles (auch) in Late Binding realisiert, da ich aber beim Coden gern die IntelliSense genutzt habe, habe ich nen Switch eingebaut und beide Varianten modular implementiert. Jetzt überlege ich, ob ich das nutze um zB zu Prüfen, ob der Verweis vorhanden ist und bei Nichtvorhandensein Late- sonst EarlyBinding nutze oder einfach die Early Binding Module als unnötigen Ballast rauslösche.

Zu meiner Frage... Hat das Late Binding irgendwelche Nachteile (außer des höheren Programmieraufwands und der fehlenden IntelliSense)?

Danke schonmal!

:)

 

Bei Late Binding wird das entsprechende Objekt erst mit Aufruf geladen. Gerade bei sehr großen Objekten (Word, Excel) verlängert sich dadurch die Laufzeit während des Aufrufs. Bei Early Binding werden die Objekte gleich mit Anwendungsstart geladen, womit der Anwendungsstart verlängert wird.
Das ist also kein Nachteil, sondern nur eine Verschiebung, der man sich bewusst sein sollte.

Nachteil neben der fehlenden IntelliSense: Man muss alle verwendeten Konstanten des Objektes selber und extra definieren, weil diese bei diesem Zugriff unbekannt bleiben.

 

Danke Eberhard!

Wenn ich das richtig verstanden habe, wird beim Early Binding durch die Objekte aber auch beim Anwendungsstart bereits der Arbeitsspeicher belegt, während ich beim Late Binding die Möglichkeit habe, die Objekte nicht nur später erst zu laden, sondern sie auch nach Abwägung von Laufzeit gegen Speicher zwischendurch wieder freigeben kann/sollte?

Wenn das so stimmt, stellt es für mich eher noch einen weiteren Vorteil dar, weil ich so selbst entscheiden kann, wann ich die Laufzeit einsetze. Ich kann ja auch gleich zum Anwendungsstart das "Late" Binding setzen und so quasi zum gleichen Zeitpunkt die Laufzeit in Anspruch nehmen, wenn ich dann die Objekte nicht mehr freigebe, habe ich doch quasi das gleiche Auslastungsprofil?

 

Das meinte ich mit dem höheren Programmieraufwand. *wink.gif*

 

Ob man die Speicherbelegung spürbar selber steuern kann? Da bin ich überfragt, wäre aber nicht so optimistisch.
Das wird aber praktisch auch kein Schwerpunkt sein. Ich persönlich bevorzuge, solche Objekte mit erstem Aufruf als Property anzulegen und mit dieser einen Instanz des Objektes und auch eigenen Instanz für meine Anwendung dann so lange zu arbeiten wie nötig. Im Voraus zu wissen und vorzusehen, wie lange ein User damit arbeiten wird, ist speziell und in der Regel nicht möglich.

 

https://groups.google.com/forum/?hl=...vb/3pw-TGc9PSo

Hier - und an vielen anderen Stellen - gibt es eine große Diskussion über die Freigabe von Objekten, deren Sinn und Unsinn. Auch wenn das weit über meine Erfahrung oder mein Wissen hinausgeht, entnehme ich der Diskussion, dass man darin übereinstimmt, dass die Ressourcenfreigabe generell gut ist. Die Gegner der Set = Nothing Enthusiasten sind nur der Meinung, man soll das System seinen Job tun lassen und es also lassen, wenn nachfolgend das System eh handeln würde.

Daher glaube ich schon, dass man mit Late Binding zumindest den Ressourcengebrauch durchaus steuern kann, fraglich bleibt da eher wie effizient beim Early Bindung agiert wird. Wird vielleicht doch erst beim ersten Nutzen der Referenz die Ressource beansprucht (glaub ich eher nicht).

Liege ich falsch damit, dass ich davon ausgehe, dass beim Early Binding zum Start des Moduls referenziert wird und erst mit closing des Moduls released wird? Vielleicht kann auch hier noch mit Set = Nothing früher freigeben aber doch auf keinen Fall erst später referenzieren oder? Das müsste mit Late Binding doch IMHO funktionieren....?

 

\@Eberhard:

Vielleicht bin ich ja auf dem Holzweg, aber bisher bin ich immer davon ausgegangen, daß bei beim Programmstart die COM-Schnittstellenbeschreibungen gelesen werden und die Objektinstanzen erst zur Laufzeit durch das Programm mit der Anweisung "New" erzeugt werden. Das würde bei der Ressourcenbelegung aber ein ganz anderes Verhalten bedeuten, wenn das so wäre, wie du das beschreibst und kann ich auch aus der Praxis heraus nicht bestätigen.

Ulrich

 

ok, das würde dann bedeuten, dass man bei Early Binding und bei Late Binding den Zeitpunkt der Ressourcennutzung selbst bestimmen kann. Das würde an der Stelle fürs Late Binding also weder Vor- noch Nachteil bedeuten...

 

Ja. Du kannst leider keine Ereignisse der Objekte aus der Bibliothek konsumieren.

 

ok, das überrascht mich jetzt. Ich war davon ausgegangen, dass ich beim Late Binding über das zunächst undefinierte Objekt aber den "eindeutigen" String. Zum Beispiel "ADODB.Connection" genauso Zugriff auf die Bibliothek erhalte wie das im Early Binding auch ist.

Kannst Du mir ein Beispiel nennen, was nicht funktioniert?

Ich habe gedacht, egal ob
Microsoft ActiveX Data Objects 6.0 Library oder
Microsoft ActiveX Data Objects 6.1 Library
und wo die DLLs liegen, da beide mit dem gleichen String gefunden werden, können beide angesprochen werden. Liege ich da falsch?

Ich dachte eher mit dem Vorteil der Versionskompatibilität geht selbstredend natürlich der Nachteil einher, dass neuere Funktionen (so auch Ereignisse) entweder nicht genutzt oder speziell gehandelt werden müssen. Meinst Du das?

Gruß Christian

 

Für Ereignisse nicht.
Bei Late Binding deklarierst du deine Objekte ja nur als Object. Der generische Typ Object hat aber einfach keine definierten Ereignisse.

 

Hallo
Early binding dient der Ilse, dem Compiler und wie schon von Sonic8 erwähnt der einfachen Verwendung von Ereignissen. Der Compiler ermittelt zur Compilierzeit mit Hife der Typelib die Position (Offset) der gewählten Method/Funktion.

Late binding ist u.U. nicht so Versionszickig, hat dafür aber etwas mehr Laufzeitbedarf da die Methoden der Klasse hier nicht direkt über das Offset angesprochen werden sondern über die IDispatch-funktionen erst zur Laufzeit ermittelt werden müssen. Für einfache Calls ist diese zusätzliche laufzeit wohl aber vernachlässigbar.

 

Bei ADO hat sich die letzten 20 Jahre eh nichts geändert.
Die Klassen werden höchstens irgend wann abgedreht. *grins

Hier noch ein Artikel zum Thema IDispatch und warum die Laufzeit doch leiden kann, wenn entsprechend Parameter vorhanden sind: CallByName - GoTo RetroCode

Grade bei einer Datenklasse würde ich niemals LateBinding verwenden, da bei der Arbeit damit Properties/Methoden/Funktionen mitunter sehr oft aufgrufen werden müssen.

Und zu den Events:
Die nutzen ja nur ganz wenige Entwickler, sonst wäre dir das ja schon lange aufgefallen.
Das du nicht einfach im Objektkatalog nachschaust, was da betroffen ist wirkt allerdings ziemlich befremdlich.

Und zum Thema Ressourcen und Speicherbelegung:
Darauf hat LateBinding keinen Einfluss.
Eine COM Server ist eine Anwendung die unabhängig von Access läuft und sich die Daten lädt. Darauf hat der Client keinen Einfluss.
Es geht nur um die Schnittstelle, wie die Daten angesprochen werden können wie bereits daolix schön ausgeführt hat.

 

Danke nochmal für alle Hinweise! Nun bin ich doch schon wieder drauf und dran doch auf Early Binding umzudenken...

Sorry Markus. Ich mache beruflich was gaaaaanz anderes und beschäftige mich mit der Programmierung, Access und ähnlichem nur privat. Das merkt man nicht nur an meinen dummen Fragen, sondern eben auch daran, dass ich ohne jegliche professionelle Ausbildung in der Hinsicht, nicht darauf komme, dort nachzusehen, wo es ein Profi tun würde :-(

Hat noch jemand einen Tipp, wie/ob man beim Early Binding die "Versionszickigkeit" handlen könnte? Wenn ich beim Kompilieren alle (zumindest die mir vorliegenden)neueren und älteren Verweise aktiviere, nimmt er auch alle Verweise mit in mein Paket? Oder beschränkt sich der Kompiler auf die neueste Version?

Beispiel:

 

Was hast du denn konkret für ein Problem damit?
Es gibt keine einheitliche Lösung für alle Situationen.