VBA DoEvents funksjonen midlertidig stanser en makro som kjører midlertidig, noe som gir Excel en sjanse til å behandle tastetrykk, museklikk og andre operativsystemmeldinger.
I langvarige makroer kan det se ut til at Excel henger og ikke reagerer, og makroen kan være umulig å avbryte. Hvis DoEvents er inkludert i koden din, kan brukerne være trygg på at makroen fortsatt kjører, og kan fortsatt avbryte kjøringen om nødvendig.
VBA DoEvents -eksempel
Vurder følgende kode:
| 1234567891011 | Offentlig undersøkelse ()Dim i As LongFor i = 1 Til 20000Område ("A1"). Verdi = iNeste jegSlutt Sub |
Når du prøver denne koden, merker du at Excel -vinduet ikke kan samhandles med. Men fordi det ikke er veldig krevende for prosessoren, kan makroen fortsatt bli avbrutt ved å trykke ESC eller CTRL+BREAK.
Hvis det ble utført mange komplekse og krevende funksjoner inne i denne sløyfen, ville Excel imidlertid ta lengre tid å registrere en tastetrykkhendelse - opptil flere minutter eller muligens ikke i det hele tatt, spesielt hvis datamaskinen kjører andre programmer samtidig.
Legg nå til en enkelt linje med DoEvents under Range -oppgaven:
| 123 | Område ("A1"). Verdi = iDoEvents |
Hvis du kjører denne koden igjen, ser du at Excel nå reagerer - den kan fokuseres og bringes til forgrunnen. DoEvents blir ringt opp hver gang gjennom løkken, noe som sikrer at makroen alltid gir kjøring slik at Excel kan behandle alle meldinger som sendes til den. Fordi denne makroen kjører raskt, virker det nesten som om den kjører i bakgrunnen (selv om den ikke er det) - flere operasjoner inne i løkken vil raskt avsløre den illusjonen.
Gjør hendelser farer
Ta en ny titt, skjønt. Mer enn bare å la Excel fokusere, kan du faktisk klikke deg rundt i cellene og til og med bytte faner mens makroen kjører (prøv det - du vil se litt morsom oppførsel). Dette viser en av farene ved DoEvents - det kan være årsaken til utilsiktede konsekvenser hvis makroen din ikke blir kodet nøye.
En annen fare er at DoEvents kan fungere som et vindu for andre makroer å kjøre inne i. Prøv dette: plasser en ActiveX CommandButton i regnearket, dobbeltklikk på den, og legg til følgende kode i CommandButton1_Click () -hendelsen:
| 1234567 | Dim c As RangeFor hver c In Range ("B3: E8")c.Value = c.Value + 1Neste c |
Slå av designmodus i Excel, og kjør deretter Test () -makroen du la til tidligere. Mens Test -makroen kjører, kan du klikke på CommandButton på regnearket, og den tilhørende makroen vil kjøres så snart DoEvents gir Test () -makroen en pause.
Faren her er hvis CommandButton -makroen endret dataene Test () -makroen jobbet med, eller utløste Test () -makroen igjen. Du kan ende opp med ekstremt rotete resultater hvis du ikke er forsiktig.
Til slutt bør du være oppmerksom på at DoEvents vil få makroen til å påvirke ytelsen når den blir ringt. I en sløyfe vil denne virkningen øke raskt, med mindre du begrenser hvor ofte DoEvents kalles. Med henvisning til vårt Test () -eksempel, prøv dette:
| 1 | Hvis jeg Mod 1000 = 0 deretter DoEvents |
Dette reduserer synlig responsen til Excel, men ytelseseffekten vil reduseres.
Når skal jeg bruke DoEvents
Til tross for disse farene, er DoEvents en praktisk funksjon som hjelper til med testing og feilsøking. Vurder å legge DoEvents til langløpende løkker.
En annen grunn til å inkludere DoEvents er å tillate brukerfeedback. For eksempel kan en makro oppdatere en UserForms etiketter med fremdriftsindikatorer. Uten DoEvents kan det hende at Excel ikke mottar meldingene for å male UserForm på nytt, noe som gir en bruker inntrykk av at makroen har sluttet å fungere - spesielt hvis du bytter til et annet program og deretter prøver å bytte tilbake til Excel. Med DoEvents vil imidlertid UserForm fortsette å bli malt på nytt, og oppdateringer av makroens fremgang vil fortsette å vises.
For det meste er DoEvents ikke noe du vil inkludere mye i koden din, og kan ofte utelates. Hvis respons er noe makroen din trenger, ikke tell det ut!
