Filter auf Hauptformular

[SSSleep]

Hallo,
ich benötige noch einmal eure Hilfe. Ich versuche gerade über ein Unterformular die Filterung eines Hauptformulars zu steuern. Dabei dient das Unterformular als Menu-Leiste mit Schaltflächen. Das Betätigen einer Schaltfläche lenkt dann den Fokus, jeweils, auf ein Datensatz-Steuerelement im Hauptformular und öffnet das Filter-Menu. Aufruf aus dem Unterformular:

Code [Auswählen] Erweitern

DoCmd.RunCommand "Hafo_Steuerelementname"
DoCmd.RunCommand acCmdFilterMenu
Als Bestätigung, dass ein Filter ausgewählt wurde, wird sowohl das Sub Form_ApplyFilter(Cancel as Integer, ApplyType as Integer) des Hauptformulars, als auch das des Unterformulars aufgerufen. Da es der Zweck des Ganzen sein soll, den Filterbereich zu modularisieren und auch in anderen Formularen "einbetten" zu können, nutze ich dabei nur den Aufruf im Unterformular.

Soweit die Vorgeschichte, nun zu meinem Problem:

Zum Löschen aller Filter & Sortierungen gehe ich analog vor. Aufruf aus dem Unterformular:

Code [Auswählen] Erweitern

       
        DoCmd.GoToControl "irgendein_Hafo_Steuerelementname"  
        With Me.parent
            If Not .Filter = "" Then
                DoCmd.RunCommand acCmdRemoveAllFilters
            ElseIf Not .OrderBy = "" Then
                DoCmd.RunCommand acCmdRemoveAllSorts
            End If
        End With     

Jetzt aber wirklich zu meinem Problem. Während DoCmd.RunCommand acCmdRemoveAllFilters ebenfalls sowohl das Sub Form_ApplyFilter(Cancel as Integer, ApplyType as Integer) in Haupt-und Unterformular aufruft, ruft DoCmd.RunCommand acCmdRemoveAllSorts nur noch das ApplyFilter Sub des Hauptformulars auf.
Das leuchtet mir zwar nicht ein, aber vermutlich wird sich daran auch nichts ändern lassen. Meine Frage ist nun, ob mein Ansatz einfach nicht gut ist und ob es elegantere Lösungen zur Modularisierung eines Filterbereichs gibt, ohne dabei den Weg über Unterformulare zu gehen.

Vielen Dank euch für die Hilfe

[Beaker s.a.]

Hallo,
1. wenn du nicht noch mit einer älteren Version als A2K arbeitest,
solltest du dich von .RunCommand verabschieden. Die meisten Objekte
in Access stellen inzwischen eigene Eigenschaften und Methoden zur
Verfügung; - musst du mal googlen.
Beispiel

Code [Auswählen] Erweitern

DoCmd.GoToControl "irgendein_Hafo_Steuerelementname"   ist besser

Code [Auswählen] Erweitern

Me.Parent.Controls("irgendein_Hafo_Steuerelementname").SetFocus2. kann man (ich) aus den Codefragmenten den genauen Ablauf nicht erkennen, -
bist du den Code mal im Einzelschrittmodus durchgegangen und hast die
Variablen und Bedingungen überprüft?

gruss ekkehard

[SSSleep]

Hallo,
1. wenn du nicht noch mit einer älteren Version als A2K arbeitest,
solltest du dich von .RunCommand verabschieden. Die meisten Objekte
in Access stellen inzwischen eigene Eigenschaften und Methoden zur
Verfügung; - musst du mal googlen.
Beispiel

Code [Auswählen] Erweitern

DoCmd.GoToControl "irgendein_Hafo_Steuerelementname"  ist besser

Code [Auswählen] Erweitern

Me.Parent.Controls("irgendein_Hafo_Steuerelementname").SetFocus

..ok nehme ich mal so mit...schadet ja für den Focus nicht und wird besser lesbar. Nach meiner googelei ist allerdings das Filter Menu ausschließlich über .RunCommand acCmdFilterMenu zu erreichen.

2. kann man (ich) aus den Codefragmenten den genauen Ablauf nicht erkennen, -
bist du den Code mal im Einzelschrittmodus durchgegangen und hast die
Variablen und Bedingungen überprüft?

