Access-o-Mania

Hallo zusammen,

ich habe eine Frage zum Navigationssteuerelement in Kombination mit der BrowseTo-Methode. Ich benutze Access 2013.

Ich habe ein Hauptformular ("frmPersonEinzeln"). Dies enthält ein Navigationssteuerelement ("NavigationsInhalt") mit mehreren eingebundenen Formularen, u.a. das "ufoPersonKontoAnzeige".

Wenn ich das Hauptformular ansteuere, möchte ich gerne direkt den "passenden" Reiter anzeigen, je nach dem, woher ich gerade komme. Vom Hauptformular selbst kann ich den Reiter mit DoCmd.BrowseTo ansteuern. Das sieht bei mir so aus:

DoCmd.BrowseTo ObjectType:=acBrowseToForm, _
ObjectName:="ufoPersonKontoAnzeige", _
PathtoSubformControl:="frmPersonEinzeln.NavigationsInhalt", _
WhereCondition:="perID = [Formulare]![frmPersonEinzeln]![txtIdTeilnehmer]", _
Page:="cmdNavKonto"


Wenn ich aber von einem anderen Formular aus dorthin browsen möchte, kann ich diese Methode dann überhaupt von dort aus benutzen? Ich bekomme jedesmal den Fehler:

ZitatLaufzeitfehler '6054':
Die WechselnZu-Makroaktion erfordert ein gültiges Pfad-Argument. Ein gültiges Pfad-Argument hat folgende Form:
Hauptformular1.Unterformular1>Formular1.Unterformular1

Ich fummle seit Tagen erfolglos am PathtoSubformControl rum und blick's einfach nicht. Bin ich da vielleicht völlig auf dem falschen Dampfer und BrowseTo funktioniert nur innerhalb des Formulars mit dem Navigationssteuerelement?

Und ganz wichtig: Wie löst man so etwas in "richtig und schön"? (Ich hab gelesen, dass das Navigationssteuerelement nicht besonders beliebt ist, aber mir ist die Alternative nicht klar.)

Vielen Dank für Eure Hilfe!
Irene             

Hallo,

ZitatIch bekomme jedesmal den Fehler:

was genau löst den Fehler aus? Zeige bitte den Code dazu.

Zitatund BrowseTo funktioniert nur innerhalb des Formulars mit dem Navigationssteuerelement?

Klar, d.h. das Navigationsformular muss natürlich geöffnet sein.

ZitatIch hab gelesen, dass das Navigationssteuerelement nicht besonders beliebt ist

Die traditionelle Alternative ist ein Formular mit Registerkarten.

Was mich betrifft, so habe ich grundsätzlich nichts gegen die neuen Features, man muss nur damit umgehen können. Wer sich nicht damit beschäftigen will, sollte wohl besser bei den herkömmlichen Verfahrensweisen bleiben.

Hallo MaggieMay,

schön, dass Du geantwortet hast!  :)

Zitatwas genau löst den Fehler aus? Zeige bitte den Code dazu.

Ich habe mir einen Button auf einem separaten Formular gebastelt; bei Klick auf den Button soll das offene Formular "frmPersonEinzeln" (das ist das mit dem Navigationssteuerelement) angesteuert werden. Der Code sieht so aus:

Private Sub test_Click()
DoCmd.BrowseTo ObjectType:=acBrowseToForm, _
ObjectName:="ufoPersonKontoAnzeige", _
PathtoSubformControl:="frmPersonEinzeln.NavigationsInhalt", _
WhereCondition:="perID = " & Me!txtPerIDRef, _
Page:="cmdNavKonto"
End Sub

Und da kommt dann die genannte Fehlermeldung.

ZitatKlar, d.h. das Navigationsformular muss natürlich geöffnet sein.

Das Navigationsformular ist dabei geöffnet. Meine Frage, wo BrowseTo funktioniert, zielte darauf, dass ich es zwar innerhalb des Navigationsformulars verwenden kann, um vom Hauptformular auf die einzelnen Navigationselemente zu kommen. Aber von diesem anderen Formular aus funktioniert es nicht. Das konnte meiner Ansicht nach
a) am Pfad oder
b) an der Verwendbarkeit von BrowseTo
liegen. Was Du schreibst, klingt danach, dass man BrowseTo von überall aus verwenden kann. Nur wie formuliere ich den PathtoSubformControl richtig? Ich hab es auch mit "Forms!frmPersonEinzeln.NavigationsInhalt" probiert, mit dem eingebundenen Formular direkt, mit dem Steuerbutton, aber das ist ja alles auch verkehrt. Argh...

ZitatDie traditionelle Alternative ist ein Formular mit Registerkarten.

