Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Interface-Nutzung in Access VBA
zurück: Nicht genügend arbeitsspeicher! weiter: Angepasste Screenshots - ein Mittel zur Verstaendigung Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Tutorial Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
18. März 2010, 01:51
Rufname:

Interface-Nutzung in Access VBA - Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Hallo zusammen,

hier mal wieder ein kleiner Ausflug in die objektorientierte Programmierung in Access.

Mehr als man glaubt, arbeitet man in Access in VBA sehr oft mit Objekten. Jedes geöffnete Formular und jeder geöffnete Report wird von Access als eine Instanz einer Formular- bzw. Reportklasse behandelt.
Man merkt es meistens nicht, denn üblicherweise öffnet man Formulare mit dem Befehl "DoCmd.OpenForm...". Und dieser öffnet ein Formular genau einmal, jeder weitere Versuch bringt das bereits geöffnete Formular einfach nur in den Vordergrund.

(Die folgenden Ausführungen beziehen sich nur auf die etwas einfache Objektorientierung, die VBA unterstützt, in der "richtigen" OOP gibt es weit mehr dazu zu sagen.)

Ein Objekt ist eine Instanz eines Klassenmoduls (kurz Klasse).
Aber was ist das eigentlich? Man kann sich eine Klasse als einen "Bauplan" vorstellen, die selbst nichts ausführen kann. Eine Klasse in Access wird genauso geschrieben wie ein normales Modul. Sie enthält also Variablen, Funktionen, Prozeduren usw. Aber wenn man versucht, etwas davon auszuführen, wie man es von normalen Modulen gewöhnt ist, bekommt man nur Fehlermeldungen.
Denn während alles in einem normalen Modul sofort ausgeführt werden kann, können alle Dinge in einem Klassenmodul erst ausgeführt werden, wenn man aus diesem Bauplan ein Objekt erzeugt hat. Das Objekt ist eine komplette Kopie von allem, was in der Klasse definiert ist. Man könnte es simulieren, indem man ein normales Standardmodul kopiert und als neues Modul wieder einfügt. Jetzt hat man eine Kopie des ersten Moduls mit eigenen Variablen und Prozeduren usw. Aber da beide die gleichen Namen verwenden, müßte man nun alle Namen in einem der beiden Module umbenennen - das Ergebnis wären dann zwei unabhängige Module, die das gleiche ausführen können, nur unter unterschiedlichen Namen.

Fragt sich, warum man das tun sollte. Wenn sie ja eh das gleiche machen, wozu eine Kopie anlegen?
Ein Beispiel wäre, daß das zweite Modul Variablen enthält, die andere Werte haben sollen als das erste Modul. Oder daß man unabhängige Module schreiben möchte, die keine Aufrufe außerhalb des Moduls verwenden, damit man sie einfach in einem neuen Datenbankprojekt wiederverwenden kann.

Ein Objekt kann das Problem ganz einfach beheben: Da hier nur ein Bauplan definiert wird, kann ich mir so viele Objekte aus dem Bauplan erzeugen, wie ich brauche. Jedes verwendet die gleichen Prozedurnamen und Variablennamen, und trotzdem kommen sie sich nicht ins Gehege. Ganz einfach, weil ihre Namen nicht direkt angesprochen werden können, wie es bei Prozeduren in Modulen der Fall ist, sondern man immer den Weg über ihren Objektvariablennamen gehen muß.

Und als VBA-Programmierer hast Du mit hoher Wahrscheinlichkeit bereits reichlich davon Gebrauch gemacht, ohne darüber groß nachzudenken. Eines der meistgebrauchten Objekte in Access ist das Recordset (egal ob ADO oder DAO). Wenn man ein neues Recordset benötigt, muß man erst einmal einer neuen Variablen den Bauplan zuweisen:
Code:
    Dim rs As Recordset
Hier ist die Klasse (der "Bauplan") das Klassenmodul "Recordset", nur daß sich dieses Modul nicht in lesbarer Form in Access VBA wiederfindet, sondern Bestandteil einer externen Bibliothek ist (die man über die Referenzen einbindet).
VBA weiß jetzt, daß "rs" nach dem Bauplan "Recordset" aufgebaut sein soll. Damit hat man aber noch kein Objekt.

Jetzt muß das Objekt noch erzeugt ("instantiiert") werden, dazu gibt es das kleine Schlüsselwort "New" - und Objekte werden in VBA immer mit Set erzeugt oder gelöscht:
Code:
    Set rs = New Recordset
