Unter oder Parent Formular als Klassenmodul initialisieren

[Milvus]

Hey Leute,

zur Überschrift, wie geht das?

So gehts nicht: Set MAFO = Me.Parent.Form

Ich habe in der Intellisense zwar die Formulareigenschaften, nicht aber meine Properties aus dem Klassenmodul.

Über New wirds ja auch nicht gehen, denn ich will eine Instanz auf ein konkretes Formular, nämlich das, welches sich innerhalb des anderen Formulars befindet.

Wisst, was ich meine?

Ich will im Klassenmodul eines Formulars x - in das ein 2. Formular y eingebunden ist - auf dessen Klassenmodul zugreifen.

[markusxy]

Die Frage ist nur als was du MAFO deklariert hast.
Du musst das natürlich mit der richtigen Klassen Angabe machen.

[Milvus]

Du meinst...

MAFO als die konkrete Formularklasse deklarieren und dann das Form der Variablen zuweisen, geht das?

Also so?:

private MAFO as Form_blabla

Set MAFO = Me.Parent.Form

Sind zwei verschiedne Dinge oder?

[markusxy]

@Milvus,
ja, so meine ich das.
Dann gibts dann auch funktionierende Intellisense.
Und wenn du dann statt.
MAFO!Feld

MAFO.Feld schreibst, schreit auch noch der Compiler bei nachträglichen Änderungen.
So kommt man dann zu halbwegs sicherem Code.

Daher würde ich auch immer von der Schreibweise Forms!Formular!Feld abraten und stattdessen eine Funktion verwenden die eine typsichere Referenz auf das Formular liefert.

[Milvus]

jepp, genau um diese Punkte geht es mir, sicherer Code.

Plan ist, alle neuen Forms von mir nur noch über die Klassen anzusprechen und auch die Kommunikation zwischen den Formularen nur über die Klassen und dort wiederum nur über die Publics laufen zu lassen, also wenn ich ein Feld brauche, richte ich ne Property ein, die den Wrt zum Feld liefert.

DoCmd will ich am besten ganz los werden, das ist zwar ein Alleskönner, führt aber meiner Meinung nach zu unsauberer Programmierung. Über die Klassen müsste eigentlich alles möglich sein.

Ich finde es etwas komisch, dass in Standardlehrbüchern DoCmd und DAO gelehrt werden. So beschäftigt man sich nicht wirklich damit, wie man es "besser" machen kann.

Für mich sind eigentlich nur ungebundene Formulare professionelle Lösungen. Direkt in die Tabellen zu schreiben,... naja. Aber auch das wird in der 1.Front nicht wirklich gelehrt. Bei mir gibt es einen Standardspeicherknopf, ggf. mit Validierung.

Mir ist aufgefallen, dass Access auch nicht wirklich so gut mit ungebundenen kann, da fehlt ein Stück weit das Dataset aus .Net, das ja eigentlich genau dafür geschaffen ist.

[MzKlMu]

Hallo,

Für mich sind eigentlich nur ungebundene Formulare professionelle Lösungen. Direkt in die Tabellen zu schreiben,... naja. Aber auch das wird in der 1.Front nicht wirklich gelehrt. Bei mir gibt es einen Standardspeicherknopf, ggf. mit Validierung.

Dem würde ich drastisch widersprechen wollen. Auch der Profi verschenkt nicht die einfachen Möglichkeiten die gebundene Formulare bieten.
Auch damit kannst Du einen Speichern Button mit Validierung realisieren. Und das noch viel einfacher wie mit ungebundenen Forms. Und die Daten sind auch nicht sofort in der Tabelle. Die sind sozuzsagen nur vorgemerkt. Die sind erst dann wirklich in der Tabelle, wenn ich explizit speichere, der Datensatz gewechselt wird oder das Form geschlossen wird. Die letzten beiden Punkte kann man wirksam verhindern um vorher eine Validierung durchzuführen.

Und, Du programmierst zu viel, entweder Sachen die man nicht braucht oder Sachen die Access von Haus aus besser kann.

Vieleicht solltet Du Dich doch erst mal mit Access beschäftigen bevor Du solche Aussagen machst.

[PhilS]

DoCmd will ich am besten ganz los werden, [...]

Ich finde es etwas komisch, dass in Standardlehrbüchern DoCmd und DAO gelehrt werden. [...]
Für mich sind eigentlich nur ungebundene Formulare professionelle Lösungen. [...]

[...] da fehlt ein Stück weit das Dataset aus .Net, das ja eigentlich genau dafür geschaffen ist.

Die oben gekürzt wiedergegebenen Punkte kann ich durchaus nachvollziehen.

Access ist eine Entwicklungsumgebung, die ...

a) einen deutlichen Schwerpunkt auf Anfänger und "Amateuere" in der Softwareentwicklung legt. Daher sind in Access viele Lösungswege vorgesehen (und werden dementsprechend auch in der Literatur propagiert), die möglichst einfach und mit eher geringen Vorkenntnissen zum gewünschten Ergebnis führen.


b) in den "verlorenen Jahren" 2010 bis 2016 von Microsoft in eine andere Richtung als die Desktop-Zielplattform getrieben worden. Dadurch ist ein erheblicher Rückstand gegenüber anderen Entwicklungsumgebungen entstanden, der von den gegenwärtig nur kleinen Entwicklerteam kaum aufgeholt werden kann.


Diese Sachverhalte sind für professionelle Entwickler nicht ideal. Es hält dich aber niemand davon ab, alternative Wege zu gehen.