Über das Formular mit Registerkarten habe ich auch nachgedacht. Aber ist es da nicht so, dass beim Laden direkt alle Inhalte der verschiedenen Registerkarten geladen werden? Da auf jeder Unterseite jeweils noch ein Endlosformular sitzt, würde das  die Sache vermutlich etwas verlangsamen.

ZitatWas mich betrifft, so habe ich grundsätzlich nichts gegen die neuen Features, man muss nur damit umgehen können. Wer sich nicht damit beschäftigen will, sollte wohl besser bei den herkömmlichen Verfahrensweisen bleiben.

Mein Hauptproblem ist, dass ich mich wahnsinnig gerne in die Funktionsweise des Elements einarbeiten möchte, aber es fehlt mir einfach an aussagekräftiger Literatur. Hölscher im Access-Handbuch erklärt lediglich, wie man es anlegt, aber nichts mit VBA. Doberenz/Gewinnus verwenden immerhin 2 1/2 Seiten darauf, nennen aber nur die Navigationsmöglichkeiten innerhalb der einzelenen Unterformulare des Navigationsformulars. Garcia im VHS-Skript vom Herdt-Verlag kennt das Feature
(noch) nicht. Ebenso Leibing/Held in Access-VBA. Die Microsoft-Onlinehilfe ist sicher gut, wenn man das Grundprinzip verstanden hat. Kannst Du mir eine Quelle empfehlen, die das Ding erschöpfend beschreibt?

(Ich habe ziemlich viel Zeit verloren, indem ich es zuerst mit dem Registersteuerelement verwechselt habe, um darauffolgend daran zu scheitern, dass ich die eingebundenenen Formulare als normale Unterformulare ansprechen wollte, was auch nicht ging. Jetzt brauche ich solide Fakten.)
Sorry für den Sermon, es ist gerade wahnsinnig frustrierend.

Dennoch optimistische Grüße
Irene

Hallo,

Es stellt sich die Frage: Warum so?

ZitatWenn ich aber von einem anderen Formular aus dorthin browsen möchte, kann ich diese Methode dann überhaupt von dort aus benutzen?

Ja, aber das sprengt die erwünschte Kapselung des Formulars (--> Klassenmodul) und kann zu unangenehmen Folgeerscheinungen führen..

Zudem ist ein Formular keine Website, in der man mit URLs/Links "browsen" kann, auch wenn der Makroname sowas vermuten läßt.

Trotzdem eine (vermutlich funktionierende) Lösung:

Ereignisprozedur als Public deklarieren:

Public Sub test_Click()
DoCmd.BrowseTo ....
.
.
End Sub


im "anderen Formular" in einer passenden Ereignisprozedur:

ZitatPrivate Sub btnButton_Click()
Forms!frmPersonEinzeln.test_Click
End Sub

Evtl. benötigte Kriterienwerte über Public-Variablen setzen.

Hallo,

ich möchte hier noch einmal einhaken:

ZitatLaufzeitfehler '6054':
Die WechselnZu-Makroaktion erfordert ein gültiges Pfad-Argument. Ein gültiges Pfad-Argument hat folgende Form:
Hauptformular1.Unterformular1>Formular1.Unterformular1

Kann es sein, dass du beim Abschreiben Schreibfehler gemacht hast?
Zeige doch bitte noch einmal die Original-Fehlermeldung.

PS:
Der Text scheint zu stimmen, ich verstehe allerdings nicht, was das für eine Syntax sein soll:
Hauptformular1.Unterformular1>Formular1.Unterformular1

Hallo MaggieMay,

ZitatDer Text scheint zu stimmen, ich verstehe allerdings nicht, was das für eine Syntax sein soll:

das beruhigt mich ein bisschen, dass Du die Syntax dieses Pfad-Argument-Schemas auch komisch findest. Es scheint aus der automatischen Übersetzung zu resultieren, hier taucht es auch auf:
https://msdn.microsoft.com/de-de/library/office/ff196381.aspx

Hallo Franz,
danke für Deine Tipps, es wird langsam heller hier!  :)

ZitatEs stellt sich die Frage: Warum so?

Sehr berechtigte Frage, die ich mir auch gestellt habe. Bzw. "Kann das so gemeint sein?" Ich dachte, es wäre die passende Methode für diesen Anwendungsbereich, aber anscheinend ist sie es nicht. Offenbar hab ich da zu sehr in Web-Kategorien gedacht.

Verstehe ich Deinen Hinweis auf die Kapselung richtig, dass ich grundsätzlich allesalles im betreffenden Formular selbst regeln soll, damit ich es unabhängig von seiner Umgebung benutzen kann? Dann streiche ich das BrowseTo für diesen Fall direkt von meiner Liste, ist dann ja völliger Humbug.

