Access-o-Mania

Grundsätzlich werden in Endlosformularen neue Datensätze immer unten angefügt. Ich möchte aber neue Datensätze in der ersten Zeile eingeben können.
Dazu gibt es unter folgendem Link eine Beschreibung:
https://access-im-unternehmen.de/Neue_Datensaetze_oben_anfuegen/
Kennt jemand von euch noch eine einfachere/bessere Möglichkeit?

Günther

Zitat von: gsaccess am November 19, 2024, 08:22:39Kennt jemand von euch noch eine einfachere/bessere Möglichkeit?

Wiso?
Das Endlosformular kennt keine neuen Datensätze oben, also muss man sich entsprechend behelfen.
Die gezeigte Lösung ist doch sehr praktikabel.
Gruß Andi

Hallo,
eine Alternative wäre, das Formular zur Dateneingabe zu öffnen, dann gibt es nur den neuen leeren Datensatz, der dann logischerweise oben steht. Nach Speicherung des neuen Datensatzes (Formularereignis: Nach Aktualisierung) kann man ein Requery ausführen und die Dateneingabe wieder abschalten. Mit entsprechender Sortierung würde der soeben eingegebene neue Datensatz dann oben stehen.

Oder,
2.Alternative

Ungebundene Felder im Formularkopf. Nach dem Ausfüllen werden die ungebundenen Felder per Anfügeabfrage übertragen.
Vor dem Übertragen kann auch noch eine Validierung durchgeführt werden.

Hallo Günther,

was gefällt Dir denn nicht an der Lösung aus AIU.

Ich finde die doch recht verständlich dargestellt wie immer.

Gruß
Holger

Vielen Dank für eure Hilfe.
Ich habe nun die 2.Alternative von Klaus versucht umzusetzen.

Nach der Aktualisierung des Kombifeldes Offene Aufträge im Hauptformular soll der Curser im Naviunterformular auf das ungebundene Feld MAEingabe im Formularkopf springen.
Name des Hauptformulars:frmStunden
Name des Navigationsunterformulars:frmNaviStundenMaterialErfassen
Name des Steuerelements:MAEingabe
Mein Code
[/[Formulare]![frmstunden]![frmNaviStundenMaterialErfassen].[Form]!MAEingabe.SetFocus]
Dabei kommt folgende Fehlermeldung (Siehe Bild).

Wo habe ich hier einen Denkfehler?

Günther

Hallo Günther,

die Fehlermeldung sagt eigentlich alles: ... nicht gefunden.
Es ist gute Praxis, dem SubForm-Steuerelement und dem geladenen Formular unterschiedliche Präfixe zu vergeben. Bei der Referenzierung wird der Name des Unterformulars nicht verwendet, sondern nur der Name des Steuerelements!

Siehe auch:
http://access.mvps.org/access/forms/frm0031.htm (http://access.mvps.org/access/forms/frm0031.htm)

Hallo,
der in #4 gezeigte Code passt doch nicht zu ungebunden Feldern.
Die dort eingetragenen Daten müssen doch per Anfügeabfrage (oder über ein Recordset) an die TAbelle übertragen werden. Davon ist aber nichts zu sehen.

Bitte mal ausführlicher beschreiben.

Vielen Dank für die Antwort.
In der Anlage die Testdatei aus der mein Ansatz ersichtlich ist.
Im Formular "frmStunden" gibt es das Navigationsformular "frmNaviStundenMaterialErfassen" mit 4 Navibutton.
Im NavigationsbuttonStunden werden die Stunden erfasst.
Im Formularkopf sind die ungebundenen Felder. Beim Verlassen von UAZMinuten werden die Daten in die Tabelle Stunden geschrieben.
Das funktioniert soweit alles.
Was ich nicht schaffe:
Nach der Auswahl des Auftrages im Feld "cboOffeneAuftraege" sollte der Curser aber auf das Feld UMitarbeiter springen (siehe Bild).
Es soll der Mitarbeiter aus dem letzten Eintrag in der tblAuftragStunden übernommen werden.

Günther

Hallo Günther,

