Office: (Office 2016) Automatische Auswahl in einem Kombinationsfeld durch die Auswahl in einem Anderen

Hallo miteinander,

entschuldigt der lange Titel, ich wusste nicht wie ich das nennen sollte.
Mein Problem ist folgendes: Ich habe ein Formular mit Kunden und Produkten. Ich kann in einer ListBox die Kunden auswählen und in einem Kombinationsfeld dann die dazugehörigen Produkte sehen und auswählen. Dann bekomme ich weitere zusatzinfos angezeigt.
Jetzt möchte ich auch die Möglichkeit haben nach den Produkten zu filtern. Gelöst habe ich das mit einem Kombinationsfeld und das funktioniert auch soweit.
Es werden mir dann nur die Kunden in der ListBox angezeigt, die auch das Produkt haben.
Jetzt ist aber Blöd, dass wenn ich dann auf einen Kunden gehe, ich weiterhin alle Produkte angezeigt bekomme und das Produkt nach dem ich gefiltert habe nicht aktiviert ist.
Gibt es eine Möglichkeit per VBA zu sagen, dass wenn ich nach Produkt gefiltert habe, dieses auch automatisch "angeklickt" wird wenn ich einen Kunden auswähle und so direkt alle weiteren Zusatzinfos angezeigt werden?
Ich hoffe Ihr könnt mir hierzu helfen *Smilie

Liebe Grüße
Dodanator

:)

 

Wahrscheinlich überschreibt der zweite Filter den ersten. Zeig mal wie du filterst.

 

Schreibst du in der zugrunde liegenden Abfrage für das Feld in dem die Produkte stehen nicht im IDFeld von Kunden

Code:

Dann werden im ZB listenfeld nur mehr die passenden Artikel angezeigt
Geht auch in VBA ist aber komplexer, da müsstest die Datenbank hochladen damit ich die Datenstrukturen sehen kann

Lg Jimmy

 

Halloo,

also zuerst habe ich diesen Befehl in VBA um nach Filtern des Kunden die passenden Produkte angezeigt zu bekommen:

Code:

Um nun die passenden Produkte mit allen Infos wie Rabatt etc. in meinem Formular angezeigt zu bekommen mach ich folgendes:

Code:

Ich möchte quasi das man einfach nach dem Produkt auch filtern kann und dann die passenden Kunden angezeigt bekommt.
Das mach ich momentan so:

Code:

Jedoch muss ich nach diesem Filtern und Auswahl des Kunden erneut das Produkt auswählen damit der AfterUpdate Code ausgeführt wird.

Was insgesamt vielleicht noch erwähnt werden muss ist, dass jedes Produkt eine ProduktID und eine EditionsID besitzt. Der Produktname und die ProduktID kann bei einem Kunden auch mehrmals vorkommen. Lediglich die EditionsID in Verknüpfung zum Kunden ist einmalig.

Ich hoffe das hilft euch weiter *Smilie

Liebe Grüße
Dodanator

 

Am Rande:
Code:

Wo kommt sqlpro her - das fliegt doch nicht vom Himmel (sofern es kein Formularfeld ist).

Füge im Modulkopf nach
Code:

die Zeile
Code:

ein. Dann wird Deine sqlpro-Zeile als Fehler markiert.

Fazit:

Alle Variablen deklarieren und Option Explicit (am Besten per Voreinstellung) in jedem Modulkopf hinzufügen!

 

Hey Maxel, das ist eine von mir deklarierte Variable die ich im Modulkopf deklariert habe:

Code:

Also damit stimmt alles soweit *Smilie

 

Servus Dodanator,
wenn Du Variablen im Modulkopf eines Formulars oder Berichtes dimensionierst, um sie dann in den Prozeduren nicht dimensionieren zu müssen, dann muss es als Code:

gemacht werden.
Code:

Nur in einer Prozedur geht es per Code:

.
Dieses Public Variable gilt allerdings dann nur innerhalb dieses Formulars/Berichtes.
In einem globalen Modul kann eine dort als Code:

oder Code:

dimensionierte Variable in allen Formularen und Berichten benutzt werden.
Vielleicht hilft Dir der Tipp.

p.s.: Vorsicht beim Arbeiten mit Public Variablen. Ihre Werte gehen verloren, wenn ein Fehler im Programm entstanden ist,
der nicht durch eine Fehlerabfangroutine abgefangen worden ist.
Dann muss man die DB neu starten oder man arbeitet mit TempVars oder Properties.

 

Hallo Manfred,
Entschuldige, wenn ich als Halbwissender dich da korrigieren muss.
In Form- oder Reportmodulen spielt es keine Rolle ob Member-Variable
Privat oder Public sind. Wobei Letzteres nur in Ausnahmefällen zulässig
sein sollte, da ein Zugriff von aussen vom Ladezustand des Forms/
Reports abhängig ist.
Laut OH heisst Public "von überall/projektweit erreichbar". "Global" heisst
das Gleiche, und taucht in der OH in diesem Zusammenhang schon gar
nicht mehr auf (A2010).
Wegen der von dir beschriebenen Gefahr öffentlicher Variablen (wo auch
immer deklariert) mache ich es inzwischen in allgem. Modulen (in Klassen-
modulen so wie so) fast nur noch mit privaten Membervariablen und zuge-
hörigen Properties.

gruss ekkehard

 

Danke ekkehard,
da lag ich dann jahrelang daneben wohl.

 

Wenn von den Profis kein Widerspruch kommt, sieht es wohl so aus *Smilie

 

Mal sehen, was du dazu sagst.
Ich definiere in Formular 1 eine Public Variable StrSQL,
lade sie beim Öffnen des Formulars und zeige sie in einem unabhängigen
Textfeld.
Aus Formular 1 öffne ich Formular 2 und möchte darin diese Variable auch anzeigen. Und ????

 

Dieses
Code:

Wenn du es mit
Code:

versuchst bekommst du einen Fehler.

 

Also stirbt die Variable, wenn ich Formular 1 schliesse und danach Formular 2
öffne und ist also nicht Public.
Wahrscheinlich ein Streit um des Kaisers Bart, der es nicht wert ist, ihn weiterzuführen.

 

Hallo,

Ja, natürlich. Darauf hatte ich doch schon hingewiesen

Das gilt i.Ü. auch für eigene Klassenmodule.
Wirklich Public (auch zeitlich) ist eine Variable nur in einem allgem.
Modul.

gruss ekkehard

 

Hallo,
Formulare sind auch Klassen und damit gelten die allg. Regeln für die Sichtbarkeit und Lebensdauer von Variablen, insbesondere natürlich auch für diese Klassenobjekte. Private und Public sind die Zugriffsmodifizierer und die Position der Deklaration innerhalb einer Klasse oder eines Moduls hat Einfluß auf die Sichtbarkeit und Lebensdauer.
Hier mal etwas über die Sichtbarkeit und Lebensdauer:
https://docs.microsoft.com/de-de/off...e-of-variables
https://docs.microsoft.com/de-de/off...and-visibility


@Dodanator:
Grundsätzlich sollte man modulglobale und public Variablen vermeiden, solange diese nicht unbedingt benötigt werden. Das Argument der vereinfachten schreibweise gilt dabei nicht, sondern beschert dir im ungünstigen Fall sehr schwer zu findende Fehler und unerkannte Seiteneffekte.

Gruß Ulrich