Debug i VBA

Du er nødt til at forklare dig nærmere - hvilket værktøj koder du i (fx Word, visual interdev...) ?

Du kan sætte fx. breakpoints og watches - er det det du ønsker forklaret?

Debug.Print er en programmørs bedste værktøj!

    Men OK, -et breakpoint, og et kig i Locals vinduet for at se hvilken værdi dine variable har lige nu, er heller ikke at  foragte.

Det er debugging -som en VB programmør bruger det. Altså at finde fejl i dit program under udviklingsfasen. At finde ud af -nøjagtigt- hvor det er, at det går galt (eller godt).
Når jeg siger VB programmør, så gælder det også for VBA (Word, Excel, Access) -de har det samme interface, dog med færre muligheder.

/tjacob

OK her kommer en lille forklaring:

Det er nok en smagssag hvilken form for debugging man foretrækker så her kommer de forskellige jeg bruger i prioriteret rækkefølge

Breakpoint:
Man kan sætte et breakpoint ved at trykke F9 på den linie i koden hvor man ønsker at koden skal stoppe midlertidigt. Når kodeafviklingen stopper (går i breakmode) kan man vælge enten at afvikle resten af koden i et hug (F5) eller singlesteppe gennem koden (F8). Når koden er i breakmode kan man se værdien af af de enkelte variabler og kontroller ved at holde musens markør henover variablen eller kontrollen et øjeblik. Man kan også i breakmode bruge immediate vinduet (hvis du ikke kan se det kan du kalde det frem med <ctrl> g) Her kan du spørge på værdien af variabler eller kontroller ved at skrive:
?text1.text <Enter>
Du kan også i immediate vinduet ændre værdier inden du køre programmet videre fx:
text1.text = "hello world" <Enter>

Når du singlestepper gennem koden vha. F8 er der en lille spidsfindighed hvis du i stedet bruger <ctrl> F8 afvikles den kode som du er nået til, men du ryger direkte til næste linie i koden. Dette er effektivt hvis du linien du stå på er et funktionskald hvor du ikke ønsker at singlesteppe gennem afviklingen af koden i den kaldte funktion.

Debug:
Du kan skrive debug.print eller debug.assert i din kode. Den første skriver det der står efter debug.print ud i immidiate vinduet, mens den anden er en form for dynamisk breakpoint. Hvis det der står efter debug.assert er sandt går afviklingen i breakmode og du kan herefter singlesteppe gennem koden som forklaret ovenfor.  debug.assert kan være effektiv hvis du fx ønsker at gå i breakmode efter at en løkke har løbet et hvis antal gange fx:

for i = to 50000
  debug.assert i = 49000
next

Det vil ikke være sjovt at skulle singlesteppe sig gennem ovenstående kode til i når 49000.

Watch:
Du kan tilføge en watch til en variabel eller en kontrol i koden ved at højreklikke med musen på den og vælge add watch Her kan du vælge mellem Watch expression (der minder om debug.assert) her skal du skrive et eller andet udtryk i Expression der kan evalueres til sand eller falsk - er udtrykket sand går koden i breakmode. Break when value is true tja det gir næsten sig selv du er fri for at skrive et udtryk i Expression, men kan vælge at markere et stump af din kode eller en variabel eller en kontrol. Den sidste giver næsten sig selv.

Stop:
Du kan skrive Stop i din kode så vil koden gå i breakmode når den rammer stop.

Msgbox:
Så er der jo også msgbox der er meget anvendelig til at udskrive værdier under programafviklingen i udviklingsfasen.

Det er som sagt nok en smagssag hvilke(t) debugging værktøj man foretrækker, personligt bruger næsten udelukkende breakpoints, debug.print og msgbox, mens jeg så godt som aldrig bruger watches da jeg synes de er besværglige - de kræver mange musseklik (det er muligt der findes hotkeys til det, men jeg har ikke gidet kikke efter dem ;-)).

Bemærk:
Alle disse ting er skrevet som de anvendes i visual basic version 6.0. Hvis du koder i access, word, powerpoint, visio, visual interdev, excell eller andet kan der være små variationer. Ligeledes kan der være forskel på hvordan tingene virker alt efter hvilken version  (97, 2000, xp) og hvilket sprogversion af ovenstående programmer du koder i. Et særligt problem er Access (Det er der jeg har erfaringen) med kode af typen ActiveControl, activeForm og andre da dette kun virker i runtime og ikke i breakmode, men det er en biting som du nok falder over hvis du for brug for det.

