Office: (Office 2010) Debug.Print

Hallo Josef,
Zwischendurch erst nochmal ein Danke für deine Hilfestellung.

Klar, hätte ich auch selber drauf kommen können *frown.gif*

Der Kommentar sollte sich eigentlich nur auf den Querynamen beziehen. Nehm' ich raus.

Sehe ich genauso.

Benamsungen werde ich deinen Vorschlägen entsprechend anpassen.
Die Konstante hatte ich vergessen mit zu löschen als ich den Code angepasst habe.

Die finde ich sicher auch im FilterWizard, - oder?

Bezügl. Versionsnummer, - das mache ich jetzt während der Entwicklung nur so, weil
das ständige Kopieren/Umbennen nervt. Geht schneller eben die Tabelle und dein
Script anzupassen.
Wenn's dann endgültig fertig ist, schreibe ich die Versionsnr. in die DB-Eigenschaften.
Da sieht sie dann in der AddIn-Liste.

gruss ekkehard

 

Hallo!

[UncPath]

Das sollte so sein. *Smilie


[OT]

Wozu benötigst du beim Entwickeln die Versionsnummer im Dateinamen?

Ich mache das so:
Aktuelle Version = Dateiname ohne Versionskennung.
Wenn ich eine Version verteile, wird diese Datei mit Versionskennung im Archiv-Ordner abgelegt.

mfg
Josef

 

Moin,
UNCPath habe ich gefunden *wink.gif* und eingebaut.

Tja, manchmal kommen einem die einfachsten Sachen nicht in Sinn *frown.gif*

gruss ekkehard

 

Hallo Josef,
Zurück zur Fehlerbehandlung.

Wie ermittele ich denn unerwartete/-bekannte Fehler, die jetzt während Entwicklung/Testen
nicht aufgetreten sind?

Müsste man ja wissen, um eine sinnvolle Fehlermeldung anzuzeigen.
Eine Meldung a la "Modul konnte nicht angelegt/gelöscht werden!" (so habe ich jetzt erstmal) ist
für den Anwender nicht wirklich hilfreich; - selbst wenn man die originale Err.Description mit
anzeigen würde.
Andererseits denke ich aber auch, dass da keine Fehler mehr auftreten dürften, - die Hoffnung
stirbt zuletzt. *wink.gif*

Noch zum Schluss(?) - bekommt man die Sicherheitsmeldung irgendwie weg, oder muss der
Anwender sich darauf verlassen, dass da nichts Schlimmes passieren kann?

Ach ja, - habe ich bei den Erläuterungen im Startform was Wichtiges vergessen?

gruss ekkehard

 

Hallo!

Wie soll die Fehlermeldung aussehen?
Willst du die Aufrufreihenfolge sehen?

Beispiel:
Code:

Wenn du z. B. die Fehlermeldung etwas aufpolieren willst, könntest du folgendes machen:
Code:

In der obersten Aufrufprozedur dann den Fehler abfangen und dem User zeigen.

mfg
Josef

 

Moin Josef,
Sorry für späte Rückmeldung, habe aber halbe letzte Woche mit einer Magen-/
Darmgeschichte rumlaboriert. - Alles gut.

Also mich heute morgen mit der Fehlerbehandlung beschäftigt. Aber irgendwie
hab' da schon wieder ein Verständnisproblem *mad.gif*

Ich habe es mit der Löschfunktion probiert, da es dort am einfachsten ist einen
Fehler zu provozieren (Modul löschen, Löschbutton zulassen).
Wenn ich so mache, wie du es geschrieben hast
Code:

wird zwar die Fehlermeldung angezeigt (nur die Source kann ich nicht entdecken),
dann der Code an dieser Stelle aber angehalten, wenn ich "Beenden" klicke. Klicke
ich "Debuggen" wird der Aufruf vom Button gelb hinterlegt.
Kommentiere ich die o.a. Zeile aus, läuft die Aufrufprozedur wie gewünscht durch
und zeigt die Meldung selber an. So werde ich wohl auch lassen, denn es gab noch
eine weiteres Problem mit dem Err.Raise.
In der kompilierten DB kommt der Fehler "Sie haben als Einstellung der Ereignis-
eigenschaft Beim Klicken ..." (reicht, oder?).
Da greift wohl die Fehlerbehandlung gar nicht ?
Einen potentiellen Fehler habe ich aber gerade noch gefunden. Und zwar kommt ein
Fehler (91) wenn keine DB geöffnet ist. Den habe ich jetzt implizit abgefangen, und so
soll es mir auch jetzt reichen.
Code:

bzw.
Code:

im Aufruf
Code:

Noch was, darf ich dein Installationsscript (Quelle ist eingetragen) auch mit weitergeben?
Dann stelle ich die DB als nächstes hier rein.

gruss ekkehard

 

Hallo!

Wenn du eine Beispiel-Datei bereitstellst, kann ich mir das mit der Fehlerbehandlung besser anschauen.

