Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
TempVars-Collection - Stiefkind aus der Makroprogrammierung
Gehe zu Seite 1, 2  Weiter
zurück: Datenexport aus Access in eine Excel-Vorlage weiter: Regionals-Funktionsbibliothek für regionale Formatumwandlung 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:
17. Sep 2010, 20:02
Rufname:

TempVars-Collection - Stiefkind aus der Makroprogrammierung - TempVars-Collection - Stiefkind aus der Makroprogrammierung

Nach oben
       Version: (keine Angabe möglich)

Hallo zusammen,

wer Makros programmiert, kennt sie bereits indirekt, die TempVars-Collection. Mit "SetTempVar" (bzw. der kruden deutschen Übersetzung "FestlegenTempVar") kann man so in Makros Variablen definieren.

Weniger oft wird diese praktische Collection in VBA eingesetzt, weil man da ja alle Möglichkeiten von Variablen und komplexen Objekten oder eigenen Collections hat. Eigentlich braucht man also keine TempVars-Collection in VBA - aber die TempVars-Collection hat eine einzige Eigenheit, die sie auch für VBA wertvoll macht: Ihre absolute Persistenz.

Legt man einen Wert dort ab, bleibt er schlicht erhalten, bis man Access wieder schließt oder ihn selbst entfernt. Das ist insbesondere für die objektorientierte Programmierung in Access interessant, weil man so wichtige Werte zwischenspeichern kann. VBA hat nämlich leider die Eigenheit, bei einem nicht abgefangenen Fehler alle Objektvariablen zu löschen, so daß man erst das Programm neu starten muß. Man hat also so keine Möglichkeit, wichtige Variablenwerte dauerhaft zu speichern, was besonders beim Debuggen stört.

TempVars ist kein Hexenwerk, es ist einfach ein Objekt vom Typ Collection, das in Access ein wenig erweitert und auf eine Funktion beschränkt wurde. Ein normales Collection-Objekt wird gewöhnlich dafür verwendet, um eine beliebige Sammlung von Variablen oder Objekten in ihr zu speichern, der Collection ist völlig egal, was sie angeboten bekommt (praktische Sache, sollte man sich mit befassen, wenn man noch nie mit Collections gearbeitet hat!).
Die TempVars-Collection kann dagegen nur einen Datentyp aufnehmen: Variant. Damit können alle VBA-Basistypen wie String, Integer, Double usw. gespeichert werden, leider allerdings keine Objektreferenzen.

Ansonsten funktioniert sie sehr ähnlich wie ein Collection-Objekt: Mit "Add" werden neue Werte hinzugefügt, mit "Remove" wieder entfernt und im Gegensatz zum Collection-Objekt gibt es auch noch "RemoveAll" zum kompletten Löschen aller Werte. Man schreibt also zum Zuweisen einer neuen Variable zum Beispiel:
Code:
    TempVars.Add "Variablenname", "Variableninhalt"
Das würde eine neue Variable namens "Variablenname" anlegen und ihr den String "Variableninhalt" zuweisen, den man so auch wieder herausbekommt:
Code:
    Dim strTest As String
   
    strTest = TempVars("Variablenname")
"strTest" hätte danach dann den Inhalt "Variableninhalt".

Wie jedes Collection-Objekt hat auch TempVars noch eine Count-Eigenschaft, so daß man sich auch ansehen kann, ob und wieviele Variablen bereits drin sind. Die Variablennamen müssen eindeutig sein, wenn man einen weiteren Wert mit Add zuweist, wird der alte überschrieben. Auch da ist der Unterschied zur normalen Collection: Die erlaubt keine Speicherung unter dem gleichen Index.

Da die TempVars ja nie ihre Werte verliert, kann man damit zum Beispiel Parametersammlungen zwischen Formularen austauschen (was mit "OpenArgs" nur sehr mühsam geht), man kann diese praktische Collection aber auch für Klassenobjekte verwenden. Beispielsweise, wenn man die Daten eines Datensatzes als Eigenschaften eines Klassenobjektes zwischengespeichert hat, damit man diese schneller auslesen kann und sie immer zur Verfügung stehen, ohne jedesmal auf die Datenbanktabelle zugreifen zu müssen (was bei einer lokalen Datenbank keine Bedeutung hat, aber bei Netzwerkdatenbanken den Datenverkehr minimieren kann).
Da Objektdaten bei einem nicht abgefangenen Fehler verlorengehen, kann man nun einfach die ID des richtigen Datensatzes in der TempVars-Collection speichern, und wenn jemand auf die Objekteigenschaften zugreift, kann das Objekt feststellen, daß es keine Daten mehr hat und sich selbst neu initialisieren anhand dieses TempVars-Wertes.