Dabei solltest du aber immer die richtige Perspektive behalten. Wenn du eine hochgradig professionelle Entwicklung betreiben willst, macht dir Access vieles schwerer als es sein müsste.


Auf der anderen Seite sind aber Features, wie z.B. die Datenbindung auch ein großer Vorteil von Access, der schnell und einfach zu guten Lösungen führt. Mit alternativen Technologien, wie z.B. den genannten .Net Datasets, hast du wesentlich mehr Flexibilität, dafür gibt es aber bei der Umsetzung Lücken und Probleme im Detail bei der (Standard-)Usability, die du selbst erst ausbügeln musst.

[ebs17]

Bei Deinen geäußerten Bedenken und Vorlieben könnte man rückfragen, warum Du Dich überhaupt mit Access beschäftigst. Alles selber machen (.Net) käme Dir doch mehr gelegen.

Als Datenbank an sich gibt es auch bessere als ein Access-File-Backend.

[Milvus]

Vieleicht solltet Du Dich doch erst mal mit Access beschäftigen bevor Du solche Aussagen machst.

Das find ich jetzt etwas unverständlich. Ist ein Access Forum hier oder?
Wozu soll das gut sein, um sich nicht auszutauschen. Wollte niemand auf die Füße treten.

Für unvalidiertes Speichern sehe ich persänlich nur eine Anwendung in der Picklistenverwaltung in Hand eines Powerusers oder in Formularen, die an eine temporäre Datenquelle gebunden sind, bei der die Validerung nachgelagert ist.

Ja, (gebe ich gerne zu), ich wäge ab, ob Access für beistimmte Anwendungen überhaupt sinnvoll ist. Dafür tausche ich mich hier aus und die Rückmeldungen, die ich erhalte sind meistens sehr hilfreich.

[MzKlMu]

Hallo,
Du bist mir nicht auf die Füße getreten. Ich wollte mit meinen Hinweisen nur klar stellen, dass auch gebundene Formulare sehr Wohl die vollständige Kontrolle über die Daten erlauben. Auch ist eine Validierung möglich bevor die Daten in die Tabelle geschrieben werden.

Direkt in die Tabellen zu schreiben,... naja.

Auch gebundene Formulare schreiben nicht direkt in die Tabellen, wie oben bereits gesagt.
Daher meine Empfehlung sich mal mit Access zu beschäftigen um nicht die vielen guten Standard Funktion von Access ungenutzt zu lassen, die auch von Profis gerne genutzt werden. Und mit Access Profis meine ich nicht unbedingt mich selbst.

In einem anderen Forum hat mal einer der Access Profis (AEK Verfasser) gesagt:
"Er verwendet auch gebundene Formulare und behält trotzdem die Kontrolle über die Daten."

[ebs17]

Direkt in die Tabellen zu schreiben

Man darf auch fragen:
- Wohin, wenn nicht in Tabellen (bei einer Datenbank)?
- Warum nicht direkt und auf vorherige drei Weltumkreisungen verzichten?

>> Es ist ein Zeichen von Genialität, schwierige Dinge einfach zu machen.<<
Insofern sind Professionalität und Direktheit und Einfachheit eine hervorragende Kombination.

[Milvus]

Bin ich froh, nicht falsch verstanden zu werden

Ist mir durchaus bekannt, dass man in gebundenen Forms auch validieren kann. Blutiger Anfänger bin ich nicht. Hab ich auch schon mal gemacht, danach nie wieder auf dem Weg. Kommt auf die Komplexität der Validierung an, musste derart mit Events rumfummeln, bis das gepasst hat. Blööök!

Naja, ist vermutlich Geschmacksache. Bei mir gibt es einen Save-Button mit ner qualifizierten Rückmeldung, was nicht passt. Erst, wenn alle Schritte durch sind wird in die konkrete Tabelle übertragen.

Bei dem Thema, kennt sich da jemand mit Batchupdate aus?

Wenn ich einen bestimmten Pack Daten (z.B. mehr als einen Satz) in das RS lade und das fröhlich bearbeite. Wie krieg ich das auf elegantem Wege zurück in die Tabelle?

Oder geht das, was ich hier anspreche nur mit einem Dataset?

[MzKlMu]

Hallo,

musste derart mit Events rumfummeln,

Da braucht es nur ein Ereignis nämlich "Vor Aktualisierung" des Formulars. Da kann man alles erledigen.

Im Anhang findes Du ein einfaches Beispiel.

Bei mir gibt es einen Save-Button mit ner qualifizierten Rückmeldung, was nicht passt.

Ist in dem Beispiel auch drin.

[ebs17]

Interessiere Dich auch für Disconnected Recordset (ADODB).

Komplexität der Validierung: Bei einem einzelnen Datensatz einer Tabelle aus einem überschaubaren und geplanten Datenmodell (keine Abhängigkeiten von Werten innerhalb des Datensatzes) fehlt mir da etwas die Vorstellung.

[Milvus]

Interessiere Dich auch für Disconnected Recordset (ADODB).

Komplexität der Validierung: Bei einem einzelnen Datensatz einer Tabelle aus einem überschaubaren und geplanten Datenmodell (keine Abhängigkeiten von Werten innerhalb des Datensatzes) fehlt mir da etwas die Vorstellung.

Mir auch nicht unbekannt. Triggert mit Wenn und Dann und vielleicht...

https://docs.microsoft.com/de-de/office/vba/api/access.form.beforeupdate-event

Wie gesagt, ist Geschmacksache. Ich war damit irgendwie nicht zufrieden, weil es für mich nur einen Trigger gibt, das Speichern!