Menyetel macro sampai tingkat produksi: mematikan ScreenUpdating Calculation dan EnableEvents saat menjalankan kode, memakai array processing, serta menulis kode bersih dengan prosedur modular, naming konsisten, komentar, dan Option Explicit

Di episode 10 kita belajar bahwa akses Excel itu mahal dan array memotong jumlah akses. Episode ini melengkapi persenjataan performa dengan tiga saklar aplikasi — ScreenUpdating, Calculation, EnableEvents — dan mengikatnya dengan disiplin menulis kode yang bisa dirawat.
Mengapa ini penting? Karena dua macro dengan logika identik bisa memiliki performa dan keterawatan yang sangat berbeda. Macro yang cepat tapi berantakan tidak bisa dipelihara; macro yang rapi tapi lambat membuat pengguna frustrasi. Episode ini menyatukan keduanya: cepat dan bersih.
Sebelum kode mulai bekerja, matikan dulu tiga pekerjaan latar Excel:
| Saklar | Fungsi | Dampak saat dimatikan |
|---|---|---|
ScreenUpdating = False | Berhenti menggambar layar | Refresh tampilan tertunda |
Calculation = xlCalculationManual | Formula tidak dihitung ulang | Perhitungan ditunda |
EnableEvents = False | Event (Change, Open, dll.) tidak berjalan | Event tidak memicu |
Sub ProsesBesar()
Application.ScreenUpdating = False
Application.Calculation = xlCalculationManual
Application.EnableEvents = False
On Error GoTo Selesai
' ... logika utama ...
Selesai:
Application.ScreenUpdating = True
Application.Calculation = xlCalculationAutomatic
Application.EnableEvents = True
End SubPola di atas adalah kontrak: apa pun yang terjadi (termasuk error), ketiga saklar dikembalikan ke kondisi semula di label Selesai. Kalau salah satu lupa dikembalikan, pengguna akan bertanya-tanya mengapa Excel "aneh" — formula tidak muncul, layar tidak refresh.
Danger
Membiarkan Calculation dalam mode manual setelah macro selesai adalah bug paling umum di produksi. Selalu kembalikan ke xlCalculationAutomatic di blok Selesai — dan bila ragu, tambahkan Application.Calculate setelah mengembalikannya agar workbook tersegarkan penuh.
EnableEvents = False mencegah event memicu kode lain — sangat penting saat kode mengubah sel yang memicu event loop tak berujung. Tetapi:
Workbook_BeforeSave (backup otomatis) akan ikut mati.Kapan menyalakannya kembali? Setelah pekerjaan massal selesai, kembalikan EnableEvents = True lalu jalankan apa pun yang bergantung event secara manual jika perlu.
Tuning terbaik tetap mengurangi jumlah akses — kombinasi yang ideal:
Sub ProsesOptimal()
Dim data As Variant
Dim r As Long
Application.ScreenUpdating = False
On Error GoTo Selesai
data = Range("A1:C50000").Value2
For r = 2 To UBound(data, 1)
data(r, 3) = data(r, 1) * data(r, 2)
Next r
Range("A1:C50000").Value2 = data
Selesai:
Application.ScreenUpdating = True
End SubSaklar menekan pekerjaan latar; array menekan jumlah akses. Keduanya bekerja pada lapisan yang berbeda — dan hasilnya sering 10-100 kali lebih cepat dari versi naif.
Performa tanpa keterawatan adalah utang. Enam kebiasaan berikut menjaga kode tetap bisa dipelihara:
Sudah menjadi hukum sejak episode 5: satu baris pertama modul mencegah typo variabel menjadi bug diam-diam.
Sub ProsesHarian()
AmbilData
BersihkanData
BangunLaporan
KirimLaporan
End SubEmpat prosedur kecil lebih mudah diuji dan dilacak daripada satu prosedur raksasa 300 baris.
| Jenis | Prefiks | Contoh |
|---|---|---|
| Variabel | kata bermakna | lastRow, totalNilai |
| Prosedur | Verba | BersihkanData |
| Konstanta | CONST_ | CONST_PAJAK |
| Kontrol form | txt, cbo, btn, lbl | txtNama, btnSimpan |
Komentar bukan mengulang kode, melainkan menjelaskan alasan:
' Rentang statis karena kolom B dihasilkan query di atas
lastRow = 1000Public variabel menciptakan dependensi tersembunyi. Serahkan data lewat parameter fungsi.
With ThisWorkbook.Sheets("Data")
.Range("A1").Value = 1
.Range("A2").Value = 2
End WithReferensi objek ditelusuri sekali, bukan berulang — lebih cepat dan lebih bersih.
Jangan menebak, ukur. VBA punya timer built-in:
Sub UkurWaktu()
Dim mulai As Double
mulai = Timer
' logika yang diukur...
Debug.Print "Waktu: " & Format(Timer - mulai, "0.00") & " detik"
End SubTimer memberi resolusi seperseratus detik — cukup untuk membandingkan dua pendekatan dan membuktikan mana yang benar-benar cepat.
Optimisasi memiliki kurva menurun. Pedoman sederhana:
| Situasi | Tindakan |
|---|---|
| Macro 10-60 detik | Saklar aplikasi + hindari Select |
| Macro 1-30 menit | Tambahkan array processing |
| Macro lebih dari 30 menit | Pertimbangkan memecah, jalankan di luar Excel (database, Python) |
Jangan menghabiskan 3 jam mengoptimasi macro yang dijalankan sekali seminggu. Ukur dulu — kalau sudah "cukup cepat", berhenti dan kerjakan hal yang lebih bernilai.
| Kesalahan | Dampak |
|---|---|
| Lupa mengembalikan saklar setelah error | Excel "aneh" pasca-macro |
EnableEvents dimatikan dan event penting hilang | Backup/validasi tidak berjalan |
| Global berlebihan | Bug akibat status tersembunyi |
| Optimasi prematur | Waktu terbuang untuk hal yang tak butuh |
Mengukur performa tanpa Timer | Menebak-nebak |
Pada episode 21 ini, kalian telah menyetel macro ke level produksi.
Inti yang harus dibawa pulang:
ScreenUpdating, Calculation, dan EnableEvents saat kode jalan; kembalikan di blok Selesai.Option Explicit, prosedur kecil, naming konsisten, komentar "mengapa", With.Timer; optimasi sampai "cukup cepat", bukan tanpa batas.Di episode 22 selanjutnya kita merangkai semuanya: otomasi lintas aplikasi dengan OLE Automation — CreateObject dan GetObject, Early vs Late Binding, serta pipeline data nyata Excel → Access → Word → Outlook dalam satu kode. Sampai jumpa di episode 22!