Access 2016. Keuzelijst met invoervak werkt niet goed

[KPTPTT]

Hallo allemaal. In een formulier heb ik nog één laatste ding te doen een zoekveld op adres, huisnummer, woonplaats. Ik heb een Query "Query zoeken" gemaakt met de ahw gegevens. Als ik via Ontwerp de keuzelijst op het formulier plaats, dan zie ik vreemd genoeg in de Wizard niet het adres staan alleen huisnummer, plaats. In de Query staan ze wel.
In de keuzelijst zie ik de ahw gegevens wel staan en kan ik een keuze maken. Ik heb voor de keuzelijst (bij klikken) de volgende VBA code gemaakt.

Private Sub Keuzelijst380_Click()
With Me.Keuzelijst380
    If .Value <> "" Then
    Me.Filter = "[Adres]= """ & .Value & """"
    Me.FilterOn = True
    Else
    Me.Filter = ""
    Me.FilterOn = False
    End If
    End With
End Sub

Ergens van internet (helpmij?) als idee overgenomen. De Rijbron staat ingesteld op "Query zoeken". Alleen als ik het Besturingselement invul met "Adres" (alleen te selecteren uit de onderliggende tabel en niet uit de Query??) kan ik dmv de keuzelijst een record selecteren. Ik heb nog twee andere bladertoetsen (macro's) om door de records van het formulier te kunnen bladeren.

Probleem: Als een adres in de keuzelijst is geselecteerd kan ik met de down toets niet naar het begin van de lijst bladeren (foutmelding: Kan niet naar de opgegeven record gaan). Met de Up toets worden alle velden van het formulier leeg (gelijk aan de situatie Nieuw). Er kan niet gebladerd worden. Ik heb dergelijke keuzelijst in een ander db gemaakt maar met macro's, dat werkt goed. Dezelfde macro instructies in deze db werken niet.

 

[OctaFish]

Ik snap je probleem niet helemaal, maar ik heb wel een licht vermoeden wat er aan de hand is. Om te beginnen: als je een keuzelijst maakt met de wizard, dan zal die proberen om het sleutelveld te verbergen. Meestal zoek je daar namelijk niet op, maar wil je op het eerstvolgende tekstvak willen zoeken. Jij maakt een query op basis van de velden adres, huisnummer en plaats en vermoedelijk wil de wizard de eerste kolom (adres) verbergen. Het veld zit echter wel in de query, vandaar dat je ‘m in de query wel ziet.
Je eigenlijke probleem is niet meer dan logisch. Als je filtert op basis van een keuzelijst, dan is het resultaat doorgaans één record. Bij jou dus ook. Dan valt er niks te bladeren, omdat er op je formulier maar 1 record te zien is. Maar je kunt dan vaak nog wel naar een nieuw record gaan, en dat is dan uiteraard leeg. Dan kun je overigens nog steeds niet bladeren, want er zit nog altijd een filter op je formulier. Dat moet je eigenlijk dan eerst verwijderen.

 

[route99]

Zet eens een test database neer. Das handiger.

Edit: ik heb pas weer eens de moeite genomen om het zoeken sterk te vereenvoudigen.
Heb het opgelost met een hulpveldje, "search" genaamd (wordt in de Engels Access versie "unbound" genoemd).
Daar heb ik een VBA code aan toegevoegd bij de optie "upon change" en zodra ik begin te typen zoekt ie meteen.
Dus of ik houd bijv 4 records over en kan ik bladeren, of ik heb 1 record over en ben ik meteen klaar...
Heb de code nu niet bij de hand, maar op mijn werk.

Ik heb code gemaakt om in 1 veld te zoeken, maar ook een uitgebreidere code om in 2 velden te zoeken.
Bij mij zijn die velden: "Name" en "Remarks"

Het werkt inmiddels zo fijn/handig, de gebruikers zijn er super blij mee tov eerdere search tools die ik erin had zitten, dat laatsten er helemaal uit gehaald worden. Lekker opschonen die handel...
Ervaren mensen weten de weg wel hoe je ook heel handig echt super gebruik kunt maken van multi-veld searches om zo steeds smaller te gaan.
Maar dat willen de meeste gebruikers niet... ff snel wat opzoeken is voor hen DE manier en dat biedt de nieuwe optie heel simpel.

 

[KPTPTT]

Octafish en Route99 dank voor jullie antwoord . Octafish. Achteraf wel logisch wat je zegt. Ik heb het keuzeveld leeg gelaten (geen filter) en kan dan weer bladeren met de twee bladertoetsen. Zou een optie kunnen zijn, maar heb je misschien ook een betere oplossing: een keuzelijst en kunnen bladeren door de records.

Route99. 1. Ik ben wel benieuwd naar jouw oplossing. 2, Als ik via rubriek Ontwerp een Keuzelijst met invoervak toevoeg, dan zie ik de in Wizard lijst de velden van de tabel waarbij het adresveld niet wordt getoond, wel het ID en huisnummer etc.. Daarbij verwacht ik in de lijst het adres en een keuze te kunnen maken uit de Query. De Rijbron staat op de Query ingesteld.

 

[route99]

Kijk de velden in de query maar eens na. Het lijkt me dat dan het adresveld niet in het query ontwerp staat... of simpeler... niet aangevinkt staat. In dat geval is het logisch dat ie niet te zien is later... als je iets wilt obv die query...

 

[OctaFish]

Heb het opgelost met een hulpveldje, "search" genaamd (wordt in de Engels Access versie "unbound" genoemd).

Volgens mij haal je wat zaken door elkaar hier. Een 'Search' hulpveld bestaat niet ("search" is bij mijn weten overigens ook een Engels woord ). Elk tekstveld kan gekoppeld zijn aan een veld (uit query of tabel) middels de optie <Besturingselementbron> of niet. In het laatste geval, dus geen koppeling, spreek je van een niet-gebonden tekstveld. Hang je er alsnog een veld aan, dan is het dus een gebonden tekstveld. Maar dat heeft dus niets met het type veld te maken.

De werkwijze van route99 is een hele makkelijke, en ik gebruik hem zelf uiteraard ook. Hij werkt m.i. het beste op een doorlopend formulier, omdat je daar gelijk het resultaat ziet van wat je doet. Het komt er op neer dat je een niet-gebonden tekstvak neerzet in de koptekst van je formulier, waar je de gebeurtenis <Bij wijzigen> van gebruikt om 'live' te filteren op de recordset die onder het formulier hangt. De code ziet er dan zo uit:

Private Sub txtZoeken_Change()
    If Len(Me.txtZoeken) = 0 Then
        Me.Filter = ""
        Me.FilterOn = False
    Else
        With Me
            .Filter = "[Band] LIKE ""*" & .txtZoeken.Text & "*"""
            .FilterOn = True
            .txtZoeken.SelStart = .txtZoeken.SelLength
        End With
    End If
