Office: (Office 2016) Form.Controls-Auflistung

In den jeweiligen Binary-Data-Streams der einzelnen Objekte innerhalb der mdb/accdb-Datei. Das interne Datenformat von Access ist von Microsoft bisher leider nicht offengelegt. Die wenigen Leute, die es (zumindest teilweise) reverse-engineered haben, behalten es auch für sich, weil Ihr Geschäftsmodel darauf basiert...

 

Liebe Leute,

nur die Ruhe.
1. Felder über ihren controls-Index anzusprechen ist m. E. eleganter, da ich den Namen nicht erst zusammenbasteln muss und so nicht unnötiger Stringmüll entsteht (garbage collection); Access muss dann auch nicht erst danach suchen, selbst wenn die Namen in einem binary tree gespeichert sind. Ich hatte vor Jahren (acc2000) mal einen Test mit ca. 300 Feldern gemacht und die Performance war per Index einfach besser.
2. Was ist ein Recordset anderes als ein Array und eben ein set of records (Plural)? Wenn ich meine Daten also komplett als RS lade, kann ich einfach auf sie zugreifen, sie verändern/kombinieren, in meine GUI-Felder schreiben und aus ihnen wieder zurück in meine DB-Tabelle.
3. Ein Problem von UFOs sind ungebundene Felder. Gebe ich z.B. in ein ungebundenes Feld eines Endlos-Ufos einen Wert ein, wird dieser Wert in allen 'geklonten' Ufos angezeigt. Ich habe bisher nicht herausgefunden, wie ich den scope auf genau ein Ufo beschränken kann.
4. Ich habe jetzt eine Referenztabelle gebaut, die mir die Controls-Indizes in ein schlankes Integer-Array liest (das dauert bei 450 Feldern kaum eine Sekunde).
5. Den Controls-Index zu nutzen, weil es ihn gibt, ist für mich genau so selbstverständlich, wie die Font-Eigenschaft zu nutzen, weil es sie gibt.
6. Ich habe meine Felder nach dem Schema FFnnn benannt (natürlich per VBA). Was ist nun eleganter (Luftcode)
for i = 1 to max
feldname = "FF" & rechts(str$(i+1000),3)
me.controls(feldname) = "Otto"
next

oder

for i = 1 to max
me.controls(referenztabelle(i)) = "Otto"
next
7. Ich bin nicht der Ansicht, dass meine Beschreibung kompliziert ist.
8. Letztlich will ich sogar Daten aus 3 Tabellen in meinen Feldern kompakt darstellen. Jeder Tabellen-Auszug enthält jeweils genau 450 Zeilen mit je ca. 3 bis 5 Werten. Es erscheint mir einfacher, diese Daten als Recordsets zu laden, meine Berechnungen anzustellen und die Ergebnisse in meine (ungebundenen) Felder zu schreiben. Und Access braucht sich nicht darum zu kümmern... Erst wenn ich fertig bin, werden veränderte Daten per Code in die zugrunde liegenden Tabellen zurück geschrieben. Dies käme durchaus auch einer asynchronen Verarbeitung in einem .Net-Projekt nahe. Ich will Access einfach nur als GUI nutzen, das Interagieren mit der Datenbank mache ich selbst. Ist das sooo abwegig?

@josef P.
Das wäre ja durchaus ein interessanter Ansatz. Aber mit meiner Ref-Tabelle klappt es auch so. Ich glaube, dass ich so etwas früher schon gemacht habe, insbes. in VB.Net. Ich habe damals einfach ein Feld als Layout-Quelle definiert und es dann per Code geklont. War sehr elegant und ich habe mir viel 'Fitzelei' im Form-Editor gespart.

@Maggie_may
Ich möchte hier niemand von irgendwas überzeugen, also bitte Ruhe bewahren. Mein Ansatz ist sicher nicht so falsch, denn es geht um Ergonomie für den Anwender.
Die Darstellung von 450 Feldern in einer einzigen Form, noch dazu mit 3 Tabellen als Quelle - wie willst du das ergonomisch und elegant gestalten, auch aus Programmiere-Sicht?
Natürlich kann man Daten in System-Tabellen ändern, denn in ihnen gespeicherte Daten entstammen ja Eingaben und Änderungen über die Access-Oberfläche. Access benutzt sich selbst, um z. B. Forms zu speichern. Alles kein Hexenwerk und durchaus strukturiert.