Jetzt haben wir unser Objekt im Speicher, und alles, was ein Recordset kann, ist ebenfalls im Objekt enthalten. Also die Prozeduren zum Öffnen, zum Schließen, zum Aufrufen einer Abfrage usw. Das sind also die Objektprozeduren und ich kann ein Recordset auch nur verwenden, wenn das Objekt erzeugt wurde. Entsprechend kann man nun mit "rs.MoveNext" nun über die Objektvariable "rs" auf die Objektprozedur "MoveNext" zugreifen. Was den Datensatzzeiger des Recordsets eins weiterbewegt. Aber eben nur dieses Recordsets, denn vielleicht habe ich ja gleichzeitig auch "rs1" und "rs2" mit anderen Recordsets befüllt, die sich dabei natürlich nicht eins weiter bewegen sollen.
Also kann man hier gut sehen, daß Kopien von Modulen im Speicher offenbar doch einen Sinn machen - und auch die verwendeten Daten des Objektes, was in diesem Beispiel die Spalten und Zeilen der ausgelesenen Tabelle sind. Diese sollen nur für dieses eine Recordset gelten, und nicht für "rs1" und nicht für "rs2".

Das Konzept der Objektorientierung, daß ich hier nur kurz umrissen habe, wird in Access durchgängig verwendet, man kann sagen, beinahe immer, wenn eine Variable gefolgt von einem "." und einem Prozedurnamen oder Eigenschaftsnamen verwendet wird, handelt es sich um ein Objekt.

Deswegen ist "DoCmd.OpenForm" natürlich auch ein Objekt. Das Objekt ist "DoCmd" und wird von Access beim Starten von Access automatisch erzeugt. Die Prozedur oder Methode ist "OpenForm".
Und das Formular ist auch ein Objekt. Aber wo ist die Objektvariable? Die erzeugt Access und heißt so wie das Formular: "Form_DeinFormularname". Kann man aber nur verwenden, wenn das Formular die Eigenschaft "HasModule" aktiviert hat oder selbst Code enthält.
Aber ein Formular kann auch anders geöffnet werden. Indem man genauso wie beim Recordset vorgeht:
Code:
    Dim frm As Form_DeinFormularname

    Set frm = New Form_DeinFormularname
Damit wird das Formular geöffnet. Nur ist es jetzt noch unsichtbar, denn auch diesen Job übernimmt "OpenForm". Das muß man also auch selbst machen, mit
Code:
    frm.Visible = True
Und wenn man das z.B. in einem Standardmodul in eine Prozedur schreibt, sieht man ganz kurz ein Formular aufblitzen und wieder verschwinden.
Warum? Weil es mit Objektvariablen nicht anders ist als mit normalen Variablen: Wenn sie nicht mehr gültig sind, werden sie gelöscht und damit auch das komplette Objekt. Innerhalb einer Prozedur mit "Dim" erzeugte Variablen sind also nach Ausführung auch wieder gelöscht - und damit schließt sich das Formular gleich wieder. Denn das Öffnen der Form hält VBA hier nicht an, die Prozedur wird weiter ausgeführt. Man kann sich entweder mit einer Schleife behelfen oder man definiert die Objektvariable übergeordnet als Public und entsorgt sie nach Gebrauch selbst.

Warum nun überhaupt ein Formular so öffnen? Weil es den riesigen Vorteil hat, daß man das gleiche Formular xmal öffnen kann! Genau wie man mehrere Recordsets haben kann, kann man nun verschiedene Detailformulare zu einem Endlosformular gleichzeitig anzeigen - ohne eine Kopie des Formulars selbst erstellen zu müssen.

Worauf ich nach dieser kleinen Einleitung zum Thema Objekte aber mit diesem Beitrag eigentlich hinaus wollte, ist eine Eigenschaft, die in VBA kaum bekannt ist und kaum Verwendung findet:

Die Interfaces

Ein Interface soll in der objektorientierten Programmierung sicherstellen, daß es bestimmte Prozeduren und Eigenschaften usw. in allen Objekten gibt, die semantisch zusammengehören.
Das so oft und beliebte Beispiel Auto ist ganz gut geeignet: Wenn man ein Objekt "Lastwagen" definiert mit der Prozedur "Losfahren" und ein anderes Objekt "Fahrrad" mit der gleichen Prozedur "Losfahren", dann werden das beide Objekte intern sicherlich anders realiseren. Aber beide sollen von außen auf diese Weise zum Losfahren gebracht werden, ohne darüber nachzudenken, wie die Objekte das intern wirklich machen.

