ga naar "nieuw record" is ook al gelijk definitief...

[ernstcramer]

Bij een formulier in Access, waar je gegevens wilt invoeren, heb je onderin de navigatieknoppen zitten. Daar zit ook zo'n mooi veldje bij welk record het is van hoeveel. En als je filtert wordt vermeldt hoeveel records er in het filter zitten.

Ik heb echter de navigatieknoppen apart gedefinieerd, omdat er aan het navigeren acties vastzitten in verband met de gegevens van het record. Bepaalde velden moeten wel of niet zichtbaar worden, afhankelijk van de inhoud van het record.

Als je bij de oorspronkelijke navigatieknoppen het laatste record hebt, en dan "pijltje rechts" doet, opent Access een nieuw record. Maar dat kan je weer ongedaan maken met pijltje "naar links". probleem opgelost.

Ik had in eerste instantie via de wizard de actieknop pijltje "volgend record" gemaakt. Dan heb je de volgende code:

voor toevoegen nieuw record : DoCmd.GoToRecord , , acNewRec
voor volgend record: DoCmd.GoToRecord , , acNext

Ik heb dat gewijzigd in: DoCmd.RunCommand acCmdRecordsGoToNew resp. DoCmd.RunCommand acCmdRecordsGoToNext

daarna run ik dus de noodzakelijke settings: maar dan is het nummer van het record ook al een feit.
Is dit te voorkomen?

Code voor het nieuwe record:

Private Sub toevoegen_Click()
'---toevoegen nieuw record
    DoCmd.RunCommand acCmdRecordsGoToNew
    Call decoder_Click
    materieelsoort.SetFocus
End Sub

Code van de Call:

Private Sub decoder_Click()

    If Me![decoder] = 1 Then
        Me![adres].Visible = False
        Me![adres] = "0"
        Me![HVM].Visible = False
        Me![HVM] = 0
        Me![geluid].Visible = False
        Me![geluid] = 0
        Me![LED].Visible = False
        Me![LED] = 0
        Me.sF_functietoets.Visible = False
        Else
        Me![adres].Visible = True
        Me![HVM].Visible = True
        Me![geluid].Visible = True
        Me![LED].Visible = True
        Me.sF_functietoets.Visible = True
    End If

End Sub

 

[OctaFish]

voor toevoegen nieuw record : DoCmd.GoToRecord , , acNewRec
voor volgend record: DoCmd.GoToRecord , , acNext

Ik heb dat gewijzigd in: DoCmd.RunCommand acCmdRecordsGoToNew resp. DoCmd.RunCommand acCmdRecordsGoToNext

Ik ben wel héél erg benieuwd naar de winst van de aanpassing; ik kan het namelijk niet uitleggen. Ik gebruik al jaren tot volle tevredenheid DoCmd.GoToRecord en heb nog geen seconde gedacht: 'dat moet beter kunnen'... Maar jij hebt die verklaring dus wel .

daarna run ik dus de noodzakelijke settings: maar dan is het nummer van het record ook al een feit.
Is dit te voorkomen?

Nou nee; je maakt een nieuw record aan, wat op het moment dat je de cursor er naar toe verplaatst nog niet bestaat. Ga je dan terug, dan heb je nog niks gedaan. Jij vult echter een aantal velden in. Ergo: je maakt een record aan. Blijkbaar gebruik je ook een Autonummerveld, en dat houdt dus in dat je dat nummer kwijt raakt. De enige oplossing is dan, als je het record verwijdert, om de db gelijk te comprimeren en herstellen. Dan krijg je het nummer weer terug.
Of, veel slimmer, laat het autonummer voor wat het is, en bepaal zelf met een aparte functie het volgnummer. Dan nog moet je het reeds gemaakte record verwijderen, maar je nummer blijft bestaan.
Of, nog mooiere oplossing, gebruik een niet-afhankelijk formulier en sla het record alleen op als aan alle voorwaarden is voldaan.

 

[ernstcramer]

Dank OctaFish voor je commentaar.

Ik heb de knop aangemaakt niet om slimmer te zijn, maar om de actie van die velden zichtbaar/onzichtbaar te maken er gelijk aan te kunnen koppelen. dat is de enige reden; anders had ik de navigatieknoppen wel gehouden.

Ik snap je uitleg: juist die settings van de velden is een actie die het record al waarde geeft. Ok! Ik zal eens kijken wat ik nu doe.
Dank voor je advies!

 

[OctaFish]

Mijn reactie was niet op het feit dat je knoppen hebt gebruikt (doe ik namelijk ook meestal) maar op het feit dat je DoCmd.GoToRecord hebt vervangen door DoCmd.RunCommand. Ik zie daar, met de beste wil van de wereld, het voordeel niet van. Dus hou ons niet langer in spanning .

 

[ernstcramer]

Aha...

ik dacht wijze lessen te kunnen leren uit jouw vorige commentaar, waarbij je je afvroeg waarom ik zo omslachtig programmeerde.

In een van die voorbeelden die je daarbij gaf zat het RunCommand commando, die toen ik naar de argumenten ging kijken ook het "acCmdRecordsGoToNew" liet zien.
Dus heb ik dat gebruikt, omdat het ook minder argumenten gebruikte...

 

[OctaFish]

... En daar is ook niks mis mee. . Alleen gebruik ik voor navigatieknoppen toch altijd GoTo, omdat het veel minder parameters kent dan RunCommand. Dat kent er een paar honderd, dus je zoekt je (ik wel althans) het schompes naar de juiste syntax. Terwijl je met Goto. veel sneller een optie hebt gevonden. Dus qua snelheid in uitvoering ontlopen ze elkaar niks, en qua snelheid van bouwen is GoTo veel sneller. Runcommand kent, zoals ik al zei, veel meer opdrachten dus dat gebruik ik dan weer wel voor acties die daar handig mee zijn. Zo is Opslaan een stuk makkelijker met Runcommand.

 

[ernstcramer]

:thumb: weer wat geleerd

 

[OctaFish]

Is je vraag inmiddels opgelost? In dat geval mag je hem op <Opgelost> zetten .

 

[ernstcramer]

ik dacht dat ik alle berichten getagd had...