Wenn ich soweit bin, werde ich gern ein Beispiel hier hochladen. Im Moment halte ich das allerdings für verfrüht und nicht sinnvoll.

Liebe Grüße,
Dinkel

 

Nur gut, dass ich das nicht wusste, sonst wäre ich nie auf die Idee gekommen, mir eine Routine zu schreiben, die mir die Eigenschaften der Controls zeigt.

Im Modul ShellExecute steckt die Prozedur tt, die macht genau das. Bitte die Db nicht weiter anschauen, ist schlicht zum Ausprobieren.

 

Warum? Dass irgendwas in einem schwer verständlichen internen Format gespeichert ist, heißt ja nicht, dass du nicht auch durch eine einfache, dokumentiere API (in diesem Fall das Access-Objektmodell) darauf zugreifen kannst.

 

Für sich gesehen ist die zweite Variante in meinem Empfinden durchaus eleganter. Den weniger eleganten Code hast du dann aber beim Aufbau deiner Referenztabelle genauso wie in der ersten Variante.
Daher bleibe ich bei meiner Auffassung, dass die erste Variante insgesamt weniger komplex und einfacher zu verstehen ist.

Ob es von der Performance her einen Unterschied macht, möchte ich weiterhin bezweifeln. Probier es doch einfach mal aus und poste dann mal die Vergleichsergebnisse hier.

 

Schon einmal daran gedacht ein ado recordset zu verwenden.
Entweder das Recordset mit den berechneten Daten öffnen, oder falls nicht möglich die restlichen Berechnungen selbst durchführen und in das recordset schreiben.
Dann kannst du das fertige Recordset dem UF zuweisen.
Der User führt die Änderungen durch und du kannst sofort bei jedem Update die Änderungen wie erforderlich in die Original Tabellen zurückschreiben.
Das würde eine ganze Menge unnötigen Aufwand ersparen, und die Performance wäre auch viel besser.

LG Markus

 

\@Dinkel:

Ja eben, über die Oberfläche.
Welche Systemtabelle dir bei diesem Projekt helfen könnte bleibt unklar. Klar ist lediglich, dass Systemtabellen generell nicht (von außen) änderbar sind. Änderst du den Namen eines Formulars, schlägt sich das natürlich auch in der Systemtabelle nieder, aber niemals kannst du dort selbst einen Eintrag direkt in der Tabelle ändern.

Die Formulare findet man wie alle anderen Objekte in der MSysObjects, aber nur den Namen und ein paar Attribute. Den Inhalt eines Formulars, seine Steuerelemente und deren Eigenschaften findest du in keiner Systemtabelle, diese Definitionen stecken im Formular selbst. Exportiere mal ein Formular mit der SaveAsText-Methode, dann bekommst du eine ungefähre Vorstellung davon.

Natürlich ist es mit der Referenztabelle eleganter, aber von deren Existenz war anfangs ja noch nicht die Rede. Außerdem muss sie erstmal erstellt und auch gepflegt (!) werden.

BTW:
Führende Nullen erzeugt man ganz einfach mit der Format-Funktion.

 

\@Maggie
Dank für deine Erläuterungen.

OK - von einer solchen Referenz-Tabelle war in meiner initialen Post nicht die Rede. Die Idee dazu kam mir erst später...

Prima. Natürlich. Ich denke nur, dass die Format-Funktion für so eine Aufgabe einfach zu mächtig ist, da sie ja immer interpretativ arbeiten muss. Mein simpler Trick mit einer Integer-Addition ist bestimmt schneller, denn während format den Format-String im eigenen Parser noch auf mögliche Inhalte analysiert, bin ich vermutlich schon fertig.

Sorry, aber ich komme aus einer Zeit, in der es noch wichtig war, Code zu optimieren, Rechenzeit einzusparen und String-Operationen möglichst zu vermeiden (garbage-collection). Mächtige Funktionen (wie hier Format) aufzurufen, ist vielleicht generell einfacher, aber mit meinem simplen Trick geht's eben auch und ich brauche nicht den gesamten internen Format-Overhead zu bemühen (Instanziieren, Daten laden, parsen, String zusammenbasteln, destructen, Heap aufräumen, Speicher freigeben...)

Du kannst ja mal einen kleinen Test bauen und die Ergebnisse hier posten.