Also kann man einfach ein Interface definieren und den Objekten mitgeben, damit diese gezwungen werden, alles, was in dem Interface vorkommt, ebenfalls zu implementieren. Ob sie es wirklich tun oder nur eine leere Prozedur vorhanden ist, ist eine andere Sache, aber ein Aufruf von außen soll auf jeden Fall nicht "ins Leere" gehen und eine Fehlermeldung produzieren.

Ein Interface ist ganz simpel zu definieren: Man erzeugt ein neues Klassenmodul, benennt es möglichst kurz (als Standard hat sich eingebürgert, Interface-Namen immer mit einem großen "I" zu beginnen) und stellt dort einfach alle leeren Prozeduren und Eigenschaften ein. Zum Beispiel so:
Code:
Public Sub UpdateForm(Optional bolRequery As Boolean=True)

End Sub
Ja, wirklich, einfach so, völlig leer. Denn das Interface soll nur die Namen und Parameter einer gewünschten Prozedur (oder Eigenschaft etc.) definieren, mehr nicht. Code dazwischen würde einfach ignoriert werden.

Interfaces können nur in anderen Klassenmodulen eingesetzt werden, zum Glück sind Formulare ja eigentlich Klassenmodule und daher kann man sie hier verwenden. Dazu setzt man als erste Zeile (nach den üblichen Option-Befehlen) die Zeile:
Code:
    Implements IForm
Wenn das Interface "IForm" heißt (der Name des Klassenmoduls).
In der linken Dropdown-Liste des VBA-Editors findet man nun einen neuen Eintrag: "IForm". Wählt man diesen aus, sieht man in der rechten Liste alle definierten Prozeduren usw.
Diese können nicht nur, sie MÜSSEN alle einmal ausgewählt werden (hier im Beispiel ist es erst einmal nur dieses eine), damit der entsprechende Code in das Formular eingefügt wird. Das sieht dann so aus:
Code:
Public Sub IForm_UpdateForm(Optional bolRequery As Boolean = True)
   
End Sub
Da dies nun der richtige Platz für den Code ist, kann man diese Prozedur nun mit Leben befüllen, zum Beispiel so:
Code:
Public Sub IForm_UpdateForm(Optional bolRequery As Boolean = True)
    If bolRequery Then
        Me.Requery
      Else
        Me.Refresh
    End If
End Sub
Somit kann man jetzt dieses Formular von außen über die Prozedur "IForm_UpdateForm" aktualisieren, ohne wissen zu müssen, wie das Formular es im Einzelnen macht. Denn das Updaten könnte ja auch wesentlich komplizierter oder wesentlich einfacher aussehen - je nach Formular.

Das Interface bestimmt lediglich, daß es diese Prozedur geben muß, ob man sie verwendet oder mit Code füllt, wird nicht kontrolliert. Hat man aber dieses Interface in jedes Formular eingefügt und überall den Code entsprechend angepaßt, dann hat man codesichere Formulare, denn man weiß ganz genau, daß jedes Formular über eine solche Prozedur verfügt.
Was man sich also nur merken muß ist, bei jedem neuen Formular die "Implements"-Zeile zu verwenden. Wenn man dann den Compiler startet, wird sofort eine Fehlermeldung ausgegeben, wenn irgendeine der im Interface definierten Prozeduren, Eigenschaften, Parameter usw. nicht ganz genau so exakt in dem Formular umgesetzt wurde, daß das Interface implementiert.
Wenn es nur um eine einzige Prozedur geht, ist der Aufwand sicherlich zu groß, aber schnell kommen andere Nützlichkeiten hinzu oder man möchte einer Prozedur neue Parameter verpassen. Dann macht man das einfach im Interface und startet den Compiler. Sofort bekommt man Stück für Stück jedes Formular präsentiert, bei dem ein Parameter noch nicht angepaßt wurde oder bei dem eine Prozedur fehlt. Man kann dadurch nicht ein einziges Formular vergessen, denn ohne die korrekte Implementierung geht der Compiler nicht durch.

Also: Auch ohne die Objektorientierung aktiv zu nutzen oder eigene Klassen zu entwerfen, kann man sich mit einem Interface eine Menge Arbeit ersparen und für mehr Codesicherheit sorgen.