Warum verwendest du überhaupt ein Navi-Form?
Die sind doch sowas von schlecht zu händeln, - ein normales Register-Control
ist da doch deutlich angenehmer.

gruss ekkehard

Hallo Ekkehard,

Ich habe das Naviformular verwendet, da ich teilweise im Programm auch vertikale Register brauche und ich dies mit dem Register-Control nicht darstellen konnte. Dann habe ich im Programm die verschiedenen Controls.
Bei diesem Formular könnte ich aber auf das Register-Control umsteigen.
Dazu gleich die Frage, kann man die Registerkarten auch vertikal darstellen?

Gruss Günther

Hallo,

es gibt in Access kein natives TabControl mit vertikalen Tabs. Du kannst so etwas nur mit anderen Controls nachempfinden oder auf externe Komponenten zurückgreifen, z.B.
https://www.fmsinc.com/microsoftaccess/controls/components/tabs/index.html (https://www.fmsinc.com/microsoftaccess/controls/components/tabs/index.html)

Solange das Navi-Control deinen Ansprüchen genügt, kannst du das doch weiter verwenden, was spricht dagegen?

Meine favorisierte Variante ist einfach ein vertikales Menü-System aus Labels in Verbindung mit einem SubForm-Control, beides dynamisch verwaltet. Bisher konnten damit alle Workflows abgebildet werden.

Gruß
Knobbi38

Danke für eure Rückmeldungen.
@ Knobbi38
Das Navi-Control genügt grundsätzlich meinen Ansprüchen.
Mit den Komponenten in deinem Link komme ich noch nicht klar.
Werde mich aber schlau machen.

@ Klaus
Ich hoffe die in #7 übermittelte Testdatenbank klärt deine Anmerkungen auf

Zitat von: MzKlMu am November 20, 2024, 00:26:45Hallo,
der in #4 gezeigte Code passt doch nicht zu ungebunden Feldern.
Die dort eingetragenen Daten müssen doch per Anfügeabfrage (oder über ein Recordset) an die TAbelle übertragen werden. Davon ist aber nichts zu sehen.

Bitte mal ausführlicher beschreiben.

Noch unklar ist für mich warum der Code
[/[Formulare]![frmstunden]![frmNaviStundenMaterialErfassen].[Form]!MAEingabe.SetFocus]
die Fehlermeldung bringt.

Gruß Günther

Zitat von: gsaccess am November 21, 2024, 17:25:23Noch unklar ist für mich warum der Code
[/[Formulare]![frmstunden]![frmNaviStundenMaterialErfassen].[Form]!MAEingabe.SetFocus]
die Fehlermeldung bringt.

Dann hast du wohl meine Antwort aus #5 nicht gelesen und umgesetzt.

die Anwort habe ich gelesen.
hilft mir aber nicht weiter.
Ich lese unter diesem Link:
Me!Subform1.Form!Subform2.Form!ControlNameAlso muss doch das NaviUnterformular angesprochen werden?

Günther

Zitat von: gsaccess am November 22, 2024, 19:01:10Ich lese unter diesem Link:

Code [Auswählen] Erweitern

Me!Subform1.Form!Subform2.Form!ControlNameAlso muss doch das NaviUnterformular angesprochen werden?

Ich weiß nicht, auf welchen Link du dich genau beziehst. 
Ein genereller Hinweis auf ein häufiges Missverständnis: Es geht da um Steuerelemente! Subform1 und Subform2 sind die Namen der Unterformularsteuerelemente. Welches Formular da drin steckt, siehst du wenn du dir die SourceObject-Eigenschaft anschaust.

Danke für deine Hinweise. Ich denke mir das ist soweit klar.
Das Hautpformular: frmStunden
Darin ein Navigationsformular:frmNaviStundenMaterialErfassen
Darin das Naviunterformular mit 4 Buttons über die die verschiedenen Formulare aufgerufen werden.
zB frmAEStunden
In diesem Formular frmAEStunden gibt es das Steuerelement UMitarbeiter.
Da sollte eigentlich der Code:
Me.frmNaviStundenMaterialErfassen.Form!frmAEstunden.Form!UMitarbeiter.SetFocus
funktionieren.
frmAEstunden wird aber als Feld und nicht als Formular erkannnt.

