VB-Exe läuft nicht - Debuggen der Exe möglich?

Hallo,

etwas weiter unten (http://www.wer-weiss-was.de/cgi-bin/forum/showarticl…) habe ich das Problem geschrieben, daß eine VB-Exe nur auf dem Entwicklungsrechner läöuft, nicht aber auf anderen Rechnern. Auch ein Setup mittels Weitergabeassistent oder Nachinstallieren der VB-Runtime halfen nichts.

Irgendein Objekt unterstützt eine Eigenschaft oder Methode nicht, noch bevor die erste Code-Zeile ausgeführt wird (die zu Debugging-Zwecken eine Msg-Anweisung ist).

Kriegt man irgendwie raus, wo es hängt? VB selbst kann ich nicht nehmen, weil´s da ja läuft. Und ein Assembler-Debugger nützt mir auch nicht so viel, fürchte ich.

Danke, Kristian

Hallo
Ich habe auch festgestellt , das man bei VB gelegentlich etwas herumprobieren muß .
In Deinem Fall gäbe es die Möglichtkeit , das Du zum Beispiel Systemabhängige API-Calls machst . Hierbei ist auch nicht unbedingt für den Laien vorhersehbar , welcher Codeteil zuerst gestartet wird , man müßte ja auch Deinen Code durchlesen , ächz .
Mein Tip ist der folgende :
Mach so ein Setup für Disketten , kopiere das in einen Ordner ( also quasi auf eine Diskette ) . Da gibt es ja den Setupassistenten für .
Hierbei werden alle notwendigen Dateien mit eingeschlossen . Falls es tatsächlich passieren sollte , das eine Datei schon vorhanden ist , ist es erstmal egal , und zweitens fragt das Setupprogramm nach , ob diese Datei ersetzt werden soll .
Ein Problem könnte eine fehlende Lizenz für ein Control sein .
Hast Du von irgendwo ein Control geladen , wofür Du aber vom Programmiersystem oder vom Hersteller des Controls keine Lizens hast , dann klappt es nicht .
Dann kann es natürlich sein , das Du das alles schon weißt , und irgendwo ist noch ein Fehler im Programm …
Da kann ich nur den Tipp geben , ( das mit der MSGBOX war schon ganz gut ) , das Programm zu zerteilen , um dann teilweise auszutesten .
Hierzu machst Du ein neues Project , wo Du teilweise die Programmbestandteile einbaust . Die ganzen Aufrufe in die jeweils anderen Programmteile müssen dann natürlich weg , und als neue Files abspeichern .
Mein Tip :
Besonders bei ein wenig Aufregung ist eine Sicherheitskopie mehr ein gute Versicherung .
MfG

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Habe den Fehler eingegrenzt :smile:

In Deinem Fall gäbe es die Möglichtkeit , das Du zum Beispiel
Systemabhängige API-Calls machst . Hierbei ist auch nicht
unbedingt für den Laien vorhersehbar , welcher Codeteil zuerst
gestartet wird

Naja, ich gehe einfach mal davon aus, daß ich in der ersten Zeile lande, wenn ich das Programm mit F8 starte.

Mein Tip ist der folgende: Mach so ein Setup für Disketten …

Auch ´ne Möglichkeit, wenn es ganz hart kommt. Werde ich mir mal im Hinterkopf behalten.

Ein Problem könnte eine fehlende Lizenz für ein Control sein .

Ich benutze eigentlich nur die Standard-Komponenten, und wenn da was zu lizensieren wäre, dürfte es ja auch auf dem Entwicklungssystem nicht laufen, auf dem ich zumindest nichts lizensiert habe - weil nix zu lizensieren ist natürlich :wink:

Dann kann es natürlich sein , das Du das alles schon weißt,

Ich möchte jetzt nicht so direkt „Ja“ sagen … Aber es lesen ja auch viele andere, das sollte man immer berücksichtigen.

Da kann ich nur den Tipp geben , ( das mit der MSGBOX war
schon ganz gut ) , das Programm zu zerteilen , um dann
teilweise auszutesten .

Jupp, die Box war der erste Schritt.

Hierzu machst Du ein neues Project , wo Du teilweise die
Programmbestandteile einbaust . Die ganzen Aufrufe in die
jeweils anderen Programmteile müssen dann natürlich weg , und
als neue Files abspeichern .

Ja, das ist der zweite Schritt. Ich habe - das hätte ich auch schon vorher machen können - nun als Start-Objekt nicht mehr das Haupt-Formular eingestellt, sondern eine Main-Sub. Dort habe ich eine InputBox reingesetzt, und mit 0 bis 4 kann ich jedes einzelne Formular aufrufen. Und - oh Wunder - bis auf das Hauptformular gehen alle! Es kann also auch nicht an den aus VBA importierten Designer-Formularen liegen.
Nun gibt es auf dem Hauptformular eigentlich nur zwei Komponenten, die nicht Standard sind: Ein Dialog aus der ComDlg32.ocx oderso und eine MultiPage-Komponente. Ich nehme mal an, daß es an letzterem liegt. Komisch eigentlich, da es unter VBA problemlos läuft, die DLL bzw. das OCX auch installiert sein müßte.

Mein Tip :
Besonders bei ein wenig Aufregung ist eine Sicherheitskopie
mehr ein gute Versicherung .

Das ist richtig. Und dazu eine Frage:
Es scheint nicht so einfach zu sein, ein Projekt einfach mal in ein anderes Verzeichnis zu duplizieren. Ich kann zwar „Projekt speichern unter“ machen, aber dabei wird lediglich die *.vbp-Datei angelegt. Alle Code-Dateien werden aus dem alten Verzeichnis weiterverfwendet. Fatal, wenn man große Teile rauslöscht und auf „Speichern“ klickt!
Wenn ich nun ganz schlau das ganze Verzeichnis kopiere und dort das Projekt lade, ist es auch nicht anders, weil in der Projektdatei offenbar absolute Pfade stehen, die natürlich wieder zum alten Verzeichnis zeigen.
Es muß doch aber eine Möglicheit geben, ohne das manuelle Löschen und wieder Einbinden jeder einzelnen Code-Datei (Formulare, Module, Klassen), ein Projekt zu kopieren, oder?

Danke und viele Grüße,
Kristian

Es muß doch aber eine Möglicheit geben, ohne das manuelle
Löschen und wieder Einbinden jeder einzelnen Code-Datei
(Formulare, Module, Klassen), ein Projekt zu kopieren, oder?

Ja , da ist schon einiges problematisch , das habe ich auch bemerkt . Ich dachte an eine Diskette , welche die Codebestandteile und eventuell Bilder aufnimmt . Mit Explorer oder Dos-Befehl kopieren usw …
Must Du mal ausprobieren , aber wie Du schon selber bemerkt hast , gaaanz vorsichtig …

MfG

FYI: COMDLG32.OCX vs. COMDLG32.DLL ?
Moin Matthias,

ich habe nochmal eine Exe gebaut, in der das fragliche Formular 4 Mal vorkommt. Den drei Kopien fehlt jeweils eins der drei möglicherweise fehlerträchtigen Komponenten: MultiPage, SpinButton (beide FM20.DLL) sowie CommonDialog (ComDlg32.OCX).
Und erstaunlicherweise ist es tatsächlich der Dialog, der nicht funktioniert, obwohl ich gerade für den die OCX-Daeti nachinstalliert habe.
Ein Blick ins System zeigte mir, daß es auch eine COMDLG32.DLL gibt. Vielleicht wird ja versucht , diese zu verwenden? Aber auf dem Entwicklungsrechner muß die doch auch existieren. Vielleicht war es gar ein Fehler, das OCX zu installieren? Kann man diese Registrierung nicht auch rückgängig machen? MIr schwirrt da irgendwas mit Reg32.exe oderso im Kopf rum.

Kristian

Hallo
Ich habe so keine Ahnung , wofür die gleichnamige OCX da ist .
Kann sein , das das OCX nur ein Interface zur DLL ist , damit es vom Basic verwendet werden kann .
Auf jeden Fall solltest Du das OCX per VB-Menü einfügen .
Sonst wird es eventuell auch nicht auf anderen Systemen mitinstalliert .
MfG
Matthias

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]