Viel Spaß beim Experimentieren...

Christian
Highcoder
Gast


Verfasst am:
18. März 2010, 14:53
Rufname:


AW: Interface-Nutzung in Access VBA - AW: Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Servus Christian.

Ich kann nur sagen: Das ist mal sowas von geil!

Sehr gute Info und dazu noch sehr schön ge- und beschrieben.

Danke!
derArb
getting better


Verfasst am:
18. März 2010, 15:05
Rufname: derArb
Wohnort: Berlin

AW: Interface-Nutzung in Access VBA - AW: Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Hallo,

suuuper Beitrag.

Danke
derArb

_________________
MfG
derArb

Scio me nihil scire...Εν οίδα οτι ουδέν οίδα... Ich weiss, dass ich nichts weiss (Sokrates)
Ich bevorzuge Beiträge mit korrekter deutscher Grammatik.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
18. März 2010, 21:10
Rufname:

AW: Interface-Nutzung in Access VBA - AW: Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Hallo,

danke, freut mich, wenn es Euch was gebracht hat...Smile

Gruß

Christian
motdeadcow
Neuling


Verfasst am:
02. Apr 2010, 03:43
Rufname:

AW: Interface-Nutzung in Access VBA - AW: Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Hallo Leute,

der Aufruf der Implements Anweisung sollte doch etwas genauer beschrieben werden.

1. Ein leeres Formular anlegen.
2. Eine Schaltfläche mit dem Namen cmdTest darauf plazieren.
3. Im Formular folgender Code
Code:
Option Explicit

Private oVersion As clsVersion   'Deklarieren des Objekts
Private m_Version As String    'Private Variable für die Versionsnummer

Private Sub cmdTest_Click()
    Set oVersion = New clsVersion
    Call GetTheVersion(oVersion)    'Versionsnummer holen mit Übergabe der Klasse
     Set oVersion = Nothing   'aufräumen
End Sub

Private Sub GetTheVersion(oIVersion As IVersion)  ' die Klasse wird in Beziehung zur Interface Klasse gebracht
'Jetzt bringen wir IntelliSense ins Spiel
    With oIVersion
        Call .GetVersion   'Version lesen
        m_Version = .Version  'Version zuweisen
        MsgBox m_Version
    End With
End Sub
Die Interface Klasse
Code:
'Eine Interface Klasse anlegen
'---------------------------------------------------------------------------------------
' Klasse: IVersion
' Verwendung: Klasse "IVersion"    (Interface Klasse)
' In der Interface Klasse alles Public
'---------------------------------------------------------------------------------------

Option Explicit

Public Sub GetVersion() as String: End Sub
Die Klasse
Code:
'Eine Klasse anlegen die das Interface einbindet

Implements IVersion

'---------------------------------------------------------------------------------------
' Module    : clsVersion
' Verwendung: Klasse "Version"    (Geschäftsebene)
' hier bitte alles Private
'---------------------------------------------------------------------------------------

Option Explicit

Private Property Get IVersion_GetVersion() As String
    IVersion_GetVersion = "Tolle Version 1.0"
End Property
in Bezug auf Clean Code sollte einer Klasse zur Offenlegung der Schnittstellen immer eine Interface Klasse hinzugefügt werden.

Zum Thema Implements bzw. Interface Klassen gibt es sehr gute Tuts und Beispiele im Internet.

Und keine Angst vor VB6.

Viel Spaß
Carsten
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
02. Apr 2010, 11:18
Rufname:

AW: Interface-Nutzung in Access VBA - AW: Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Hallo Carsten,

VBA basiert zwar auf VB6, aber VB6 kann durchaus mehr als VBA. Das nur mal am Rande.

Ich kann jetzt nicht behaupten, zu verstehen, was an Deinem Code besonders "Clean" oder "genauer beschrieben" wäre. Der Sinn der Zwischenklasse erschließt sich einem beim Lesen auch nicht wirklich. Ein Formular IST bereits eine vollwertige Klasse und kann damit ein Interface selbst implementieren, benötigt keine zusätzliche Klasse. Da alle Interface-Methoden/Eigenschaften implementiert werden MÜSSEN, ist auch alles rund um das Interface in der Formularklasse bereits beschrieben. Und man hat einen einfachen Anwendungsfall, der leicht nachzuvollziehen ist.

