Hur använder man knapparna i en msgbox, ex: vbOkCancel

Om du t ex vill kolla om någon svara ja eller nej på din fråga:

If MsgBox("Do you want to remove this row?", vbQuestion + vbYesNo, "Titel") = vbYes Then

Snyggare och bättre sätt(Tycker jag):

Select Case MsgBox("Do you want to remove this row?", vbQuestion + vbYesNo, "Titel")
Case vbYes
DeleteRow
'Case vbNo
'Case Else
End select

Lite bättre exempel på varför den är bättre:

Public Sub Test()
On Error GoTo Test_Err

Err.Raise vbObjectError + 1, "Fel1", "Fel 1 har inträffat"
Err.Raise vbObjectError + 2, "Fel1", "Fel 2 har inträffat"
Err.Raise vbObjectError + 3, "Fel1", "Fel 3 har inträffat"

Test_Exit:
Exit Sub

Test_Err:
Select Case MsgBox(Err.Description, vbAbortRetryIgnore, Err.Source, Err.HelpFile, Err.HelpContext)
Case vbRetry
Resume
Case vbIgnore
Resume Next
Case vbAbort
Resume Test_Exit
End Select
End Sub

hej
Snyggare och bättre sätt(Tycker jag):

Snyggare för vem ??? . Programmet blir ju inet
bättre för att man "smackar" in en massa onödigt "skit".

Sven

Smaksak... Men detta är sant.

Men låt oss jämför dessa två sätt att utföra det på?


If MsgBox("Do you want to remove this row?", vbQuestion + vbYesNo, "Titel") = vbYes Then

End if

Select case MsgBox("Do you want to remove this row?", vbQuestion + vbYesNo, "Titel")
Case vbYes

End Select

Vi lägger till en nej/ avbryt möjlighet

If MsgBox("Do you want to remove this row?", vbQuestion + vbYesNo, "Titel") = vbYes Then

Else

End if

Select case MsgBox("Do you want to remove this row?", vbQuestion + vbYesNo, "Titel")
Case vbYes

Case Else

End Select

Alternativt...

Select case MsgBox("Do you want to remove this row?", vbQuestion + vbYesNo, "Titel")
Case vbYes

Case vbNo

End Select

Vi försöker med tre knappar. Låt os säga att vill fråga användaren om han vill spara förändringarna när han stänger formuläret...


Private Sub Form_Unload(Cancel As Integer)
Dim Response As VbMsgBoxResult
Response = MsgBox("Vill du spara dinna förändringar?", vbQuestion + vbYesNoCancel, "Titel")
If Response = vbYes Then
SaveRecord
ElseIf Response = vbCancel Then
Cancel = True
End If
End Sub


Private Sub Form_Unload(Cancel As Integer)
Select Case MsgBox("Vill du spara dinna förändringar?", vbQuestion + vbYesNoCancel, "Titel")
Case vbYes
SaveRecord
Case vbCancel
Cancel = True
End Select
End Sub

Om vi jämför resultatet så ser vi att if-satsens struktur förändras i struktur. Select-satsen kan förändras, behöver ingen variabel och är lättöverskådlig...

Men alla har ju rätten att programmera hur de vill, jag ville bara föreslå en lösning jag tycker är smidig...

Det finns alltid bättre sätt att lösa saker och ting på än andras sätt. Just i programmering ser många det som prestige att lösa det med kortaste koden. Men programmering är inget udnantag från fysikens lagar, tänker då närmast på: Det man vinner i tid förlorar man i kraft. Det är direkt applicer´bart på mycke programkod.

Du förlorar i tid på att skriva snygg kod och kommentera mycket. Kod som är lättläst. MEN du VINNER i kraft. Detta är sant. Jämför följande kodrad. (Den är bara ett exempel, koden i övrigt är meningslös)

If etid = 10 Then etid = Timer + 10 Else etid = etid + 1

Med följande rader:

If etid = 10 Then
etid = Timer + 10
Else
etid = etid + 1
end if

Självklart förlorar man i tid på det andra sättet att koda. MEN det blir snyggare och mer lättläst för den som skall läsa det. Ett annat exempel är följande.....

day=choose(d,"Måndag","Tisdag","Onsdag","Torsdag","Fredag","Lördag","Söndag")

OK dett är väl snyggt och så... Du vinner i tid men förlorar i kraft:

Nedan är ett bättre sätt att lösa det på.

select case d
case 1: day="Måndag"
case 2: day="Tisdag"
case 3: day="Onsdag"
case 4: day="Torsdag"
case 5: day="Fredag"
case 6: day="Lördag"
case 7: day="Söndag"
case else:
end select

Varför är detta ett bättre sätt att lösa det på...... Jo det kan hända att d antar ett värde annat än inom tillåtet intervall och då har man case else villkoret som tar hand om detta läge. Med choose får man NULL vilket kan generera fel i programmet....

Detta kallas defensiv programmering och utnyttjas av lite mer seriösa programmerare som vill försäkra sig om att minimera antalet buggar.

Jag tycker att din lite längre lösning är snyggare och bättre bara därför att det är defensiv programmering. BORT med all prestige i detta forum.. Det är visst bra att det kommer olika förslag på att lösa problem men jag tycker inte man skall klanka ner på andras lösningar och säga att min är bättre.....

VISST kan man hävda att min är bättre, men då tycker jag det är viktigt att man skall motivera detta.

Ha det bra....

/Peterh

Tack för att du påpekar detta för mig. Detta är ju okså något som mina arbetskamarter råkar utför varje dag. Det händer öfta att mitt egot springer iväg... :O)

Ska försöka ta åt mig din kritik och förbättra mig...

Min första prioritet är att hjälpa. Inte försöka skryta...
Får försöka efterleva det bättre...

//Mvh, Andreas

Nja det var inte dig jag kritiserade (konstruktivt) det var sven som tycket att man inte skulle in med en massa onödigt skit...

Ju mer onödigt skit desto bättre..... Fram för mer defensiv
programmering än spagettikod som ingen fattar efter en stund.

Jag tycker din kod är OK.... Du förutser fel och sådant....

Jag tycker det är bra... Det är så man skall programmera...

Det är svårt nog att skriva buggfritt.... Så därför bör man i längsta möjliga mån tillämpa defensiv programmering...

Likaså det där med att döpa formar och textrutor som många inte orkar göra.... Men hur jobbig blir inte en kod på 200 rader att läsa om det är typ

text1.text="kalle"
text2.text="Andersson"
text3.text="Sundsvall"

istället för

txtFnamn="Kalle"
txtEnamn="Andersson"
txtOrt="Sundsvall"

Mycket bättre eller hur...

Ha det bra AH..

Safe programming

/peterh