Office: (Office 2010) Debug.Print

Hallo Josef,
So, deinen Code habe ich jetzt in meine letzte Version eingefügt, und dabei bis auf
dieses alles verstanden.
Code:

Die erste Zeile verstehe ich so, dass das schon mal sein kann, da globale Variable.
Wozu dient "m_SelfRef"? Wird doch nirgends mehr verwendet.
Und wozu dient der Timer?

I.Ü. habe ich noch eine Änderung vorgenommen, die ich auch schon in meiner letzen
Version vorgenommen hatte. Und zwar habe ich die Auswahl des WindowMode
gecancelt, da acDialog den Zugriff auf die SQL-Ansicht der temporären Abfrage
blockiert. Und ein normales Debug.Print hält den Code ja auch nicht an.

gruss ekkehard

 

Hallo!

Damit hält das Formular seine eigene Formularinstanz am Leben.
(Das ist für den Fall, wenn das Formular mit New erstellt wird, damit mehrere SQL-Text hintereinander geöffnet werden können.)

Der Timer ist für die verzögerte Anzeigedarstellung.

Wozu canceln? Es hätte doch gereicht, wenn du den Standardwert des optionalen Parameters von acDialog auf acNormal geändert hättest. Dann hätte man immer noch die Möglichkeit den Code an dieser Stelle mit dem Aufruf zu unterbrechen.



mfg
Josef

 

Hallo Josef,
Ich fang mal hinten an.

Hab's ja erstmal nur auskommentiert *wink.gif*
Dann mache ich es vorgeschlagen, würde aber die beiden anderen Modi noch
"ausschliessen" wollen.
Code:

Das geht aber auch nur mit acWindowNormal.

Dass das eine Referenz auf sich selber ist, habe ich wohl verstanden, aber wie,
wo oder wann kommt die zum Tragen?
Sorry, aber Formularinstanzen zu verwalten ist für mich auch schon wieder was
Neues. Habe ich bis jetzt nicht benötigt.

Und zuletzt noch,

Sorry, da war die Frage falsch gestellt. Meinte warum/ob es nötig ist.

gruss ekkehard

 

Hallo!

Diese Referenz hält das Formular offen.

Als Erklärung
Sobald auf ein COM-Objekt keine Referenz mehr zeigt, wird die Instanz geschlossen.
Code:

Nach End sub wäre das Formular wieder weg, falls nur mit frm eine Refernz gespeichert wurde.
Wenn ich aber im Formular selbst beim Laden eine Referenz einstelle, bleibt das Formular offen, das der COM-Referenzzähler nicht auf 0 geht.

mfg
Josef

 

Hallo Josef,
Danke für deine Erklärungen, die ich auch verstanden habe *Smilie
Wie's im Hintergrund funktioniert ist mir zwar nicht klar, aber man muss wohl auch
nicht alles verstehen, wenn's dann funzt. *wink.gif*
Ich weiss jetzt auf jeden Fall, dass man das bei Form-Instanzen beachten muss.

Der nächste Schritt, das nötige Modul in die Anwendung zu kopieren beschäftigt
mich nun schon 2 Tage. Dazu habe ich mich mir deinen "FilterWizard" angeschaut.
Das ist aber als Beispiel wohl etwas zu mächtig, - sorry, aber da muss ich aufgeben,
in der Hoffnung, dass auch "leichter" geht.
Denn, zumindest konnte ich daraus das prinzipielle Vorgehen für unser AddIn ableiten.
- Modul aus dem AddIn mit SaveAsText exportieren
- Modul in die Anwendung mit LoadFromText importieren (vorher prüfen, ob schon
vorhanden)
Die dazu nötigen Prozeduren habe ich in deiner VBETools-Klasse gefunden.

Leider hapert es da schon wieder bei der Umsetzung, will sagen, mir fehlt technisches
Wissen.
Mein Problem, ich muss dabei auf zwei VBProjekte zugreifen, kann aber an dem
eingebundenen AddIn in der Testanwendung nichts "entwickeln"/testen, obwohl nicht
kompiliert und Standalone gibt es eben nur ein Projekt. *frown.gif*

Wie macht man das?

gruss ekkehard

 

Hallo!

Das würde ich in deinem Add-In nicht über einen Import eines kompletten Codemoduls machen.
Ich würde ein neues Modul per VBA erstellen und die paar Zeilen Code einfügen.

Als Hilfsklassen kannst du z. B. CodeModuleWriter.cls verwenden oder Code-Auszüge daraus verwenden.

Prinzip:
1. vbComponent im Anwendungs-VBProject erstellen
2. In das darin enthaltene Codemodul die Prozeduren einfügen.

mfg
Josef

 

Danke.
Setze ich mich heute Nachmittag dran.

 

Hallo Josef,
Geschafft! *Smilie Jedenfalls fast.
Der Code zur Übertragung des Moduls funzt.

Leider habe ich noch nicht herausbekommen, wie ich es in eine Anwendung einbinde. *frown.gif*
Das AddIn ist in das AddIn-Verzeichnis kopiert, und wird auch angezeigt (siehe Anlage).
Wobei mich da schon der angezeigte Name (DebugPrint.mdb) wundert; -
die Datei heisst: SQLDebugPrint.mda (noch unkompiliert)
das Projekt heisst genauso
eine Beschreibung (steht in den Projekt-Eigenschaften und in der USysRegInfo) wird nicht angezeigt.

Wie/wo wird denn die Startfunction aufgerufen?
Über den installieren-Button geht es bei mir nicht (siehe auch Anlage).
Ich vermute das "Geheimnis" verbirgt sich in deiner Klasse "ApplicationHandler", da bin ich
aber noch nicht durchgestiegen.