Zu Deinem Konstrukt sollte man vielleicht noch hinzufügen, was der eigentliche Sinn eines Interfaces ist (was natürlich in meinem Artikel oben nicht vollständig beschrieben ist): Sozusagen eine "spezielle Sicht auf eine Klasse" herzustellen.

VBA kennt ja keine Vererbung, wie es in richtigen objektorientierten Programmiersprachen der Fall ist. In diesen kann ein Objekt von (meistens nur) einem anderen Objekt abgeleitet, "vererbt" werden. Hier hat ein Interface u.a. die Möglichkeit, weitere Standardklassen darzustellen, von denen sozusagen (nicht ganz korrekt) "geerbt" werden kann, mit dem Unterschied, daß Interfaces eben keinen eigenen Inhalt haben, aber die "erbende" (eigentlich "implementierende") Klasse zwingen, weitere Standardmethoden/-eigenschaften einbauen zu müssen.

In der OOP verwendet man Interfaces aber eben nicht nur, um sozusagen "nix zu vergessen", sondern im wörtlichen Sinn des Wortes "Interface": Als Schnittstelle zwischen verschiedenen Klassen.

Eine Klasse A ruft von Klasse B immer nur ganz bestimmte Methoden und Eigenschaften auf, deswegen benötigt sie keinen Zugriff auf die sonstigen Methoden und Eigenschaften, die Klasse B auch noch parat hält. Als "Vermittler" kann dann hier die Schnittstelle dienen, indem die Klasse B eben nicht als vollständige Klasse, sondern nur mit den aus dem Interface benötigten Methoden und Eigenschaften instanziiert wird (oder genauer: Das Objekt aus dieser Klasse ist natürlich immer noch vollständig, aber durch das Interface "sieht" man nur den benötigten Teil).
Das hast Du ja durch die folgende Zeile demonstriert:
Code:
Private Sub GetTheVersion(oIVersion As IVersion)  ' die Klasse wird in Beziehung zur Interface Klasse gebracht
Innerhalb dieser Prozedur hat man in "oIVersion" nur noch den Teil des Objektes zur Verfügung, den man aus dem Interface benötigt. Das kommt leider aus Deinem Beispiel nicht heraus, denn die Klasse "clsVersion" besteht hier nur aus der einen Funktion, die aus dem Interface kommt und macht damit die Zusatzklasse überflüssig.
Ein sinnvolleres Beispiel wäre es, würde die Klasse "clsVersion" außerdem z.B. noch ein zweites Interface mit anderen Methoden/Eigenschaften implementieren und darüber hinaus auch noch andere eigene öffentliche und private Methoden/Eigenschaften. Damit könnte man dann zeigen, daß man die gleiche Klasse auch mit einem anderen Interface instantiieren kann und dann nur die Methoden/Eigenschaften des anderen Interfaces zur Verfügung hätte. Außerdem natürlich auch noch als "normale" Instanz, ohne über ein Interface zu gehen.

Grob gesagt, kann man ein Interface mit einer Abfrage auf eine einzelne Tabelle vergleichen: Ruft man die Tabelle auf, erhält man alles. Ruft man die Abfrage auf, erhält man auch die gleiche Tabelle, aber sieht nur noch den Teil, der in der Abfrage definiert ist (ich weiß, ist kein ganz korrekter Vergleich, aber so kann man es sich leichter vorstellen).

Sinn eines Interfaces ist damit, daß "fremde" Klassen auf bestimmte Teile einer Klasse, die ein oder mehrere Interface(s) implementiert, zugreifen können, ohne vom Rest der Klasse zu "wissen" oder darauf zugreifen zu können. Eben wie bei einer Schnittstelle im "richtigen" Leben: Man klinkt seinen Klinkenstecker in die Klinkenbuchse des Kopfhörereingangs ein und erhält über diese Schnittstelle Zugriff auf die Musikausgabe des Players. Der Kopfhörer muß aber nicht wissen, ob es noch eine Aufnahmefunktion gibt, ob es ein MP3-Player oder ein Kassettenrecorder oder ein CD-Player ist. Die definierte Schnittstelle ist die 3,5mm-Klinkenbuchse, die der Player implementiert hat, und der Kopfhörer kann sich darauf verlassen, daß an dieser Schnittstelle nur Musikausgabe stattfindet. Und er weiß genau, daß an einem Ring der rechte, am anderen der linke Stereokanal anliegt. Mehr muß der Kopfhörer nicht über den Player dahinter wissen.