Ein Beispiel dafür ist eine selbstprogrammierte Benutzerverwaltung, bei der man die Benutzerdaten für die Programmlaufzeit im Speicher halten möchte. Der Benutzer meldet sich an und man speichert die Primary Key ID des Benutzerdatensatzes in TempVars und liest dann den restlichen Datensatz in die einzelnen Objekteigenschaften ein. Gehen die Objektdaten oder gleich das ganze Objekt verloren, dann kann das aufrufende Programm einfach ein neues Objekt erstellen und dieses kann dann im "Class_Initialize" Event prüfen, ob es schon einen ID-Wert in den TempVars gibt und wenn ja, sich selbst wieder mit den richtigen Daten befüllen.

Ebenso kann man natürlich auch eine Reihe von Datensätzen in einem Formular filtern, dann in einer Schleife deren IDs auslesen und mit VBA-Join dann zu einer String-Variablen verketten und in den TempVars speichern. Das Formular kann dann ruhig geschlossen werden, die gefilterten Datensatz-IDs stehen weiterhin in einer simplen Stringvariablen zur Verfügung - und da es in SQL die praktische IN-Klausel gibt, kann man so einen Sting in einem WHERE auch gleich einsetzen, um gezielt diese Datensätze jederzeit wiederherzustellen oder irgendwelche Operationen damit auszuführen usw.

Wenn man sich also einfach nur erinnert, daß TempVars eben grundsätzlich keine Inhalte verliert und beliebig viele Werte speichern kann, dann ist der Rest nur eine Frage der eigenen Phantasie, was man damit alles machen kann....

Viel Spaß beim Experimentieren.

Christian
derArb
getting better


Verfasst am:
17. Sep 2010, 20:34
Rufname: derArb
Wohnort: Berlin


AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo,

das klingt ja revolutionär und lässt mich überlegen, meine ganzen globalen Variablen
zu überdenken. Die sind zwar abgesichert und gehen nicht "Kaputt", aber ich will das trotzdem mal nachvollziehen.
Hat jemand negative Erfahrungen damit?

MfG
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:
17. Sep 2010, 20:42
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo derArb,

prinzipiell kannst Du in der Tat auch die globalen Variablen auf diese Weise vorhalten. Ich würde in dem Fall allerdings empfehlen, für jede TempVars-Variable eine Konstante anzulegen, zum Beispiel so:
Code:
Public Const cVAR_MeineGlobaleVariable = "MeineGlobaleVariable"
Das hat den Vorteil, daß Du überall im Code statt des Literals einfach die Konstante aus IntelliSense auswählen kannst, besonders, wenn alle Konstanten z.B. mit "cVAR_" beginnen wie im Beispiel, dann stehen sie in IntelliSense alle untereinander.

Im Code würde man also zum Beispiel schreiben:
Code:
    TempVars.Add cVAR_MeineGlobaleVariable, "Inhalt"
Auf diese Weise kann es nicht zu Schreibfehlern kommen, was bei Literalen sehr schnell mal passieren kann. Daneben kann man natürlich so auch den Namen der Variablen an einem einzigen Ort verändern, nämlich in der Konstantendefinition.

Gruß

Christian
derArb
getting better


Verfasst am:
17. Sep 2010, 20:50
Rufname: derArb
Wohnort: Berlin

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo,

sehr spannend...
werd ich am WE ausprobieren..

Danke und MfG
derArb

_________________
MfG
derArb

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


Verfasst am:
29. Sep 2010, 17:25
Rufname:
Wohnort: NRW


AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo miteinander,

wieder mal ein hochinteressanter Beitrag von Bitsqeezer!

Ich vermisse nur den Hinweis, ab welcher Version die TempVars-Collection verfügbar ist - "keine Angabe möglich"
ist hier eher eine unglückliche Wahl. Ich schätze mal ab A2007...?!

_________________
Gruß MissPh!
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
29. Sep 2010, 19:06
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: Office 2007

Hallo MissPh,

