L'app VBA di Excel si interrompe spontaneamente con il messaggio "L'esecuzione del codice è stata interrotta"

Da quello che posso vedere sul web, questa è una lamentela abbastanza comune, ma le risposte sembrano essere più rare. Il problema è questo:

Abbiamo un numero di app VBA di Excel che funzionano perfettamente su un numero di macchine degli utenti. Tuttavia su una macchina si fermano su determinate righe di codice. Sono sempre le stesse linee, ma quelle linee sembrano non avere nulla in comune l'una con l'altra.

Se premi F5 (esegui) dopo l'arresto, l'app continua, quindi è quasi come se fosse stato aggiunto un punto di interruzione. Abbiamo provato a selezionare "Rimuovi tutte le interruzioni" dal menu e persino ad aggiungere un'interruzione e rimuoverla di nuovo.

Abbiamo già riscontrato questo problema con singole app e l'abbiamo risolto tagliando il codice dai moduli, compilandolo e incollandolo di nuovo in ecc.

Il problema ora sembra riguardare Excel stesso anziché un singolo .xls, quindi non siamo sicuri di come gestirlo.

Qualsiasi aiuto sarebbe ricevuto con gratitudine :)

Grazie,

Philip Whittington

Ho trovato una seconda soluzione.

1. Premi il pulsante "Debug" nel popup.
2. Premi Ctrl+ Pause|Breakdue volte.
3. Premi il pulsante di riproduzione per continuare.
4. Salva il file dopo il completamento.

Spero che questo aiuti qualcuno.

Questo problema deriva da una strana stranezza in Office / Windows.

Dopo aver sviluppato lo stesso pezzo di codice VBA e averlo eseguito centinaia di volte (letteralmente) negli ultimi due giorni, ho riscontrato questo problema proprio ora. L'unica cosa che è stata diversa è che poco prima di sperimentare questo problema imbarazzante ho accidentalmente interrotto l'esecuzione del codice VBA con un metodo non ortodosso.

Ho ripulito tutti i file temporanei, riavviato, ecc. Quando ho eseguito nuovamente il codice dopo tutto ciò, ho ancora riscontrato il problema, prima di entrare nel primo ciclo. Ha senso che "premi il pulsante" Debug "nel popup, quindi premi due volte [Ctrl + Break] e dopo questo può continuare senza interruzioni" perché qualcosa nella combinazione di Office / Windows non ha rilasciato l'esecuzione. È bloccato.

L'azione ridondante Ctrl + Break probabilmente risolve l'esecuzione persistente.

Una soluzione è qui :

La soluzione a questo problema è aggiungere la riga di codice "Application.EnableCancelKey = xlDisabled" nella prima riga della macro. Questo risolverà il problema e sarai in grado di eseguire correttamente la macro senza ottenere il messaggio di errore "Codice l'esecuzione è stata interrotta ”.

Ma, dopo aver inserito questa riga di codice, non sono stato più in grado di utilizzare Ctrl + Break. Quindi funziona ma non molto.

Ho trovato colpire ctrl + break mentre la macro non era in esecuzione risolto il problema.

Vorrei provare le solite cose correttive: - Esegui Cleaner codice VBA di Rob Bovey sul tuo codice VBA - Rimuovi tutti i componenti aggiuntivi sul PC degli utenti, in particolare i componenti COM e .NET - Elimina tutti i file .EXD degli utenti (incompatibilità con MSoft Update) - Esegui Excel Rileva e ripara sul sistema degli utenti - controlla le dimensioni del file .xlb dell'utente (dovrebbe essere 20-30K) - Riavvia quindi elimina tutti i file temporanei degli utenti

Grazie a tutti per il loro contributo. Questo problema è stato risolto scegliendo RIPARAZIONE nel Pannello di controllo. Immagino che questo registri di nuovo esplicitamente alcuni dei componenti COM nativi di Office e faccia cose che REINSTALL non fa. Mi aspetto che quest'ultimo passi attraverso una lista di controllo e talvolta accetti ciò che è lì se è già installato, forse. Ho quindi avuto un problema separato con la registrazione della mia dll .NET per l'interoperabilità COM sul computer dell'utente (nonostante funzionasse anche su altri computer) anche se penso che questo sia stato il mio errore piuttosto che Microsoft. Grazie ancora, lo apprezzo molto.

Ho riscontrato questo problema alcune volte durante lo sviluppo di un'app VBA Excel complessa. A volte Excel ha iniziato a rompere l'oggetto VBA in modo casuale. E l'unico rimedio era riavviare la macchina. Dopo il riavvio, Excel di solito ha iniziato ad agire normalmente.

Presto ho scoperto che la possibile soluzione a questo problema è premere CTRL + Break una volta quando la macro NON è in esecuzione. Forse questo può aiutare anche a te.

Ho avuto questo problema anche usando Excel 2007 con una cartella di lavoro foobar.xlsm (abilitata per le macro) che avrebbe ottenuto "L'esecuzione del codice è stata interrotta" semplicemente provando a chiudere la cartella di lavoro sulla X rossa nell'angolo destro senza macro in esecuzione su tutte o qualsiasi forma di "inizializzazione" del modulo, cartella di lavoro o macro del foglio di lavoro. Le opzioni che ho ottenuto sono "Fine" o "Continua", il debug è sempre stato disattivato. Ho fatto come un precedente poster suggerito Pannello di controllo-> Programmi e funzionalità-> tasto destro del mouse "Microsoft Office Proffesional 2007" (nel mio caso) -> modifica-> riparazione.