Günther

Hallo Günther,

ich hatte doch geschrieben, daß jedes Unterformular-Steuerelement (das Control !!!) einen eindeutigen Namen bekommen sollte. Hast du das gemacht?

Also, nochmal Schritt-für-Schritt:
"frmStunden" enthält ein SubForm-Steuerelement. Dieses könntest du z.B. in "subContainer1" umbenennen und das darin geladene Formular ist "frmNaviStundenMaterialErfassen".
Um das geladene Unterformular anzusprechen, wäre der richtige Ausdruck:
Formulare!subContainer.Form
Dieses Unterformular enthält nun wiederum ein SubForm-Steuerelement, welches Access automatisch mit "Navigationsunterformular" benannt hat und das darin geladene Formular heißt "frmAuftragStunden".

Um nun in "frmAuftragStunden" die Kombobox "UMitarbeiter" anzusprechen, müßte der Ausdruck dann so sein:
Forms!subContainer1.form!Navigationsunterformular.form!UMitarbeiterForms und Formulare sind in diesem Kontext gleichwertig - Access benennt sich das selbständig um.

Man muß also nur konsequent die Hierarchie der Steuerelemente durchlaufen, wobei die Name der Formulare niemals benutzt werden!

Wie du siehst, hast du dir mit deiner inkonsistenten Namensgebung der Steuerelemente alles nur unnötig schwerer gemacht und die Lesbarkeit verschlimmbessert. Ein guter Programmierstil zeichnet sich auch durch eine stringente Namensgebung von Kontrols, Variablen und Funktionen aus und damit das andere auch noch lesen können, gibt es sogenannte Namenskonventionen (http://www.buch.andreasstern.de/Namenskonventionen-v401.pdf) (wird übrigens auch im Access-Tutorial (https://www.access-tutorial.de/namenskonventionen.htm) angesprochen).

Deine Datenbank test.accdb, was für ein aussagekräftiger Name ::) , solltest du dahingehend dringend überarbeiten und ob man designmäßig ein NavigationControl in einem Unter-Unterformular haben muß, darf doch stark bezweifelt werden. Hier stimmt dann einfach der Workflow nicht und alles wird unnötig erschwert. Formulare so zu überfrachten macht alles nur unhandlich.

Gruß
Knobbi38

Hallo Ulrich,
Ich denke das reicht nicht.
Wenn ich die Beschreibung richtig verstanden habe, sieht die Hierarchie
doch so aus

HFo enthält Naviform1Control
NaviForm1Control enthält Naviform1UFoControl
Naviform1UFoControl enthält NaviForm2Control
NaviForm2Control enthält Naviform2UFoControl
Naviform2UFoControl enthält das anzusprechende Form mit dem Zielfeld

da müsste dann die Referenz auf das Textfeld so aussehen (nicht getestet)

HFo.Controls("Naviform1Controlname").Form.Controls("NaviForm1UFoControlname").Form.Controls("Naviform2Controlname").Form.Controls("NaviForm2UFoControlname").Form.Controls("Textfeldname").Setfocus
Und dann bin ich mir mit Folgendem nicht sicher.
Früher musste man den Fokus zuerst auf das UFo-Control setzen bevor
man ein Control desselben fokussieren konnte.

gruss ekkehard

@Ekkehard

Ich habe mich exakt an die Beispiel-DB gehalten und daran den Ausdruck ausgerichtet. Zum Fokushandling hatte ich noch gar nichts geschrieben, aber ich meine auch, da zunächst das SubForm-Steuerelement den Fokus erhalten muß und dann das erst das Formular.

Es ist übrigens keine Textbox, sondern eine Kombobox und i.d.R. verwende ich in Ausdrücken nicht die Controls-Auflistung, sondern verwende explizit die Bang-Schreibweise, was einem "Late-Binding" entspricht. Damit habe ich zumindest bei Ausdrücken bessere Erfahrungen gesammelt, als mit der objektorientierten Schreibweise.

Grüße
Ulrich

