Hallo,

ich habe ein Problem mit Option Strict On. Diese Einstellung erlaubt ja bekanntlich kein spätes Binden. Ich komme aber nicht so ganz damit klar, wie das mit dem frühen Binden ablaufen soll.

Angenommen ich habe bisher einer Variable den Datentyp Object zugewiesen. Dann ist das - nach meinem bisherigen Verständnis - spätes Binden.
Doch welchen Datentyp soll ich denn der Variable zuweisen, um früh zu binden?

Vielleicht kann mir das jemand näher bringen, da meine Literatur darüber nicht viel hergibt, zumindest nicht für mich verständlich.

Vielen Dank im Voraus!

MfG
Dude

Klick mich

Ich versuche es mal kurz zu erklären:

Early Binding heisst das Du den Objekt-Typ gleich bei der Deklaration bekannt gibst. So z.B.:



Das heisst der Objekt-Typ muss bereits zur Deklaration bekannt sein. Bei Fremd-Objekten ist dafür nötig das Du einen Verweis auf das Fremd-Objekt (DLL oder so) in Deinem Projekt setzt.

Den gleichen Effekt wie oben erreichst Du bei Late Bindung auf folgendem Weg:



Bei der Deklaration der Variable ist der Typ des Objektes also völlig unbekannt.

Für diese Art der Objekt-Ansprache brauchst Du keinen Verweis in Deinem Projekt sondern musst nur sicherstellen das ein passendes Objekt in der Registry registriert ist.

Nachteile von Late Binding:

- kein IntelliSense
- keine Compiler-Prüfung, Fehler in der Ansprache von Methoden oder Eigenschaften fallen erst zur Laufzeit auf

Vorteile von Late Binding:

- völlig unabhängig von der Version des Objektes auf dem Zielrechner

Daher wird Late Binding oftmals dort eingesetzt wo man sich nicht sicher ist welche Datei-/Treiber-Version des anzusprechenden Objektes auf dem Zielrechner installiert ist.

Z.B. Du sprichst in Deiner App Excel an. Setzt Du nun auf Deinem Developer-Rechner den Verweis auf Excel wird der Verweis auf das auf Deinem Developer-Rechner installierte Excel registriert. Hast du nun Excel 2007 drauf und der Zielrechner auf dem Du Deine App laufen lässt nur Excel 2003 dann kracht es im Gebälk weil die Version des Verweise nicht übereinstimmt ... dieser Umstand wird dann auch passend salopp als die Dll-Hell betitelt.

Aber VB.NET liefert dafür mittlerweilen die mMn wesentlich bessere Alternative Verweise direkt zu laden und als lokale Kopie ins Projekt einzubinden. So kann man alle Vorteile von Early-Binding nutzen und entgeht trotzdem der Dll-Hell (die mich persönlich schon oftmals an den Rande des Wahnsinns getrieben hat).

Gruß

Rainer

Danke für die ausführliche Erklärung, Rainer. Das hat mir wirklich geholfen, das Thema zu verstehen.

In meinem Fall wäre es tatsächlich wichtig, das möglichst unabhängig von einer Version zu gestalten, da es sich um den Internet Explorer handelt.

Auf die Gefahr hin deine Mühe überzustrapazieren: Wo finde ich denn Informationen darüber, wie ich das mit dem lokalen Einbinden eines Verweises mache?

Bisher startete ich den IE, indem ich einer Variable den Datentyp Object zugewiesen habe und dann eben CreateObject("InternetExplorer.Application")

Bei einem Kumpel, der das testen sollte, endete das schon in einer Fehlermeldung - während es bei mir aber einwandfrei funktioniert hat. Dann bekam ich hier im Forum den Tipp, alles mit Option Strict On zu schreiben.
Das hab ich dann getan, blieb aber leider an dieser Stelle hängen.

an welcher codezeile tritt denn der fehler auf..

@ Dude32

Was möchtest Du denn genau bezwecken, bzw. wozu brauchst Du den Zugriff auf den IE?

Könnte Dir unter Umständen auch das WebBrowser-Control weiterhelfen?

Gruß

Rainer

Dude23 schrieb:

In meinem Fall wäre es tatsächlich wichtig, das möglichst unabhängig von einer Version zu gestalten, da es sich um den Internet Explorer handelt.