Questo ha risolto il problema per me. Potrei aggiungere che questo è successo poco dopo un aggiornamento di MS e ho anche trovato un componente aggiuntivo in Excel chiamato "Team Foundation" di Microsoft che certamente non ho installato volontariamente

Vorrei aggiungere maggiori dettagli alla risposta n. 2 di Stan per i seguenti motivi:

• Ho affrontato questo problema più di una dozzina di volte e, a seconda delle condizioni del progetto, ho scelto tra la risposta magica voodoo n. 1 o n. 2 di Stan . Quando ho continuato ad affrontarlo di nuovo, divento più curioso del motivo per cui accade al primo posto.

• Vorrei aggiungere una risposta anche agli utenti Mac.

• Esistono limitazioni con entrambe queste possibili risposte:

  • se il codice è protetto (e non conosci la password) la risposta n. 1 non sarà di aiuto.
  • se il codice non è protetto, la risposta n. 2 non ti consentirà di eseguire il debug del codice.

1. Può accadere a causa di uno dei seguenti motivi:

   • Il sistema operativo non alloca le risorse di sistema al processo di Excel. ( Soluzione: è sufficiente avviare il sistema operativo: il tasso di successo è molto basso ma ha funzionato molte volte)

   • Il codice P è il codice intermedio utilizzato in Visual Basic (prima di .NET) e quindi viene ancora utilizzato nel VBA. Ha permesso un eseguibile più compatto a spese di un'esecuzione più lenta. Perché sto parlando di p-code? Perché a volte viene danneggiato tra più esecuzioni e file di grandi dimensioni o solo a causa dell'installazione del software (Excel) è andato danneggiato da qualche parte. Quando il codice p si corrompe. l'esecuzione del codice continua ad essere interrotta. Soluzione: In questi casi, si presume che il codice abbia iniziato a corrompersi e in futuro è probabile che anche la cartella di lavoro di Excel venga corrotta, dandoti messaggi come "il file Excel danneggiato e non può essere aperto". Quindi, come soluzione rapida, puoi fare affidamento sulla risposta n. 1 o sulla risposta n. 2 secondo le tue esigenze. Tuttavia, non ignorare mai i segni della corruzione. È meglio copiare i moduli di codice nel blocco note, eliminare i moduli, salvare e chiudere la cartella di lavoro, chiudere Excel. Ora, riapri la cartella di lavoro e inizia a creare nuovi moduli con il codice copiato in precedenza nel blocco note.

2. Gli utenti Mac, provare una delle opzioni seguenti e sicuramente funzioneranno a seconda dell'architettura del sistema, ovvero del sistema operativo e della versione di Office

   • Ctrl + Pause
   • Ctrl + ScrLk
   • Esc+ Esc(Premere due volte consecutive)

Verrà attivata la modalità di interruzione utilizzando le combinazioni di tasti sopra riportate poiché la macro sospende l'esecuzione terminando immediatamente l'attività corrente. Questa è la sostituzione del passaggio 2.

3. Soluzione: per superare la limitazione dell'uso della risposta n. 1 e della risposta n. 2 , utilizzo xlErrorHandlerinsieme Resumeall'istruzione nel gestore errori se il codice di errore è 18. Quindi, l'interrupt viene inviato alla procedura in esecuzione come errore, intercettabile da un errore gestore impostato con un'istruzione GoTo On Error. Il codice di errore intercettabile è 18. La procedura corrente viene interrotta e l'utente può eseguire il debug o terminare la procedura. Microsoft avvisa che non utilizzare questo se il gestore degli errori ha ripreso la dichiarazione, altrimenti il ​​gestore degli errori torna sempre alla stessa istruzione. Questo è esattamente ciò che vogliamo in indesiderate interruzioni insignificanti dell'esecuzione del codice.

La mia attuale reputazione non consente ancora di pubblicare questo come commento. Stans soluzione per accedere alla modalità debug, premere due volte Ctrl + Break, giocare, salvare ha risolto il mio problema, ma ho due colpi di scena inaspettati:

1. La struttura del mio progetto è protetta da password, quindi per entrare nella modalità debug ho dovuto prima entrare nella modalità sviluppatore, fare clic sulla struttura del progetto e inserire la password.

2. Il mio progetto è un file modello (.xmtl). Ho aperto il file con un doppio clic che lo apre come .xml con un "1" alla fine del nome del file precedente. Ho corretto il bug come da istruzioni Stans e l'ho salvato come quel file ... 1.xml. Quando ho aperto nuovamente il modello, questa volta come modello, e volevo applicare la stessa correzione di bug a quel file, il bug era sparito! Non ho modificato questo file e ancora nessun bug nell'esecuzione della Macro. Questo significa per me che il bug non si trova effettivamente nel file, ma in un'impostazione (nascosta) in Excel.

Il problema ora sembra riguardare Excel stesso

Reinstalla e correggi :) Altro che è difficile da dire.