Danke für eure Unterstützung. Ich bin aber im Naviformualar mit den obigen Verweisen nicht weitergekommen. Ich habe daher auf eine Registerformualar umgebaut.

Günther

Noch eine Frage an knoppi38

ZitatMeine favorisierte Variante ist einfach ein vertikales Menü-System aus Labels in Verbindung mit einem SubForm-Control, beides dynamisch verwaltet. Bisher konnten damit alle Workflows abgebildet werden.

Hast du das so gemeint, dass im Formular Schaltflächen eingesetzt werden und mit Unterformularen gearbeitet wird, die je nach Schaltfläche ein/bzw ausgeblendet werden.
Dann könnte ich mir die Probleme mit den Navi und Registerkarten Elementen sparen.

Günther

Hallo Günther,

richtig, in einem HF gibt es eine vertikale Leiste mit Labels und ein SubForm Steuerelement. Mit den Labels wird ein Menüsystem realisiert, welches die Daten dynamisch aus einer Tabelle bezieht und im SubForm Steuerelement wird dazu das jeweils benötigte Unterformular geladen. Das Ganze wird mit einer zentralen Klasse umgesetzt, welche die Menü-Requests entgegen nimmt, das aktuelle Unterformular entlädt und das neu angeforderte Unterformular nachlädt. Anschließend wir zu dem neuen Unterformular noch das dazu gehörende Menü geladen.

Funktioniert praktisch wie ein altes aufgebohrtes Switchboard, nur das jetzt alle Übersichtsseiten als Unterformulare geladen werden und die eingebetteten Makros durch VBA Code ersetzt worden sind.

Zumindest in ACC2010 konnte man noch den alten Übersichts-Manager im Ribbon aktivieren.

Gruß
Knobbi38

Nachtrag:
Hier der Link für den Übersichtsmanager:
https://learn.microsoft.com/de-de/office/troubleshoot/access/switchboard-manager-option-disappears (https://learn.microsoft.com/de-de/office/troubleshoot/access/switchboard-manager-option-disappears)

Hallo Knobbi38,

Danke für die ausführliche Erklärung. Ganz komme ich damit leider nicht klar.
Gibt es dazu ein kleines Beispiel, wie das umgesetzt wird.
Das mit dem Laden der Unterformulare funktioniert ja beim Registersteuerelement gleich. Siehe TestDB oben.
Select Case Me.mpgDaten.Value

Case Me.pagAuftrag.PageIndex
'Me.sfmAuftragDetail.SourceObject = "frmAEauftrag"
Me.frmAEAuftrag.Visible = True

Case Me.pagStunden.PageIndex
Me.sfmAuftragDetail.SourceObject = "frmAEStunden"
Me.frmAEAuftrag.Visible = False

Case Me.pagMaterial.PageIndex
Me.sfmAuftragDetail.SourceObject = "frmAEMaterial"
Me.frmAEAuftrag.Visible = False

Case Me.pagSonstiges.PageIndex
Me.sfmAuftragDetail.SourceObject = "frmAESonstiges"
Me.frmAEAuftrag.Visible = False

Case Else
MsgBox "keine gültige Auswahl getroffen"
Me.frmAEAuftrag.Visible = False

End SelectIst also der Hauptunterschied die vertikale Leiste, die Registersteuerelemente nicht abbilden können?
Oder habe ich das noch nicht verstanden.

Gruß
Günther

Hallo Günther,

vom Design her sieht es ähnlich aus, aber es wird tatsächlich nur ein HF mit zwei UFs verwendet, eins für die Darstellung des Menüs und ein anderes für die Anzeige der nachzuladenden Formulare. Man könnte auch mit einem auskommen, aber das Menüsystem ist als "benutzerdefiniertes" Steuerelement konzipiert, was aber für die Funktionalität egal sein sollte.

Seiten, wie sie es beim Registersteuerelement gibt, werden bei dieser Lösung nicht verwendet - es entspricht im Prinzip eher einem Registersteuerelement mit nur einer Seite. So ein Registersteuerelement mit nur einer Seite gibt wenig Sinn und kann damit auch gleich weggelassen werden.