Ich könnte meine 450 Felder vielleicht auch mit geschachtelten "wenn()" und mehreren bedingten Formatierungen zusammenschustern. Aber wo bleibt dann die Übersicht? Ich müsste für jedes einzelne Feld meiner form all das wiederholen. Da ist es doch mit absoluter Sicherheit besser, dies im VBA-Code zu tun, denn dann sehe ich, was passiert oder passieren soll und ich kann auch debuggen.

Eine kleine Aufgabe hätte ich da als Beispiel:
Ich habe in einer Tabelle sagen wir 30 Attribute als Wahr/Falsch-Felder. Diese Felder sollen in einem Formular als grüne oder rote Rechtecke dargestellt werden, jedes 0,2cm breit und alle in einer Zeile nebeneinander. Ich möchte in diesen Feldern aber keine abgeschnittenen Texte (Wahr oder Falsch) sehen, sondern einfach nur die Farben Rot oder Grün.
Wie würdest du das lösen?

Bin gespannt.

 

Hallo!

Als erstes würde ich überlegen, ob ich vielleicht einen Normalierungsschritt vergessen habe.
Falls ich das ausschließen kann, würde ich 30 Textfelder nutzen, und die Farbe über bedingte Formatierung einstellen. Über die Format-Eigenschaft der Textbox würde ich verhindern, dass ein Text angezeigt wird.
Ein Problem gibt es aber: das ist alles mit Access-Bordmitteln ohne VBA einstellbar. *wink.gif*


Falls ich es komplizierter machen wollte:
Eine Klasse für die Steuerelementformatierung und eine Container-Klasse die alle Steuerelemente aufnimmt. Im Formular wird dann über die Container-Klasse eine Instanz der Steuerelement-Formatierungs-Klasse erzeugt und die passende Textfeld-Referenz übergeben.
... das ist zwar im Vergleich zur Variante mit der bedingten Formatierung um einiges aufwendiger, aber dafür eine schöne Übung zum Gestalten von Klassen, wenn man die Schnittstelle sauber gestalten möchte.

mfg
Josef

 

Hallo,

das darf es in einer normalisierten Datenbank gar nicht geben.

 

\@Josef
Danke für deine Antwort.

Einen Normalisierungsschritt habe ich dabei bestimmt nicht vergessen. Ein Beispiel könnte ein Fragebogen sein oder vielleicht der DNA-Vergleich zweier Probanden oder die sensitive Beurteilung eines Produkts...
Textfelder zu nutzen ist schon mal gut, weil man sie auch an die Daten binden kann. Bei der bedingten Formatierung habe zumindest ich leichte Probleme, denn ich kriege den Text nich weg.

Also warte ich noch auf eine weitere Idee.

 

Hallo,

das sind aber eher Beispiele für klassische n:m Beziehungen und nicht für die Notwendigkeit von Ja/Nein Feldern.
Die sensitive Beurteilung eines Produkts über Ja/Nein Felder ist mit Sicherheit der falsch Weg. Wenn Du was anhakst hast Du ja eine feste Vorgabe zum Anhaken.
Demzufolge ist das eine n:m Beziehung mit 3 Tabellen.
- Produkt
- Eigenschaften (alle die möglich sind)
- Produkt_Eigenschaft (jeweils ein Datensatz, mit den zutreffenden Eigenschaften)

Kannst Du mal ein Bild der Beziehungen Deiner DB posten.

 

\@gpswanderer
OK - ich könnte in meinem gedachten Beispiel die 30 Felder auch sequentiell in einer zweiten Tabelle speichern. Dann wäre der Normalisierung genüge getan.
Aber ich möchte diese 30 Felder nebeneinander in einer Zeile darstellen. Und siehe da macht mir die strikte Normalisierung Probleme an der Darstellungs-Oberfläche.
Da ist es doch einfacher, die 30 Felder als Attribute in meiner Tabelle zu halten, weil sie dann schon 'horizontal' sind, oder?

Normalisierung ist OK, aber man muss dabei auch Möglichkeiten, Grenzen und Konsequenzen berücksichtigen.

 

\@gpswanderer
Auf den ersten Blick magst du ja recht haben. Aber wenn du dir vorstellst, dass bei einer Analyse immer genau 30 Parameter ja-nein-geprüft werden, ist es m. E. doch erheblich einfacher, diese Prüfungen un-normalisiert in der Tabelle zu speichern.

 

Darum schrieb ich, dass ich den Text mit der Format-Eigenschaft entfernen würde.

mfg
Josef