danke für die Blümchen...Smile
Du hast recht, ich wußte nicht, daß die Vorversionen diese Collection nicht beinhalten, hab's mal in einem Office 2003 geprüft, da gibt es keine TempVars-Collection (und nebenbei auch nicht den dazugehörigen Makrobefehl), habe auch keinen anderen Befehl gefunden, um Variablen in Makros in 2003 anzulegen.
(Wieder ein Grund mehr, warum ich mich mit Makros nie weiter beschäftigt habe und sie aus jeder Access-Anwendung eliminiere...)

Entsprechend kann man also sagen, daß es wohl tatsächlich erst seit Access 2007 geht.

Danke für den Hinweis!

Gruß

Christian
MissPh!
Office-VBA-Programmiererin


Verfasst am:
29. Sep 2010, 19:21
Rufname:
Wohnort: NRW

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: Office 2007

Ja, das klingt plausibel und macht Sinn, denn mit A2007 hat sich die Philosophie bezüglich Makros ja leider grundlegend geändert:
Bei mit dem Assistenten erstellten Befehlsschaltflächen gibt es keine Ereignisprozeduren mehr, sondern die Aktionen werden
in eingebetteten Makros versteckt. Shock

Um den Makroeinsatz einem altbewährten VBA-Programmierer schmackhaft zu machen, da nützen aber auch die neuerdings
verfügbaren Variablen nichts und auch nicht die möglicherweise verbesserte Fehlerbehandlung.

Wirklich schade, dass es hier noch nicht einmal eine Wahlmöglichkeit gibt! Sad

Umso genialer die Idee, sich die TempVars auch im VBA-Code zunutze zu machen! Wink

_________________
Gruß MissPh!
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
29. Sep 2010, 19:49
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo MissPh,

da kann ich Dir gleich noch einen Tip geben - habe mich bei meinen ersten Versuchen mit Access 2007 genau darüber auch sehr geärgert:

Schau mal in den Optionen unter "Objekt-Designer" und dort unter "Formulare/Berichte", da findest Du einen Punkt "Immer Ereignisprozeduren verwenden", einmal abhaken, damit erscheint schon mal beim Klick auf Eventfunktionen automatisch der VBA-Editor.

Und die lästigen Makros wird man leider nicht los, aber in Datenbanktools kann man "Makros des Formulars zu Visual Basic konvertieren", dann hat man auch wieder die Prozeduren (in gewohnt schlechter Qualität, weswegen ich mittlerweile grundsätzlich keine Assistenten mehr verwende, außer, um die Bildchen zuzuweisen).
Das funktioniert auch mit Makros, die in der "Module"-Liste stehen.

Gruß

Christian
Sascha Trowitzsch
Im Profil kannst Du frei den Rang ändern


Verfasst am:
25. Nov 2010, 22:05
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Zitat:
Die TempVars-Collection kann dagegen nur einen Datentyp aufnehmen: Variant. Damit können alle VBA-Basistypen wie String, Integer, Double usw. gespeichert werden, leider allerdings keine Objektreferenzen.
Mit einem Trick ist auch dies möglich, indem man in der Tempvar den Objekt-Pointer (Long-Wert) abspeichert:
Code:
    TempVarXY = ObjPtr(MeinObjekt)
Um daraus später wieder das Objekt zu erhalten, bedarf es einer zusätzlichen Routine, wie dieser:
Code:
    Set MeinObjekt = ObjectFromPointer(TempvarXY)
mit
Code:
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" _
    (Destination As Any, Source As Any, ByVal Length As Long)

Function ObjectFromPointer(lPtr As Long) As Object
    Dim oTemp As Object
   
    CopyMemory oTemp, lPtr, 4
    Set ObjectFromPointer = oTemp
    CopyMemory oTemp, 0&, 4
End Function

Ciao, Sascha
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
27. Nov 2010, 17:44
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo Sascha,

danke für den Hinweis, damit könnte man sicher auch einen Objektzeiger speichern. Allerdings hat die Sache einen Haken: Objekte werden bei einem nicht abgefangenen Fehler von Access zerstört, weswegen es zweifelhaft ist, ob der Zeiger auf die Speicheradresse dann noch viel bringen würde. Wenn der Speicher zwischendurch anders belegt wurde (freigegeben), dürfte diese Methode einen satten Absturz zur Folge haben.