Genauso verhält es sich auch mit dem Eingangs-Beispiel zu "UpdateForm": Von außen muß ich nur wissen, daß es diese Schnittstelle gibt, um sie nutzen zu können, alles Übrige wird nicht benötigt. Und somit könnte man nun auch das Formular als vollwertige Klasse mit einem Interface aufrufen wie im Beispiel von Carsten, aber man kann sich das Leben auch unnötig kompliziert machen, der Code würde in diesem Fall deutlich komplizierter und undurchsichtiger werden. Für mein einfaches Beispiel oben genügte die gezeigte Methode völlig. Für eine saubere Klassenkommunikation im eigentlichen Sinn einer Schnittstelle ist die Methode von Carsten natürlich korrekter.

Keine Angst davor, Dinge auch mal "anders" zu machen, wenn es der Übersichtlichkeit und Einfachheit von Code dienlich ist. Auch die 3.Normalform und darüber muß nicht immer sein, man kann sich auch das Leben selbst schwer machen durch zuviele Regeln.

Wenn es um die Entscheidung zu besserer Performance und besserer Code-Lesbarkeit geht, bin ich immer für die Lesbarkeit und Performance.

Gruß

Christian
motdeadcow
Neuling


Verfasst am:
10. Apr 2010, 02:27
Rufname:

AW: Interface-Nutzung in Access VBA - AW: Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Hallo Christian,

So eine Antwort kommt heraus, wenn man Copy und Paste benutzt. ;)

Mein Beitrag sollte eigentlich nur eine Ergänzung zu deinem sein, und kleinere Schwachstellen aufzeigen.

Es ist ein Fragment einer Arbeit von Jugendlichen die im Praktikum ein Refactorin umgesetzt hatten.
Das Ergebnis sollte ein trennen von Oberfläche und Code sein (n-Tier in Access), wobei in dem Fragment der Zugriff auf die Daten fehlt.

Außerdem sollten die Klassen und der Zugriff darauf unabhängig voneinander sein,

heisst im Objectexplorer nicht doppelt auftauchen (deshalb in der Klasse alles private)
beim kompilieren sollten keine Fehler auftauchen die korrigiert werden müssen.
siehe
Code:
Private Sub GetTheVersion(oIVersion As IVersion)  ' die Klasse wird in Beziehung zur Interface Klasse gebracht
könnte ohne Änderung auch als
Code:
Private Sub GetTheVersion(oIVersion As IVersionCool)  ' die Klasse wird in Beziehung zur InterfaceCool Klasse gebracht
übergeben werden.

Die Anspielungen auf VB6 sollten nur einen Hinweis darauf geben, das VB6 Code fast immer in Access benutzt weden kann.

Deine Antwort zeigt mir aber auch, das hier keine Anfänger am Werke sind.

Ein Forum über OOP/ Access wäre nicht schlecht.

Mit freundlichen Grüßen
Carsten
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
10. Apr 2010, 08:22
Rufname:


AW: Interface-Nutzung in Access VBA - AW: Interface-Nutzung in Access VBA

Nach oben
       Version: (keine Angabe möglich)

Hallo Carsten,

ein Extra-Forum für dieses (leider) eher seltene Thema wäre vielleicht ein bißchen übertrieben, zumal die meisten Leute anscheinend schon so nicht wissen, wo sie ihre Beiträge schreiben sollen, wie man immer wieder an Fragen hier in diesem Unterforum sieht, obwohl "draußen" groß dransteht, daß dies kein Frageforum ist.

Es wäre vielleicht mal eine gute Idee, wenn Du zu dem Thema "n-Tier" und Kapselung zu Deinen/Euren Erfahrungen im Bereich Access einen eigenen Artikel schreiben würdest, denn ich könnte mir gut vorstellen, daß dieses interessante Thema auch sehr viele andere Leser interessiert.
Über OOP gibt es in der Internetwelt und in der Literatur zwar schon ausreichend Stoff, gerade aber über die relativ schwachen VBA-Umsetzungsmöglichkeiten gibt es kaum Artikel.
Wenn Dein Projekt natürlich gar nicht in Access umgesetzt wurde, sondern in VB6, hilft es nicht viel, denn über dessen Möglichkeiten der OOP verfügt Access leider nicht.

Gruß

Christian
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: CSS Forum