Dann würde ich also in Zukunft (je nach Anwendungsfall) grundsätzlich so vorgehen:
- entweder OpenForm in Kombination mit den OpenArgs (damit das Formular weiß, wo ich herkomme),
- oder die benötigten Subs von außen ansteuerbar machen, indem ich sie als Public deklariere und sie dann von Ferne auslöse.

Habe ich Dich bzw. Euch da richtig verstanden, ist das das Grundkonzept, wie man sauber von Formular zu Formular kommt? Oder bin ich -wieder- auf dem Holzweg?

Ich find's super, dass Ihr mir helft, danke nochmal!
Einen schönen Abend wünscht
Irene

Hi,

Die Browseto-Methode, bzw. Makro kann sicherlich innerhalt eines (Navi-) Forms benutzt werden...Mein Einwand bezieht sich darauf, von einem zweiten  Formular heraus auf die Methoden oder Prozeduren des ersten Forms zuzugreifen.

Zitatdie benötigten Subs von außen ansteuerbar machen, indem ich sie als Public deklariere und sie dann von Ferne auslöse.

Eben nicht so...  Die Subs (Ereignisprozeduren) sind "Eigentum" des jeweiligen Forms und nicht umsonst Private deklariert.  Wenn Prozeduren allen Objekten zur Verfügung stehen sollen, dann in ein Standard-Modul platzieren und von dort aufrufen, wo sie gebraucht werden.

Hallo Else,

ZitatÜber das Formular mit Registerkarten habe ich auch nachgedacht. Aber ist es da nicht so, dass beim Laden direkt alle Inhalte der verschiedenen Registerkarten geladen werden? Da auf jeder Unterseite jeweils noch ein Endlosformular sitzt, würde das  die Sache vermutlich etwas verlangsamen.

Das hat mit Registern nichts zu tun, es werden normal immer alle Daten beim Öffnen eines Forms geladen. Und gerade da bieten Register eben die Möglichkeit das zu "verhindern", indem die Inhalte von UFos erst beim Wechsel zur entsprechenden Registerkarte geladen werden.
Private Sub Registerelement_Change()
    Select Case Me.Controls("Registerelement").Value
        Case Me.Controls("Registerelement").Pages("ErsteKarte").PageIndex
            Me.Controls("ErstesUFo").Form.RecordSource = "Abfrage1"
        Case Me.Controls("Registerelement").Pages("ZweiteKarte").PageIndex
            Me.Controls("ZweitesUFo").Form.RecordSource = "Abfrage2"
    End Select
End Sub
Die Datenherkunft der UFos muss dazu leer sein.
Ich persönlich finde dieses Navi-Element auch ziemlich daneben. Ist doch ein elendiges Gefrickel sich durch den "Objektbaum" zu hangeln. Ist da doch so, dass jedes darauf plazierte "HFo" ein UFo ist, und jedes darauf gesetzte UFo ein UFoUfo ist, also drei Ebenen.
Ist doch deutlich einfacher gleich die globale Einstellung "Dokumente im Registerkartenformat" zu verwenden.
gruss ekkehard

Hallo,

"... daneben ..."

In der Tat, das Ding hat ,bis auf die Möglichkeit der Einstellung der Reiter-Platzierung, keinen praktischen und theoretischen Vorteil....

Hi Franz,
danke für Deine Erklärungen, ich verstehe jetzt besser, was mit der Kapselung der Formulare gemeint ist und warum sie so wichtig ist. Wenn die gemeinsam benutzten Prozeduren ins Standardmodul kommen, dann wird auch alles viel übersichtlicher und klarer. Ich hab jetzt auch den Aufsatz von Pötzl zum Thema gefunden, hoffe also, Euch bleiben solche Fragen von mir künftig erspart.

Hallo Ekkehard,
danke für Deine Einschätzung und Deine Tipps! Wenn immer alle Daten geladen werden, dann kann ich ja auch das Registersteuerelement nehmen und die Ufos beim Kartenwechsel laden. Ich dachte, das sei genau das, was das Navigationssteuerelement täte. Ich werde mir die Sinnhaftigkeit seiner Verwendung für meine Zwecke nochmal durch den Kopf gehen lassen.

Viele Grüße und danke nochmal!
Irene

Hallo,

Zitatund die Ufos beim Kartenwechsel laden. Ich dachte, das sei genau das, was das Navigationssteuerelement täte.

genau so ist es, aber das kann man ja auch ebensogut selbst so anlegen und alles läuft unter eigener Regie.

...und man braucht sich nicht mit der Syntax und Wirkungsweise neuer Befehle zu beschäftigen.  ;D

Hallo MaggieMay,
aha! Ich höre unterschiedliche Glaubensrichtungen leise trapsen... :-D
Danke nochmal!
Irene