Der Sinn der TempVars-Collection hier war ja gerade, Variablen über so einen Fall hinwegzuretten, für das sonstige Speichern von Objekten gibt es ja genug sicherere Möglichkeiten.

Würde die TempVars-Collection dagegen den Zeiger auf das Objekt selbst speichern können, wie es jede andere Collection kann, dann würde vermutlich auch das Objekt nicht gelöscht werden - das wäre das Optimum.

Gruß

Christian
Sascha Trowitzsch
Im Profil kannst Du frei den Rang ändern


Verfasst am:
01. Dez 2010, 14:14
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hi Christian,

Ist richtig, was du da ausführst.
Wenn das Objekt nicht mehr existiert, dann gibt es einen Absturz, weil über den ehemaligen Objektpointer auf Speicherbereiche zugegriffen wird, die nicht mehr alloziert sind.

Es gibt mir mehr ums Prinzip, wobei ich zumindest einen konkreten Anwendungsfall habe:
Für die Ribbonprogrammierung braucht man, wenn man zur Laufzeit Controls ansprechen möchte (InvalidateControl etc.), einen Verweis auf das IRibbonUI-Objekt, welches man beim Start der DB per Load-Callback von Access bekommt.
Wenn etwa durch unbehandelte Fehler diese Objektvariable zerstört wird, so hat man nachträglich keine Möglichkeit mehr, diesen Verweis zu bekommen. Man muss die DB neu starten.
Hat man aber stattdessen in einer Tempvar den Objekt-Pointer des IRibbonUI festgehalten, so lässt sich die Objektvariable über obigen Code jederzeit wiederherstellen.
Sprich: Für Objektverweise auf Objekte, die noch bestehen, lässt sich die Routine einsetzen.
Anderes Beispiel, welches zwar nutzlos ist, aber den Vorgang verdeutlicht:
Code:
    Set dbs = DBEngine(0).Databases(0)
    TempVars.Add "objptr", ObjPtr(dbs)
    Set dbs = Nothing
    Set dbs = ObjectFromPointer(TempVars("objptr"))
    Debug.Print dbs.TableDefs.Count

Ciao, Sascha
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
01. Dez 2010, 17:39
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo Sascha,

danke für die Idee, damit hast Du eine sehr gute Anwendungsmöglichkeit genannt, mir ohnehin unbegreiflich, wieso MS den Link auf dieses Objekt nicht als Office-Standardobjekt permanent zur Verfügung hält (habe noch nicht ausprobiert, ob sich das in 2010 geändert hat).

Genau aus dem Grund habe ich die Ribbons bisher nur als "Einbahnstraße" benutzt - z.B. für Buttons, die ihre zugehörige Funktion immer finden, während InvalidateControls ja die andere Richtung ist, bei der VBA den Inhalt des Ribbons ändern soll, was eben ohne diesen Objektzeiger nicht funktioniert.

Schade, daß es kein TempVars bei Excel gibt. Man müßte vielleicht Deinen Trick verwenden, um den Objektzeiger in irgendein permanentes Objekt in Excel zu kopieren, z.B. eine Zelle in einem Sheet.

Gruß

Christian
pigeldi
Rudimentärer VBA-Bastler


Verfasst am:
25. Jan 2011, 12:37
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Wie von Bitsqueezer angesprochen, ich stehe vor genau diesem Problem in Excel. Hat jemand eine Ahnung, wie ich den Zustand auf einem Tabellenblatt zwischenspeichern kann, so dass ich ihn von dort auch wieder auslesen kann?
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
25. Jan 2011, 13:06
Rufname:

AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo,

die Funktion "ObjPtr", die Sascha oben angesprochen hat, liefert einen Long-Wert zurück. Da das ja nur eine ganz normale Zahl ist, kannst Du sie auch in eine Zelle eines Excel-Sheets schreiben und von dort wieder auslesen. Du mußt halt nur sicherstellen, daß der User sie nicht überschreibt. Außerdem muß der Wert bei jedem neuen Laden des Workbooks neu geschrieben werden, weil er immer wieder anders ist. Wenn Du dann den alten Wert verwenden würdest, der mit dem Workbook gespeichert wurde, gibt's sehr wahrscheinlich einen Absturz.

Ich hab's selbst aber noch nicht ausprobiert.

Gruß

Christian
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
03. Jan 2012, 18:45
Rufname:


AW: TempVars-Collection - Stiefkind aus der Makroprogrammier - AW: TempVars-Collection - Stiefkind aus der Makroprogrammier

Nach oben
       Version: (keine Angabe möglich)

Hallo,

hier mal eine kleine Demo, die zeigt, wie man ein Klassenmodul dazu verwenden kann, Daten aus einer Tabelle (hier eine Benutzer-Logintabelle) in der Anwendung vorzuhalten. TempVars wird hierbei benutzt, um die UserID im Speicher zu halten, auch wenn das Objekt verlorengeht (zum Beispiel bei einem nicht abgefangenen Fehler). Die zuletzt verwendete UserID wird in TempVars gesichert und das Objekt initialisiert sich selbst mit den übrigen Daten über Class_Initialize: Ist eine UserID in TempVars, dann wird der entsprechende Datensatz wieder erneut geladen und die Variablen zugewiesen.

Das Objekt instantiiert sich automatisch über die Function "Login", die im Modul "modObjects" steht. So kann man in VBA einfach so einen User laden (ID 1):
Code:
Login.LoadUser 1
Und danach kann man auf alle Attribute zugreifen z.B. mit:
Code:
Debug.Print Login.Uservorname
Wenn nun das Objekt verlorengeht, braucht man nicht mit LoadUser den User erneut zu laden, da dessen ID ja noch in TempVars steht. Durch die Initialisierung des Objektes in der Funktion "Login" lädt sich der User beim Zugriff einfach selbst. Also einfach erneut z.B. mit "Login.Uservorname" auf den Vornamen zugreifen und schon hat man alle Daten wieder da. Das macht das Arbeiten in VBA sehr bequem.

Auch hat das Objekt den Vorteil, daß Variablen "intelligent" sein können. Beispielsweise ist die Eigenschaft "Kennwort" als "Write Only" definiert - man kann zwar einen Wert hineinschreiben, aber nicht auslesen. Hier könnte man außerdem auch den Kennwort-Wert gleich wieder in die Tabelle zurückschreiben (zum Beispiel, wenn der User sein Kennwort ändern möchte).

Die Methode soll aber nur zeigen, wie man die TempVars-Collection einsetzen kann, es soll nicht zeigen, wie ein ordentlicher Login funktioniert. Die hier gezeigte Methode würde sicher keinen besonderen Schutz bieten, da die Kennwörter in der gleichen Tabelle wie die Userdaten liegen und im Klartext gespeichert werden. Außerdem nimmt man statt einer Combobox mit der Liste aller verfügbaren User lieber ein Textfeld, damit ein Hacker nicht gleich schon die Liste aller User verfügbar hat. Ebenso ist ein Anmeldename sinnvoll, der nicht unbedingt einem Standardschema folgt wie hier, so daß man ihn möglichst nicht erraten kann. Für eine echte Datenbank sollte man sich also bedeutend bessere Sicherheitsrichtlinien erstellen und die Anmeldung verbessern. Die Demo hier soll nur das Prinzip der Arbeit mit Klassenmodulen und TempVars zeigen und ist deswegen sehr einfach gehalten.

Der Anhang ist nur im Format A2007, da es die TempVars vorher ja noch nicht gab.

Viel Spaß beim Ausprobieren und Entwickeln eigener Varianten...

Christian



TempVars.zip
 Beschreibung:
Zeigt, wie man TempVars einsetzt, damit ein Objekt eines Klassenmoduls sich selbst neu befüllen kann.

Download
 Dateiname:  TempVars.zip
 Dateigröße:  27.47 KB
 Heruntergeladen:  96 mal

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

Gehe zu Seite 1, 2  Weiter
Diese Seite Freunden empfehlen

Seite 1 von 2
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

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Programmierung / VBA: Makroprogrammierung mit Access 8 DENDEMANN 715 30. März 2007, 10:35
DENDEMANN Makroprogrammierung mit Access
Keine neuen Beiträge Access Programmierung / VBA: Makro-Programmierung 1 Scarlett1 1025 19. März 2006, 08:27
stpimi Makro-Programmierung
Keine neuen Beiträge Access Programmierung / VBA: Ich möchte Makroprogrammierung in Access lernen 8 koerschgen2001 1851 15. Nov 2005, 16:07
stpimi Ich möchte Makroprogrammierung in Access lernen
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Microsoft Excel-Formeln