Mit jeder neuen Menüauswahl wird, wie du das schon richtig erkannt hast, mit dem SubForm-Objekt per SourceObject ein neues Formular zugewiesen.

Das würde an sich schon reichen, aber so hätte man nur ein einstufiges Menüsystem. Will man etwas mehr haben, verlagert  man die einzelnen Aufgaben, wie die Verwaltung des konfigurierbaren Menüsystems und das Ent-/Neuladen mit Übergabe von Parametern in entsprechende Klassen, die dann die Arbeit im Hintergrund erledigen. 

Mit dem Beispiel wird das etwas schwieriger, weil das Bestandteil einer geschützten Anwendung ist. Anbei mal eine Switchboard-Demo, bei dem du erkennen kannst, wie ein tabellengesteuertes Menüsystem funktioniert; allerdings werden dabei noch die Formulare klassisch geöffnet und nicht in ein SubForm-Steuerelement geladen. Deshalb sagte ich ja: "aufgebohrtes" Switchboard.

Wenn du noch Fragen hast, einfach nochmal melden.

Gruß
Ulrich

Nachtrag:
Hier gab es das Thema schon mal und da sind auf ein paar Bilder:
https://ms-office-forum.net/forum/microsoft-access-datenbanken/microsoft-access/305614-formulare-aus-switchboard-in-unterformular (https://ms-office-forum.net/forum/microsoft-access-datenbanken/microsoft-access/305614-formulare-aus-switchboard-in-unterformular)

Hallo Ulrich,

vielen Dank für die ausführliche Erklärung und das Demobeispiel.
So ein Switchboard würde mir für die Formularverwaltung sehr gefallen.
Da muss ich mich aber intensiv mit der Materie auseinandersetzen.

Ich werd mal im Netz stöbern.

Gruß Günther

Hallo Ulrich,

Ich komme auch nach meinen Recherchen im Netz nicht wirklich weiter.
Daher folgende Fragen:
1) Muss ich nicht den Switchboard Manager in Access integrieren? Dieser ist bei mir nicht sichtbar.
2) Ist Switchboard eine Weiterentwicklung des Übersichtsmanagers bis Access 2010?
https://www.youtube.com/watch?v=qDhaotZmEmc (https://www.youtube.com/watch?v=qDhaotZmEmc)
3) Wie das in deiner Demo ohne Code funktioniert hängt ja mit der Tabelle SwitchboardItems zusammen. Zur Bedeutung der einzelnen Spalten in dieser Tabelle habe ich keine Beschreibung gefunden. Hast du dazu einen Link?

Gruß Günther

Hallo,

wie du den Übersichtsmanager in das Ribbon integrieren kannst, steht im Nachtrag zu #23. Du kannst ihn aber auch i Direktfenster mit
docmd.RunCommand acCmdSwitchboardManagerstarten.

Zu 2) Früher hieß das Switchboard-Manager und später Übersichtsmanager.

Zu 3)
Einen Link dazu habe ich nicht, aber mit den Makros erschließt sich das sehr schnell.

Um jetzt nicht alle eingebundenen Makros suchen zu müssen, gibt es einen Trick:
Öffne den Makro Editor und dann rechts im Aktionskatalog unter 'in dieser Datenbank'->'Formulare' findest du alle Formulare mit eingebundenen Makros. Die kannst du dann öffnen und eruieren. Auch wenn man sonst noch nicht mit Makros gearbeitet hat, kann man das eigentlich anhand der Namen und Aktionen gut nachvollziehen.
Wenn du ein einzelnes Makro in den Editor ziehst (Drag&Drop), kannst du es mit dem Tool 'Makros zu VBA konvertieren' in VBA Code konvertieren lassen. Ist manchmal kein elegante Code, aber immerhin. Zumindest könnte man den im Einzelschrittmodus besser durchgehen.

Gruß
Ulrich

Hallo Ulrich,

Es ist einfach toll wie schnell und fachlich fundiert ich hier Auskunft bekomme.
Vielen Dank für deine Hilfe. Ich werde mich mit Switchboard in nächster Zeit intensiv auseinandersetzen.
Ich werde versuchen es in meine Datenbank zu iplementieren.

Gruß
Günther