gruss ekkehard

 

Hallo!

Du meinst, es wird in der Add-In-Liste des Access-Add-In-Managers angezeigt?
Der Namen und die Beschreibung kommt aus den Datenbankeigenschaften. (Steht das nicht im Skript von Thomas?)

Die Startfunktion, die aufgerufen werden soll, wenn man das Add-In über das Add-In-Menü startet, musst du in der UsysRegInfo-Tabelle einstellen.

Prinzip:
Code:

(Anm.: Backslash bitte in den Text der 1. Spalte reindenken, da der vom Forum abgeschnitten wird und ich keine Lust habe, diesen Forum-Fehler durch Verdoppeln nach jeder Beitragsänderung zu umgehen.)

LG
Josef

 

Hallo Josef,
Grrr, Anlage vergessen.

Ja.

Doch, habe ich jetzt beim nochmal Nachlesen gefunden.

Meine USysRegInfo sieht so aus
Code:

Ich sehe da keinen Unterschied, bis auf die beiden Type 4 Zeilen. Die brauche ich aber
gar nicht, - oder?

gruss ekkehard

 

Hallo!

Code:

vs.
Code:

Man glaubt es nicht, aber das klein geschriebene i verhindert die Installation.

Tipp:
Gib dem User Rückmeldung, dass das Codemodul eingefügt wurde. Als Add-In-Nutzer erwarte ich, dass sich eine Maske öffnet, wenn ich ein Access-Add-In starte. Sonst glaube ich, es ist nichts passiert.
Ich würde im Add-In ein Formular erstellen, dass über die Add-In-Startfunktion geöffnet wird und von dem aus dann per Click der fehlende Code eingefügt wird. Weiters könntest du in diese Formular eine Kurzbeschreibung oder einen Beispielcode einfügen, damit man sieht, wie SqlDebugPrint verwendet werden kann.


Fehler im Code:
Code:

löst bei mir einen Fehler aus, wenn das Modul nicht enthalten ist.
Besser:
Code:

Den Einzufügenden Code würde ich wie bereits erwähnt nicht über einem Dateiexport erzeugen, da du dadurch verhinderst, dass das Add-In als mde genutzt werden kann. (Ist praktisch, da dann dieses VbProjekt nicht irrtümlich geändert werden kann.)

Du paar Zeilen könntest du auch direkt als Text in den Code schreiben.
Oder du schreibst die Code-Zeilen in eine Hilfstabelle und liest den Text von dort aus.

mfg
Josef

 

Hallo Josef,
So langsam wird's *Smilie

Kleine Ursache - grosse Wirkung *wink.gif*

Der Test ist mir echt durchgerutscht *mad.gif*

Jau, .AddFromString habe ich dann auch noch gefunden *wink.gif*
Den String baue ich jetzt mal zusammen, und dann werde ich auch noch deine weiteren Tipps einbauen.
gruss ekkehard

 

Hallo,
Heureka - es funzt *Smilie , - jedenfalls bei mir.

Eine "Kleinigkeit" muss ich allerdings noch verbessern. Und zwar habe ich zunächst aus
dem Modul "mdlTransferModuleCode" ein Klassenmodul gemacht und die beiden Subs
"CreateModuleInApp" und "DeleteModuleFromApp" in Functions umgewandelt, die einen
Boolean-Wert zurückgeben wegen der Erfolgsmeldung(en) im Startformular.
Und da muss ich noch herausbekommen, wie ich einen evtl. Fehler an die Prozeduren
im Form zurückgebe. Ich hoffe ich mir das auch noch aus deinem FilterWizard
"abschreiben" kann.

gruss ekkehard

 

Hallo!

Dein Add-In schau ich mir später an.

Vorab:

Die einfachst Variante wäre, auf nicht behandelbare Fehler in der Klasse gar nicht reagieren. *wink.gif*

Ansonsten kannst du mit err.raise einen Fehler auslösen.

mfg
Josef

 

Hallo!

Ein paar Fragen zum code:

In TransferCodeModule.CreateModuleInApp steht:
Code:

Warum löscht du das Codemodul, wenn es bereits vorhanden ist?
Du könntest es auch verwenden und bei Bedarf den Inhalt löschen und neu einfügen.

Angepasster Code:
Code:

Code:

Das kann man aber nur anpassen, wenn man das Add-In verändert. *wink.gif*
Damit man das anpassen kann, könntest du im Add-In-Start-Formular die Werte zum Ändern anbieten und die Konstanten z. B. durch Property-Prozeduren ersetzen. Das ist aber meiner Meinung nach nicht notwendig.

Ich würde als Modulnamen "mdlSqlDebugPrint" (oder ohne Präfix "SqlDebugPrintFactory") und als Name für die Temp-Query "qTempSqlDebugPrint" verwenden. Dann wird es kaum ein Problem mit einer Namensgleichheit bestehender Elemente in der Anwendung geben.

Die Konstante ADDINPROJECTNAME kannst du übrigens löschen, die wird nicht verwendet.

In TransferCodeModule.CurrentVbProject:
Code:

Wenn die Anwendung auf einer Netzwerkfreigabe liegt, passt der Vergleich nicht, da Proj.Filename den UNC-Pfad liefert.

besser:
Code:

Die UncPath-Funktion nutzt eine API-Funktion um den UNC-Pfad zu ermitteln.


/edit:
Eines ist mir noch aufgefallen: ich würde die Versionsnummer nicht im Dateinamen lassen. Das ist beim Update nur lästig, weil dann beide Versionen als Add-In angeboten werden, wenn man die alte Datei nicht aus dem Add-In-Verzeichnis löscht.


mfg
Josef