Endlosformular - Neuer Datensatz oben

[gsaccess]

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:

Code [Auswählen] Erweitern

Me.frmNaviStundenMaterialErfassen.Form!frmAEstunden.Form!UMitarbeiter.SetFocus
funktionieren.
frmAEstunden wird aber als Feld und nicht als Formular erkannnt.

Günther

[Knobbi38]

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:

Code [Auswählen] Erweitern

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:

Code [Auswählen] Erweitern

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 (wird übrigens auch im Access-Tutorial 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

[Beaker s.a.]

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)

Code [Auswählen] Erweitern

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

[Knobbi38]

@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

[gsaccess]

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

[gsaccess]

Noch eine Frage an knoppi38

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.

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

[Knobbi38]

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

[gsaccess]

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.

Code [Auswählen] Erweitern

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

[Knobbi38]

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

[gsaccess]

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

[gsaccess]

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
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

[Knobbi38]

Hallo,

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

Code [Auswählen] Erweitern

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

[gsaccess]

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