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:
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:
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
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
DoCmd.GoToControl "irgendein_Hafo_Steuerelementname" ist besser
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
Zitat von: Beaker s.a. am September 22, 2020, 12:21:05Hallo,
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
DoCmd.GoToControl "irgendein_Hafo_Steuerelementname" ist besser
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.
Zitat von: Beaker s.a. am September 22, 2020, 12:21:052. 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.
Kann die Abläufe leider nicht abstrahieren, - lade eine Beispiel-DB hoch.
Zitat von: Beaker s.a. am September 22, 2020, 14:16:49Kann die Abläufe leider nicht abstrahieren, - lade eine Beispiel-DB hoch.
...done:
datenbank_test_filter.zip
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?
@SSSleep Manchmal hat man echt ein Brett vor'm Kopf. Die Frage hätte
ich auch ohne Beispiel beantworten können müssen. :o
Die Zeile
DoCmd.RunCommand acCmdRemoveAllSortswird ja durch das ElseIF nur ausgeführt wenn der Filter leer ist
If Not .Filter = "" ThenAlso
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 Withgruss ekkehard
Hallo ekkehard,
stimmt, das war ein Fehler, vielen Dank. Ich habe es gleich geändert.
Zitat von: Beaker s.a. am September 23, 2020, 12:34:31Me.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?
@SSSleep ZitatVergessen 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
Zitat von: Beaker s.a. am September 23, 2020, 14:25:11Wieso "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.
Zitat von: Beaker s.a. am September 23, 2020, 14:25:11Bezü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
Forms(Me.Parent.Name).OnApplyFilter = "=test()"versucht und eine gleichnamige Funktion im Unterformular zur Verfügung gestellt. Gibt aber nur Meldungen.
Zitat von: Beaker s.a. am September 23, 2020, 14:25:11Vor 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:
Zitat von: SSSleep am September 22, 2020, 08:53:05Da 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.
Zitat von: Beaker s.a. am September 23, 2020, 14:25:11Wieso "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.
Hallo,
Letzter Post zuerst
ZitatDas 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?
ZitatDa 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
'HFo
Private Sub Form_ApplyFilter(Cancel As Integer, ApplyType As Integer)
Me.status.Visible = (Not Me.Filter = "")
End SubZitatEreignis 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
Private Sub ...
Call DeineProzedur
'Call kann man auch weglassen, ich finde es aber lesbarer
End SubSowas brauchst du hier aber gar nicht.
Zitatden 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 (http://www.ccedv.de/downloads/php/downloads.php?lang=de) an.
gruss ekkehard
Du bist schon älteres Semester, oder?...ü60?
Du bist schon älteres Semester, oder?...ü60? ,,aber irgendwie immer gerne seinen Senf dazugeben" beschreibt es schon ganz treffend
Jau, Baujahr 1954.