End Sub

Bij mij heet het zoekveld dus [txtZoeken], en ik filter het formulier op één veld: [Band]. Voor filteren op twee velden krijg je zoiets:

            .Filter = "[Band] LIKE ""*" & .txtZoeken.Text & "*"" OR [Album] LIKE ""*" & .txtZoeken.Text & "*"""

Als je op meerdere velden tegelijk wilt zoeken, kun je dat beter in de query oplossen door de velden samen te voegen in één veld, en de zoekactie dus op dat ene veld uit te voeren.

 

[OctaFish]

2, Als ik via rubriek Ontwerp een Keuzelijst met invoervak toevoeg, dan zie ik de in Wizard lijst de velden van de tabel waarbij het adresveld niet wordt getoond, wel het ID en huisnummer etc.. Daarbij verwacht ik in de lijst het adres en een keuze te kunnen maken uit de Query. De Rijbron staat op de Query ingesteld.

Ik heb je de oorzaak daarvan dacht ik al uitgelegd in bericht #2 . Sowieso is filteren via een keuzelijst tricky, omdat je, zeker als je de wizard gebruikt, bijna altijd het sleutelveld meekrijgt (en dat wordt dan ook nog eens verborgen). En zodra je filtert op het sleutelveld krijg je altijd maar één record.

 

[route99]

Volgens mij haal je wat zaken door elkaar hier. Een 'Search' hulpveld bestaat niet ("search" is bij mijn weten overigens ook een Engels woord ). Elk tekstveld kan gekoppeld zijn aan een veld (uit query of tabel) middels de optie <Besturingselementbron> of niet. In het laatste geval, dus geen koppeling, spreek je van een niet-gebonden tekstveld...................