Natürlich.

mfg
Josef

 

Hallo,
So, da ist es nun, "mein" erstes AddIn *boah

Das Archiv enthält die "SqlDebugPrint.mda" (ist eine .mdb), Josefs Installationsscript
und eine ReadMe mit allen Erklärungen wie auf dem Startformular, ergänzt um die
Installationsanweisungen.

Für Anregungen und Kritik bleiben meine Ohren weiterhin geöffnet.

gruss ekkehard


P.S.: Darf ich das jetzt auch woanders veröffentlichen?

 

Hallo Josef,
Hat sich überschnitten.
Beispiel am letzten Post anbei, und danke.
gruss ekkehard

 

Hallo!

Ich entführe diesen Thread etwas in Richtung Codegestaltung.
Anm.: Alle Kommentare zum Code sind meine persönliche Sichtweise.

Ausgangscode:
Klasse: TransferCodeModule, Methode: CreateModuleInApp

Code:

Vorab: was fällt dir bei den Kommentarzeilen nach der Funktionsdeklaration auf?
.. der Name im Kommentar stimmt nicht mit dem Prozedurnamen überein. Nutzt du eine Anwendung, die aus diesen Zeilen eine Dokumentation erstellen kann? Oder wozu schreibt man unter den Prozedurnamen noch einmal den Namen der Prozedur? *wink.gif*
Du stellst auch jedes Mal das Datum auf den aktuellen Stand, wenn du eine Änderung im Code machst? Mir wäre das zu viel Aufwand.

Anwendung der Methode:
Code:

Deine Funktion CreateModuleInApp gibt True oder False zurück. Das würde ich aus dem Namen nicht ableiten. Wenn ich eine Methode CreateModuleInApp aufrufe, erwarte ich einfach, dass sie ein Modul erzeugt. Sollte dabei etwas schiefgehen, würde ich eher einen Fehler erwarten.

Mit True/False-Rückgabe, welche die erfolgreiche oder nicht erfolgreiche Durchführung zeigt, würde ich eher einen Namen wie TryCreateModuleInApp verwenden.

Beispiel:
Code:

Verwendung:
Code:

Eine andere Variante: den Fehler aus der Klasse weitergeben.
Code:

Verwendung:
Code:

Vorteil der letzten Variante: Der Code-Block für den Fehlerfall stört nicht im restlichen Code, der den Ablauf beschreibt.


mfg
Josef

 

Hallo Josef,

Irgendwann fallen einem solche Fehler einfach nicht mehr auf *frown.gif*

Tja, aus den MZTools übernommen und nicht hinterfragt *frown.gif*
Das Datum ändere ich nicht jedes mal. In anderen Projekten ist es schon vorgekommen,
dass ich eine Version dokumentiert habe (Änderung der Parameter o.ä.). Aber hier hielt
ich weitere Kommentare für nicht nötig.

Bezügl. Rückgabewert und Funktionsname, - solche Tricks und Feinheiten werden sich
wohl bei mir nicht mehr einschleifen, den Versuch gebe ich aber nicht auf. Auslöser war
deine Anforderung dem Verwender einen Hinweis zu geben, die ich "auf die Schnelle" so
umgesetzt hatte.
Jetzt versuche ich mal deinen letzte Variante einzubauen.

gruss ekkehard

 

Hallo,
Hier jetzt die Version mit der eleganten Fehlerbehandlung von Josef. Danke noch einmal für die vielen Denkanstösse.
gruss ekkehard

 

Hallo, (schon wieder *wink.gif* )
Nach dem letzten Post saß ich noch davor und da ist mir noch ein anderes Manko
vieler Anfängerposts eingefallen, - HTML-Tags.
Also habe ich, wieder "so auf die Schnelle" *wink.gif*, noch eine Funktionlität eingebaut,
die dies behebt.
Checkbox gesteuert kann man die Texte jetzt inkl. der Tags (CODE bzw. QUOTE)
in die Zwischenablage kopieren.
Einen Hinweis bezügl. Formatierung, ist manuell im Formular ja möglich, habe ich
auch noch platziert.
gruss ekkehard

 

Hallo!

Vielleicht ergibt sich einmal die Möglichkeit den QueryHelper von Eberhard in deinem Add-In zu nutzen.

LG
Josef

 

Hallo,
Na ja, aus der Diskussion hatte ich mich ja schon abgemeldet, - in der Richtung
lauert für mich der Wahnsinn. *wink.gif*
Aber das AddIn steht ja offen zur Verfügung. Es kann also jeder damit machen,
was er will, - zweckgemäss verwenden (Anfänger) oder für ambitionierte Entwickler
als Basis für eigene Ideen.
Ich setzte den Thread dann jetzt auch erstmal als erledigt. Falls es doch noch
weitergehen sollte, können wir ihn ja wieder öffnen.
gruss ekkehard