.NET-Klassenbibliotheken für Access/VBA

[Josef Pötzl]

Zu NCrunch: Damit kann ich mich auch mit NUnit anfreunden.

[FireWalkerHH]

Danke für den Hinweis auf NCrunch. Das sieht nett aus. Kann man in Express-Versionen Erweiterungen/Add-Ins installieren?

Ich glaube ja, habe aber keinen Rechner mehr zu Verfügung auf dem ich das Testen kann.

[Josef Pötzl]

Eine kurze Zusammenfassung, was nicht funktioniert:

• ParamArray von .NET kann man nicht nach COM bringen.
• Arrays als Parameter hat auch noch nicht geklappt. Das lässt sich aber möglicherweise per Mashal & Co. noch regeln. Aktuell übergeben ich Arrays einfach als Variant.

Folgendes hat schon geklappt:

• Enumerator für for each
• Default Property (VB_UserMemId = 0 wird zu [DispId(0)])

mfg
Josef

[Josef Pötzl]

Gerade getestet:
Wenn man Visual Studio Expresss verwendet kann man keinen Add-Ins für das Visual Studio nutzen. => Dann muss man die NUnit-Tests über die NUnit-Oberfläche starten. Den Aufruf kann man sich aber zumindest unter "External Tools" einen Aufruf einbauen.

[Josef Pötzl]

FYI:
Array kann man übergeben, man muss allerdings den Parameter mit ref deklarieren, da VBA Array nicht per ByVal übergeben kann.

[Christoph Jüngling]

Ich habe die beiden Repos mal probeweise mit Hg geclont, was einwandfrei ging. Ich würde mich vorerst quasi als lernender Beobachter beteiligen, da ich mit den neueren Visual Studios und insbesondere C# noch fast nichts gemacht habe aber so kann ich hoffentlich auch endlich mal reinrutschen.

Ein Versuch wäre es wert, mal zu testen, ob ich mit Hg auch schreiben kann.

[Josef Pötzl]

@Christoph:
Wie wäre es, wenn du zum Eingewöhnen ein paar Tests gestaltest?
Ich glaube, das würde sich ganz gut eignen, um sich ein wenig an C# zu gewöhnen.

[Sten Schmidt]

Hallo Josef,

das ist ja wirklich mal ne coole Sache! Ich hätte im leben nicht gedacht, dass das Verfahren auch mit MDE's funktioniert, die man dann mal schnell in ein anderes Verzeichnis verschiebt (wg. der kompilierten Pfaden bei den Verweisen) ... aber selbst dieser Fall wird ja abgefangen.

Dann könnte ich zukünftig ja meine MDE's u.U. auch unter Windows 64bit kompilieren und auf Windows 32bit deployen, sofern ich die Pfade kenne... werd ich mal ausprobieren.

Zu AccessCodeLib.NET:

Grundsätzlich ne schöne Idee, es lohnt sich jedoch nicht für jedes Thema, z.B. Erstellen und Bearbeiten von Access-Menü-Leisten ginge zwar über .NET, ist aber von VBA aus "schneller" gemacht.

Was ich mir aber vorstellen könnte wäre XML-Generierung bzw. XML-Parsing, was in der VBA-Welt nur sehr unschön funktioniert. Der Klassiker für den Einsatz von Access in Verbindung mit .NET ist sicherlich der ganze Themenbereich um die Nutzung von WebServices.

Und zum Schluss noch ne "Spinnerei": Wirklich cool wären in Access-Forms eingebettet .NET-Winforms, damit hätte man eine Möglichkeit Schritt-für-Schritt seine Access-Lösung auf .NET umzubauen...

[Josef Pötzl]

Hallo!

... aber selbst dieser Fall wird ja abgefangen.

.. man darf aber nicht vergessen, vor der Nutzung der dll, auf das aktuelle Verzeichnis zu achten.

Dann könnte ich zukünftig ja meine MDE's u.U. auch unter Windows 64bit kompilieren und auf Windows 32bit deployen, sofern ich die Pfade kenne... werd ich mal ausprobieren.

Wie meinst du das?
Das bringt mich noch auf weiteren einen Vorteil einer .Net-COM gegenüber einer VB6-COM: sie sollte auch in 64-Bit-Office verwendet werden können.

Grundsätzlich ne schöne Idee, es lohnt sich jedoch nicht für jedes Thema, z.B. Erstellen und Bearbeiten von Access-Menü-Leisten ginge zwar über .NET, ist aber von VBA aus "schneller" gemacht.

Bei Ribbons wird das aber schon wieder lustiger. Ich baute mir z. B. in VBA eine Ribbon-Hülle ein, um auf Ereignisse zu reagieren. Wenn ich so einen Code nicht immer in meine Anwendung sondern nur per dll nutzen kann, finde ich das schon praktisch.

Wirklich cool wären in Access-Forms eingebettet .NET-Winforms, damit hätte man eine Möglichkeit Schritt-für-Schritt seine Access-Lösung auf .NET umzubauen...

Oder anders ausgedrückt: man könnte Access für das Nutzen, wofür es super ist: RAD. Sobald dann ein Ablauf ausgereift ist, portiert man ihn nach .NET um ihn mehrfach verwenden zu können.
Oder: Access-Client für die kundenindiviuellen Anpassung + NET-COM für den wiederverwendbaren Code.

[Sten Schmidt]

Hi,

Wie meinst du das?

Ausgangslage: Entwicklungsrechner: Windows 64bit + Office 2007 32bit (Office 2007 64bit wird ja nicht für Produktionsumgebungen empfohlen).

Der VBE-Dialog für Verweise (siehe Anlage) zeigt, dass die entsprechenden 32bit-Varianten der DLLs / Bibliotheken genutzt werden.

Problem: Wird nun eine MDE kompiliert, so werden auch diese Pfade fest übernommen. Wird nun die MDE auf Windows 32 bit deployed, dann exisitert der Pfad "C:\Programm Files (x86)\..." nicht, der Verweis wird nicht gefunden.

Im umgekehrten Fall hingegen wird die MDB auf Windows 32bit kopieren und dort kompilieren. Die Pfade stehen dort wie gewohlt auf "C:\Programm Files\...". Wird die dort erzeugte MDE dann auf Windows 64bit deployed, wird (weil Office als 32 bit Version installiert ist) der in der MDE hinterlegte Pfad "C:\Programm Files\..." automatisch auf "C:\Programm Files (x86)\..." umgebogen (das macht das WOW64-Subsystem von Windows automatisch ohne dass Office davon etwas mitbekommt). Die Anwendung funktioniert erwartungsgemäß.