Stop hvem denn gør og retur til en formular

glemte lige, min knap gøre dette idag. den skal selvføldige ikke åbne formular1, hvis der er et felt som mangler data, men fortælle brugeren at han/hun skal indtaste data, så han kan komme videre

Private Sub Kommandoknap77_Click()

On Error GoTo Err_Kommandoknap77_Click

    Dim stDocName As String
    Dim stLinkCriteria As String

    stDocName = "Formular1"
    DoCmd.OpenForm stDocName, , , stLinkCriteria

Exit_Kommandoknap77_Click:
    Exit Sub

Err_Kommandoknap77_Click:
    MsgBox Err.Description
    Resume Exit_Kommandoknap77_Click
   
End Sub

I #1 vises blot hvilken horibel kode guiden autogenererer - i tillæg er Kommandoknap77 et dårligt navn - men da access 'knap skaber funktionaliteten' jo ikke kan vide hvad knappen skal bruges til er guiden stort set ubrugelig (til at lave kode - det er ok at orientere sig ved at gennemgå guiden med dens valg af handling ved  klik)



Uddybning af autogenerede kodes særheder:

1.
==
Det, at fejlhåndtering i viste eksempel er overflødig, påpeger det generelle forhold at fejlhåndtering ikke bør autogenereres - det er programmørens ansvar at tage stilling til, i hvert enkelt tilfælde, hvilke selektioner skal håndteres af den normale sekvens og hvilke af fejlhåndtering.
Anvendelse af 'goto' bryder princippet om struktureret programmering - et princip som vba ikke alene honorerer med alle andre kontrolstrukturer - men, grundet de forskelligt navngivne 'slut på kodesekvens', i sikker kodning, er i særklasse med sproget ADA. 
Man behøver ikke at bruge goto for at håndtere fejl i vba:

On error resume next

[possible error raising command1]
if err.Number <> 0 then
...
err.Clear:end if

[possible error raising command2]
if err.Number <> 0 then
...
err.Clear:end if


Indrømmet, ovenstående vbscript måde er lidt tung - det er nok derfor ms-access skaberne har valgt at ignore 50-60år gammel god latin
http://en.wikipedia.org/wiki/Goto med:

on error goto label
[command1]
[command2]

label:
'handling all errors, breaking main thread of execution.



2.
==
Dim stDocName As String

Der er ingen speciel grund til stDocName ikke kan være variant - altså blot

Dim stDocName

Det er et eksempel på Microsofts misvisende pædagogik - der findes nemlig tilfælde (api kald og byval argumenter) hvor man skal bestemme typen. Det Microsoft her signalerer med 'as String' er at vi har med de tilfælde at gøre uden det har noget på sig.
At forlade den gamle notation stDocName$ er endnu et punkt hvor der IMO ikke er grund til at rette sig efter Microsoft kedelige retningslinier.

3.
==
stDocName = "Formular1"
DoCmd.OpenForm stDocName, , , stLinkCriteria

En variabel skal anvendes når der skal refereres til en værdi 2 eller flere gange. Det konflikter med programmør kreativitet ikke at udtrykke sig kortest muligt og kun dokumentere en gang. At navngive en variabel for at anvende den en gang på navngivet argument plads er dobbelt konfekt.

oki, for mig lyder det meget som om du er sur på microsoft, jeg kan ikke lige se den evt. løsning som jeg har spurgt om.

I grove træk kunne du bruge en konstruktion i stil med:
(Ikke testet. Udskift feltnavne m.v. med dine egne værdier)

Private Sub DinKnap_Click()
  'Tjek for tomt felt
  if IsNull(Me.Felt1) then
    msgbox "Felt1 skal udfyldes"
    me.felt1.setfocus
    exit sub
  end if

  'Tjek for værdi
  if (Me.Felt2<1) or (Me.Felt2>100) then
    msgbox "Felt2 skal indeholde en værdi mellem 1 og 100"
    me.felt2.setfocus
    exit sub
  end if

  'osv. osv.

  DoCmd.OpenForm "DinAndenForm"
End Sub

Takker, kan du evt fortælle mig hvorfor den ikke virker i en liste ??

Hm. Hvis du mener, at du vil tjekke værdien af en dropdown, skal du bruge f.eks.:

  If Me.Kombinationsboks1.Column(n) <> EtEllerAndet Then

hvor n er nummeret på den kolonne, du vil tjekke. Første kolonne er nummer 0 (nul).

... og jeg ser lige, at du allerede har lukket spm, så tak for point i øvrigt ;o)