Håber du kan bruge det...

henrik :-)

Beklager meget, I andre, men heko124 kommer så absolut med det mest kvalificerede svar, point til dig og mange tak for hjælpen.

your welcome :-)

Det var svært at komme med kvalificerede svar, når man ikke er helt klar over hvad du spørger om - hekto124 tog chancen og forklarede hvordan du bruger de forskellige debug-features, og satsede på at det var det du mente...

Helt OK at han får alle points :o)

NB: En anden meget vigtig ting:

Du bør kræve variabel deklaration (Tools -> Options -> Editor fanebladet: Afkryds Require Variable Declaration)

Hvorfor nu det?

Fordi:

Hvis du har en variabel "variabel_1" og senere bruger denne variabel, men laver en stavefejl (fx. "variable_1"), tror VB (eller VBA) at det er en ny variabel, der derfor nødvendigvis er tom. Og så kan tingene gå rigtig meget galt - for du er jo helt sikker på at den indeholder en eller anden værdi, men VB regner med at den er tom.

Al denne forvirring undgås, hvis du kræver variabelerklæring - for når du kører macroen/programmet, så vil VB fortælle dig at variablen variable_1 ikke er erklæret.
'Hvad søren', tænker du, og kikker nærmere, og ser, at det er fordi du har stavet forkert...

I øvrigt er det efter min mening sjusk ikek at erklære alle variable, og jeg kan ikke forstå hvorfor den indstilling er slået fra pr. default...

En anden god ting: Brug mindst et stort bogstav i dine variablenavne. Og når du skriver dit variabelnavn i din kode, så skriv altid med små bogstaver - retter VB automatisk variablen til så de rigtige bogstaver til store, kan du se, at VB genkender variablen...

:o)

To gode råd :-)

Takker igen, har altid Option Explicit slået, en feature der har "reddet" mig mange gange.
Jeg har dog nogle "debug-problemer".
Er det muligt at afvikle en del af koden og ikke kun fra "start" af proceduren og til første breakpoint?

Jeg er ikke helt sikker på at jeg forstår hvad du mener, men her et eksempel på nogen man kan gøre:

function eks()
kodelinie 1
kodelinie 2
kodelinie 3
kodelinie 4
kodelinie 5
end function

lad os sige at du ikke ønsker at linierne 1 til 3 bliver afviklet:
sæt et breakpoint på "function eks()" når koden stopper klikker du på den gule pil i venstre side af vinduet holder musen nede og trækker den gule pil ned til "kodelinie 4" herfra kan du nu trukke F5 for at afvikle programmet normailt eller F8 for at singlesteppe gennem resten af koden....

hvar det det du mente?

det var det, heko124, takker igen for hjælpen.

so little

:-)

Hmmmm....ved nærmere eftertanke, er det faktisk det modsatte jeg ønsker. Er det muligt at markere nogle linier og så få afviklet KUN dem? F.eks. en For-løkke midt i en procedure.

Nop - men du kan jo meget simpelt i din form_load smide en linie ind, der aktiverer For-løkken. Med GoTo (fy!) kommandoer kan du springe til den del af koden du er interesseret i (men undgå helst GoTo til andet end debugging samt OnError - det er ikke "pæn" programmering :o)

helt enig, men hvis vi kun taler om debugging hvorfor så ikke bare udkommentere de linier du ikke ønsker afviklet ?

GoTo er MEGET fy-fy i OOP verdnen, så jeg tror jeg må nøjes med at "kommentere" linierne i stedet.

Nå ja - bemærk, at jeg selv siger, at GoTO kun bør bruges til debugging!!!

Hvis man nu ønsker at springe til linie 2798 i et program, er det jo nemt lige at smide en GoTo ind i stedet for at kommenterer 2798 linier ud... Ofte vil man ikke bare kunne kommenterer alle linierne ud hvis man vil bevare at funktionaliteten. Og så fjerne GoTo igen, når man har fundet den fejl man leder efter :o)