ja, die Sortierung wird sogar entfernt. Allerdings erfolgt er Aufruf des besagten Subs nicht. Ich lasse mir in beiden Sub Form_ApplyFilter(Cancel as Integer, ApplyType as Integer) des Hafo und Ufo ein Debug.Print erzeugen und sehe, dass im Fall von DoCmd.RunCommand acCmdRemoveAllSorts nur die Debug Message des Sub aus dem Hauptformular abgesetzt wird.

Bei DoCmd.RunCommand acCmdRemoveAllFilters wird erst das Sub des Hauptformulars durchlaufen, dann das des Unterformulars.

[Beaker s.a.]

Kann die Abläufe leider nicht abstrahieren, - lade eine Beispiel-DB hoch.

[SSSleep]

Kann die Abläufe leider nicht abstrahieren, - lade eine Beispiel-DB hoch.

...done:
Sie dürfen in diesem Board keine Dateianhänge sehen.

Bei dem angefügten Beispiel verhält sich der Event-Handler wieder anders. Auch beim Löschen des Filters wird die Ereignisprozedur im Unterformular nun nun nicht aufgerufen. Ich kann aber auch nicht erkennen, wo der Unterschied zu meiner Arbeitsversion ist.

Vermutlich müsste ich dem Event-Handler mitteilen, dass er eine Prozedur im Unterformular aufrufen soll?

[Beaker s.a.]

@SSSleep
Manchmal hat man echt ein Brett vor'm Kopf. Die Frage hätte
ich auch ohne Beispiel beantworten können müssen. 
Die Zeile

Code [Auswählen] Erweitern

            DoCmd.RunCommand acCmdRemoveAllSortswird ja durch das ElseIF nur ausgeführt wenn der Filter leer ist

Code [Auswählen] Erweitern

        If Not .Filter = "" ThenAlso

Code [Auswählen] Erweitern

     With Me.Parent
        If Not .Filter = "" Then
            DoCmd.RunCommand acCmdRemoveAllFilters
        End If
        If Not .OrderBy = "" Then
            DoCmd.RunCommand acCmdRemoveAllSorts
        End If
        Me.status.Visible = False    'hattest du vergessen
    End With
gruss ekkehard

[SSSleep]

Hallo ekkehard,

stimmt, das war ein Fehler, vielen Dank. Ich habe es gleich geändert.

 

Me.status.Visible = False    'hattest du vergessen

Vergessen eigentlich nicht. Zugegeben, das Zurücksetzen an der Stelle wäre ein möglicher workaround. Wie im Beispiel gezeigt, habe ich eigentlich angestrebt den Status erst im Form_ApplyFilter() zurückzusetzen, weil ich mit diesem Aufruf die größere Sicherheit habe, dass der Aufruf auf Filter & Sortierung angewendet wurde.

Mittlerweile wurmt es aber auch, dass ich den Aufruf der Ereignisprozedur offenbar nicht verstehe.

Hast du in meinem Beispiel die Unterschiede beim Aufruf von Form_ApplyFilter() feststellen können? 

[Beaker s.a.]

@SSSleep

Vergessen eigentlich nicht. Zugegeben, das Zurücksetzen an der Stelle wäre ein möglicher workaround

Wieso "Workaround"? Das passiert doch genau an der Stelle nachdem Filter
und Orderanweisung entfernt wurden.
Bezügl. Reihenfolge der Ereignisse kann ich dir nicht helfen. Hauptsächlich
weil ich mit dem Ereignis "_ApplyFilter" noch nie auseinander gesetzt habe,
- ich habe da bis jetzt andere Vorgehensweisen gelernt.
Vor Allem frage ich mich wozu du da extra ein UFo mit der gleichen DS-Herkunft
wie das HFo verwendest. Die drei Controls kannst du doch auch gleich im Formular-
kopf unterbringen.

gruss ekkehard

[SSSleep]

Wieso "Workaround"? Das passiert doch genau an der Stelle nachdem Filter
und Orderanweisung entfernt wurden.

naja, aus meiner Perspektive schon. Es war ja mein ursprüngliches Ziel, es in der Ereignisprozedur zum ApplyFilter unterzubringen. Aber ja, ich habe ja auch nach alternativen gefragt, das ist sicher eine.
Da der Status auch in der Ereignisprozedur ApplyFilter() gesetzt wird, möchte ich auch gerne das Rücksetzten dort platzieren, um den Code zusammenzuhalten. 

