Diskussionsforum

Hallo,
d.h. ich erstelle ein sogenantes SetupModul, welches die Tabellen erstellt und ein sog. HelperModul erstellt mit dem Enum.
Danach löscht sich das SetupModul per Execute-Befehl von selbst.

Denke so ists Korrekt?
Mach mich mal ans Werk.

Andreas

Die Tabelle beim erstmaligen Import per Setup-Modul erstellen finde ich gut, da man dann sofort eine lauffähige Test-Variante hat. Wer will kann dann immer noch die Tabellen ins Backend verlagern.
Das "HelperModul" (ich nehme an das Modul mit den Enum u ä.) könntest du auch direkt in der CodeLib ablegen und mit "use"-Tag automatisch importieren lassen.

[OT]
Bei diesem Fall fällt mir zum Import-Wizard etwas ein: Das erwähnte "HelperModul" ist ja im Prinzip ein Code-Modul, das nur einmal importiert, dann aber vom Anwendungsentwickler geändert wird und danach nie mehr durch eine AcLib-Update geändert werden darf.
Sollten wir für den Codelib-Bock einen Tag einführen, der so ein Modul kennzeichnet und z. B. die eigenen Änderungen im Modul stehen lässt, aber Neuerungen trotzdem importiert?
(z. B. Code zw. 2 Text-Markern unverändert lassen bzw. im neu importieren Codemodul den bestehenden Code-Block einfügen.)

LG
Josef

Hallo,
das wäre nicht notwendig wenn das "HelperModul" durch das Setupmodul erstellt wird. Dann gäbe es nix zum updaten bzw. dem "Helpermodul" weil es nicht Bestandteil der AccLib ist.

Übrigend was die Options-Tabelle im Backend angeht, es gibt genausoviele Anwendungsfälle wo es sinnvoller ist diese beim Frontend zu belassen. Z.B. verschiedene User verschiedene Verzeichnisstruktur im Netzwerk. Hab ich bei einem Kunden selbst gesehen. Außerdem könnten man so auch Anwenderspezifische Optionen wie Farben, Schriftart, -Größe etc. abspeichern.

Gruß Andreas

BTW: weist du wie man ein erstelltes Modul auch speichern kann ohne dass dann irgendwann die Frage nach dem Speichern kommt?
habs gefunden, trivialer gehts kaum: DoCmd.Save acModule, strModulename

Wo die Tabelle liegt, muss sowieso der Anwendungsentwickler entscheiden. Nur der kennt den Bedarf in der Anwendung. Ich wollte damit nur erwähnen, dass es kein Problem sein sollte, diese Tabelle im BE bei Bedarf selbst zu erstellen.

Außerdem könnten man so auch Anwenderspezifische Optionen wie Farben, Schriftart, -Größe etc. abspeichern.

Man kann auch 2 Instanzen der Klasse nutzen und eine lokale Tabelle und eine Backend-Tabelle einsetzen.


Falls du einmal Code für das Programmieren von CodeModulen suchst, findest du eventuell auch Beispiele im Code des Import-Wizards.
Unter http://source.access-codelib.net/listin ... ns_shared_ sind ein paar Codemodule enthalten, die Code für den Umgang mit Codemodulen enthalten.

LG
Josef

Ich hab mal ein Update gemacht, noch ohne Beispiel-Optionen und Beispiel-Formular.
Ja die Funktionsweise der Module hab ich mir angesehen. Verstehe dabei allerdings nicht das gegenseitige <use> der Klasse und der defGlobal...

Gruß Andreas

<use> wird immer dann eingesetzt, wenn ein Codemodul ein anderes Codemodul benötigt, damit es läuft.
Der Import-Wizard liest sich diesen Codelib-Block durch und importiert die benötigten Codemodule. Man muss sich somit beim Import keine Gedanken machen, was man sonst noch benötigt.

"defGlobal" bitte in diesem Zusammenhang unbeachtet lassen, das ist die die ApplicationHandler-Codemodule (Versuch eines Anwendungs-"Frameworks") vorgesehen.

LG
Josef

Hallo,
aktuelle Dateien sind jetzt online.
wenn ich die OptionManagerSetup.bas importiere bekomme ich Fehler 2425, der von Ihnen eingegebene Ausdruck enthält den Namen einer Funktion die von MS Access nicht gefunden werden kann.

Kannst du mal nachsehen? Liegt es vieleicht daran dass man weil es ein AddIn ist statt CurrentDB CodeDB verwenden muss? Oder was?

Gruß Andreas

Da waren ein paar Fehler die ich korrigierte.
Eventuell den Code des Setup-Codemoduls ohne VBIDE-Referenz auskommen lassen, dann müsste man diesen Verweis nicht setzen.

Anm.: ltOptions halte ich für keinen besonders aussagekräftigen Namen. Was bedeutet "lt"?

LG
Josef

Danke.
lt...
keine Ahnung
hat sich irgendwann mal eingeschlichen vor Jahren.
Bezeichne meine Enums meist so.

Andreas

Bez. des Codes,
ja teile braucht man sicherlich noch.
Hab den Code nochmal angepasst nach dem Update im Repository.
bekomme aber immer noch die gleiche Fehlermeldung wenn ich die Setup-Datei in eine leere DB importiere.
Hab mal die mda debuggt, folgender Ausdruck wird false:
StringTools.Contains(m_cli.ExecuteList(i), REPOSTITORY_ROOT_CODE_PrivateRoot)

Modul AcclibFilemanager Prozedur importFilesFromImportCollection
Parameter sind korrekt soweit ich das sehe, gleich beim ersten Execute der Tabellenerstellung geht er in den Fehler.

Andreas