De werkwijze van route99 is een hele makkelijke, en ik gebruik hem zelf uiteraard ook. Hij werkt m.i. het beste op een doorlopend formulier, omdat je daar gelijk het resultaat ziet van wat je doet. Het komt er op neer dat je een niet-gebonden tekstvak neerzet in de koptekst van je formulier, waar je de gebeurtenis <Bij wijzigen> van gebruikt om 'live' te filteren op de recordset die onder het formulier hangt. De code ziet er dan zo uit:

Private Sub txtZoeken_Change()
    If Len(Me.txtZoeken) = 0 Then
        .............
End Sub

....

Het is geen cursus,...het was vooral om een indruk te geven, maar je snapte meteen wat ik bedoelde met de oplossing... dus de boodschap was dus echt wel aangekomen dus ook la was het wat plastisch/rekbaar/ niet zo formalistisch geschreven... het was iig duidlijk...met de TS was ik er wel uitgekomen...

Bedankt voor het neerzetten v/d code, de mijne er bijna gelijk... gek he...
Super handig... dan kan ik dat nu achterwege laten.... kon even een rustig bakkie koffie doen...

 

[OctaFish]

Het is geen cursus,...het was vooral om een indruk te geven,

Het gaat er niet zozeer om dat we TS wat leren, als wel in de juiste richting duwen. En ik vond dat je e.e.a. niet helemaal correct uitlegde, vandaar dat ik er even insprong.

Ik post wel eens een db met een uitgebreide zoekfunctie die op meerdere velden kan zoeken. En op verschillende manieren. Daarbij zit natuurlijk de moeilijkheidsgraad dat je van tevoren nooit weet of je op een datum wilt zoeken, een getal of tekst. Of een combinatie. En als je daar een keuzelijst bij gebruikt, wordt het nog lastiger. Dus als je écht een universele functie wilt gebruiken om te zoeken, dan is dat wellicht wat voor je. Mijn gebruikers hoor ik er in ieder geval nooit over klagen .

 

[route99]

Mijn gebruikers ook niet....
En het doel was om het niet te formalistisch te doen... de rest komt later.... dat duwtje...

Als het echt te ingewikkeld wordt dan gaat mij voorkeur uit naar een query iets als dit:
https://www.airweb.org/eAIR/techtips/Pages/Criteria-Field.aspx
waarbij ik dan liever een of meerdere criteria invul waarbij je per vraag naar het criterium een pop up krijgt zoals in het voorbeeld onder.

 

[KPTPTT]

Heren, hartelijk dank voor alle informatie. Ik ga met de informatie stoeien en de werking en resultaten bestuderen. Als ik het goed begrijp is het een zoekveld geworden. Ik ga meer van de keuzelijst uit omdat je dan een goed overzicht van alle beschikbare "formulieren" hebt en een keuze kan maken. Vandaaruit moet het mogelijk zijn om nog wat op en neer te kunnen bladeren.
Over duwtjes in de goed richting gesproken, ik heb dankzij Helpmij veel geleerd en twee mooie Access/Excel (VBA) applicaties gemaakt die in de praktijk uitstekend dienst doen, hulde voor jullie werk en zet het voort.

 

[OctaFish]

Als het echt te ingewikkeld wordt dan gaat mij voorkeur uit naar een query iets als dit:
https://www.airweb.org/eAIR/techtips/Pages/Criteria-Field.aspx
waarbij ik dan liever een of meerdere criteria invul waarbij je per vraag naar het criterium een pop up krijgt zoals in het voorbeeld onder.

Dat is een leuke pagina met “basic stuff” over hoe je het criterium veld gebruikt, maar het kan dus vele malen mooier. .

@TS: filteren met een keuzelijst is prima als de uitkomst één record moet zijn. En valt er niks te bladeren. Een ‘live’ filter met een tekstvak werkt veel intuïtiever dan een keuzelijst, omdat je het resultaat van elke letter gelijk terugziet in het resultaat. Met een keuzelijst moet je altijd een keuze maken en de keuze bevestigen. Gebruikers (althans: de mijne) vinden dat minder prettig.
Er is, als je ruimte op het formulier hebt, natuurlijk niks op tegen om beide opties aan te bieden. Dat vergroot alleen maar het gebruikersgemak. Denk er altijd aan dat je de db niet voor jezelf maakt, maar voor anderen die niet in jouw hoofd kunnen kijken.