Bezügl. Reihenfolge der Ereignisse kann ich dir nicht helfen. Hauptsächlich
weil ich mit dem Ereignis "_ApplyFilter" noch nie auseinander gesetzt habe,

Hast du denn evtl. einen Ansatz, wie ich das Ereignis im Hauptformular auf eine andere Funktion im Unterformular umleiten kann? Ich habe

Code [Auswählen] Erweitern

Forms(Me.Parent.Name).OnApplyFilter = "=test()"versucht und eine gleichnamige Funktion im Unterformular zur Verfügung gestellt. Gibt aber nur Meldungen.

Vor Allem frage ich mich wozu du da extra ein UFo mit der gleichen DS-Herkunft
wie das HFo verwendest. Die drei Controls kannst du doch auch gleich im Formular-
kopf unterbringen.

Das hatte ich aber in meinem ersten Post erklärt:

Da es der Zweck des Ganzen sein soll, den Filterbereich zu modularisieren und auch in anderen Formularen "einbetten" zu können, nutze ich dabei nur den Aufruf im Unterformular.

Die angefügte Datei war nur ein Beispiel. Der eigentliche Filterkopf ist etwas umfangreicher und soll für mehrer Formulare gelten. Bei Änderungen am Filter möchte ich nicht in mehreren Formularen die gleiche Änderungen mehrfach nachpflegen müssen, sondern nur einmal, zentral, im Unterformular.

[SSSleep]

Wieso "Workaround"? Das passiert doch genau an der Stelle nachdem Filter
und Orderanweisung entfernt wurden.

...jetzt ist mir auch wieder eingefallen, warum mir diese Lösung nicht so behagt. Das Filtermenu selbst bietet ebenfalls die Möglichkeit den Filter zu löschen:

(irgendwie wird der screenshot nicht angezeigt)...hier der Link:
https://www.bilder-upload.eu/thumb/c61095-1600928166.png

Diese Auswahl bekomme ich aber nur dann mit, wenn ich im Ereignis ApplyFilter auf den Inhalt des Filters schaue.

[Beaker s.a.]

Hallo,
Letzter Post zuerst

Das Filtermenu selbst bietet ebenfalls die Möglichkeit den Filter zu löschen:

Aber wozu sollte ich die nutzen, wenn es doch einen Reset-Button gibt?

Da der Status auch in der Ereignisprozedur ApplyFilter() gesetzt wird, möchte ich auch gerne das Rücksetzten dort platzieren, um den Code zusammenzuhalten. 

Dann mache es doch, und da geht auch das Setzen mit der gleichen Zeile

Code [Auswählen] Erweitern

'HFo
Private Sub Form_ApplyFilter(Cancel As Integer, ApplyType As Integer)
        Me.status.Visible = (Not Me.Filter = "")
End Sub

Ereignis im Hauptformular auf eine andere Funktion im Unterformular umleiten kann

Welches?
Ereignisse stösst man nicht per Code an, da kannst du böse Überraschungen
erleben. Dazu schreibt man eine, von Ereignissen unabhängige Prozedur (Sub/
Function) und ruft diese auf

Code [Auswählen] Erweitern

Private Sub ...
    Call DeineProzedur
'Call kann man auch weglassen, ich finde es aber lesbarer
End SubSowas brauchst du hier aber gar nicht.

den Filterbereich zu modularisieren und auch in anderen Formularen "einbetten" zu können

Dann lösche als Erstes mal die DS-Herkunft im UFo. Die ist so nützlich wie ein Kropf,
und es entfällt die zusätzl. Filterung. Dann gebe dem Control einen anderen Namen
als dem Formular; - ich habe es jetzt "subcontrol_frm_filter" getauft (s. Anhang).
Was mich interessieren würde, - wie willst du das parametrisieren?

Vielleicht schaust du dir in dem Zusammenhang auch mal Christians Filterklasse CCFilterV2_7 an.

gruss ekkehard

[SSSleep]

Du bist schon älteres Semester, oder?...ü60?

[SSSleep]

Du bist schon älteres Semester, oder?...ü60? ,,aber irgendwie immer gerne seinen Senf dazugeben" beschreibt es schon ganz treffend

[Beaker s.a.]

Jau, Baujahr 1954.