beachte, dass Strict Off nur bei Com-Zugriffen sinnvoll ist, wie raist10 erläutert hat.
Also bei der Verwendung von Klassen, die nicht zum .Net-Framework gehören.
Innerhalb des Framework (verwalteter Code) ist Strict Off immer dirty.
Dirty bedeutet: Dasselbe ist in jedem Fall mit Strict On sicherer programmiert, und wenn ein Programmierer die Wahl hat zwischen mehr oder weniger Sicherheit, bei gleichem Aufwand, ist das im Grunde keine Wahl ;).

Das unsichere an Strict Off - Code ist, dass der Compiler selbständig TypUmwandlungen vornimmt, die du dem Code nicht ansehen kannst. Meistens geht das gut, und irgendwann treten Umstände ein, wos nicht hinhaut (entweder bei Code-Änderungen, gelegentlich sogar bei UserEingaben), und dann gibts ganz unerwartete Laufzeit-Fehler an Stellen, die bisher "tadellos" liefen - total mühsam zu debuggen.

Bei Strict On hingegen gibt dir die IDE schon von vornherein Bescheid, sodaß du gleich mit den richtigen Datentypen programmierst, und diese überflüssigen und tückischen LaufzeitFehler erst gar nicht auftreten können.
gugge Option Strict On!

Also pack deine Com-Zugriffe in spezielle Klassen und Module, und programmier den verwalteten Code sauber.
Das Zusammenfassen der Com-Zugriffe ist auch deshalb sinnvoll, weil Com-Objekte ganz speziell aufgeräumt werden müssen.

Es ist so, dass ich damit ein automatisches Login für ein Browser-Managerspiel machen möchte. Man gibt Nutzername und Passwort ein, klickt auf "Login" - dann öffnet sich der IE mit der Adresse des Spiels, wo das Anmeldeformular dann gleich ausgefüllt wird.

Das WebBrowser-Control wäre viel einfacher, hilft mir aber deshalb nicht weiter, weil dort scheinbar die IE6-Engine verwendet wird. Bei dem Managerspiel gibt es aber z.B. eine Art Liveticker, der mit dieser Engine nicht korrekt dargestellt wird.

Bisher hatte ich das folgendermaßen gelöst:



Das lief bei mir einwandfrei, bei meinem Kumpel aber nicht. Der erhält die Meldung

Unhandled exception has occured in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately.

Falscher Variablentyp.

Daraufhin bekam ich wie erwähnt den Tipp, mit Option Strict On zu programmieren.

erstmal würdich empfehlen, deine Buttons vernünftig zu benennen.
Dann versuchma, ob du an ein IE_DocumentComplete - event rankommst, anstatt mit Thread.Sleep auf die Vollendung der Navigation zu warten.
Vlt ist das schon die Lösung, nämlich weil dein Kumpel ein langsameres Internet hat

Wäre sehr seltsam, denn die Fehlermeldung kommt bei ihm sofort beim Drücken des Buttons. Da wird nicht mal versucht etwas zu laden.

@ Dude

Es wäre vielleicht mal sinnvoll rauszufinden was schief läuft bei Deinem Freund.

Bevor man hier rumräselt woran es liegen könnte, erstell doch mal eine Version Deines Programmes wo Du die einzelnen Schritter bei dieser Routine in einer Art WhiteBox-Testing prüfst und dokumentierst.

Das geht als simples Modell relativ einfach: Erstell Dir eine Public-Routine die einen übergebenen String als Zeile in ein Text-Dokument abspeichert im Modus Append (also wenn Dokument vorhanden dann wird der Text an den bestehenden Text angefügt).

Und danach baust Du einfach nach jedem Schritt in der zu prüfenden Prozedur eine Message die Du dann durch die oben beschriebene Routine in die Text-Datei schreiben lässt.

Z.b. nach der Anweisung CreateObject einfache einen Eintrag ala "Objekt wurde erstellt, Objekt ist nicht Nothing: " & (Not IE Is Nothing)

Dann soll Dein Freund das Programm mal starten und Dir am Ende die Text-datei per Email zu schicken. Dann weisst Du genau welche Stelle nicht funktioniert. *g*

Gruß

Rainer

Werd ich machen und mich dann wieder melden (hoffentlich schon mit einer Lösung im Gepäck ^^). Vielen Dank!