如果你一直想學Excel的VBA，但是苦于沒有一個好的老師
Excel本身就提供這樣的幫助手段：錄制宏
錄制宏，將Excel操作直接映射成對應的VBA代碼
圖1 打開錄制宏
圖2 打開錄制宏
圖3 錄制宏名稱定義
圖4 排序前
圖5 排序后
Sub 宏1()
'
' 宏1 宏
'
'
Columns("F:F").Select
ActiveWorkbook.Worksheets("Sheet2").Sort.SortFields.Clear
ActiveWorkbook.Worksheets("Sheet2").Sort.SortFields.Add Key:=Range("F1"), _
SortOn:=xlSortOnValues, Order:=xlAscending, DataOption:=xlSortNormal
With ActiveWorkbook.Worksheets("Sheet2").Sort
.SetRange Range("F1:F18")
.Header=xlNo
.MatchCase=False
.Orientation=xlTopToBottom
.SortMethod=xlPinYin
.Apply
End With
End Sub圖6 代碼截圖
注：錄制宏無法實現循環，判斷功能，但很多操作代碼都是可以參考的
以上，為本次的介紹內容，下回見。
本文首發于微信公眾號：Excel高效辦公之VBA。排版和細節略作修改，發于頭條
VB/VBA更注重如何用，作為系統腳本更中！
在《VB/VBA為何不需要所謂的標準DLL？》中給大家伙解釋了什么是標準DLL，為何VB/VBA不需要這樣的標準DLL。簡單總結下，標準DLL就是導出了指定函數的DLL，方便直接通過函數指針的方式進行調用。在VB/VBA中呢，就是可以通過Declare機制進行聲明和使用。但VB/VBA通過COM接口，要遠比Declare方式高效靈活，所以VB/VBA不需要所謂的標準DLL。
Declare相關討論可以參考《VB/VBA的Win32API聲明中，不得不了解的真相》《來聊聊VB/VBA函數》《VB/VBA中Declare聲明API時，這樣用效率又會增加一點點哦！》...
但是VB/VBA是COM的語言，編譯的DLL天生就是ActiveXDLL，也即是說天然就會有4個標準的COM導出函數，那為何還在強調是否標準與否呢？網友一針見血地說，標準DLL才不是為了讓VB/VBA方便Declare呢，想想其他編程語言要怎么調用VB/VBA的DLL？這就是今天要跟大家分享的，『為何VB/VBA不需要標準DLL，其他語言也不需要VB/VBA的標準DLL?』。
《VB/VBA為何不需要所謂的標準DLL？》也解釋了利用COM接口，在VB/VBA的IDE中，通過對象+『.』，非常便捷，使用上也很高效。從使用Dll函數的角度，無論是Declare還是直接使用函數指針，這都是沒法比的。
Declare不僅需要自己寫聲明，而且會內建一套類導入表的機制。就為了避免用戶直接面對函數指針，可謂是繞了一大圈。要在VB/VBA中直接使用函數指針，方便是方便，但得懂如何用才行，不然也不會讓Declare處心積慮地隱藏它。
這顯然與VB/VBA的定位和用戶群，是不符的。但無論怎樣，最后大家都是奔向函數指針而去的，因為指令層面就認這個超級GOTO+行號(Call/跳+函數地址)。
前面也說了，ActiveXDLL會導出4個函數，這4個函數就是COM對象使用函數的關鍵，也同樣是奔著函數指針去的。事實上，其他語言使用DLL函數指針是通過導出/導入表，與COM對象使用成員函數的機制是一樣的，這便是VTable綁定。這是VB/VBA唯一可以和其他語言平起平坐講專業性的地方，不過很可惜，VB/VBA還是通過類和對象將其遮蓋得嚴嚴實實。
需要了解VTable相關知識點的朋友，請繼續關注后續文章，VB/VBA的很多高階用法都離不開這一機制，比如函數指針動態調用，處理C調約（調用C調約API，提供C調約回調函數），IDE和編譯均適用的嵌入匯編等。
VB/VBA的COM接口中的VTable綁定機制，不僅兼顧了源碼編寫上的便捷和高效（對應IDE的智能提示和自動補全），而且也同樣兼顧了代碼運行的高效率，與其他專業語言不相上下（比如C/C++）。所以，VB/VBA中確實是不需要所謂標準DLL的。
1、先問VB/VBA的先人BASIC是干什么的？
其實，一開始BASIC，就以教員的方式，盯著如何讓文科一類背景的人使用計算機，所以如何操作計算機便是后來VB的核心基因之一。這個使用當然不是專業程序員那般細膩的控制，而是在更粗糙的粒度上的操作體驗。早期的BASIC沒有現在的鼠標視窗環境，這種使用，大抵跟很多人心中的黑客風，是差不多的吧。
如果調整下字體和背景色，還以為是黑客在搞事！
要拿到現在，是不是會勸退很多人呢？但在那個年代，這已經很親民了，畢竟學生們不用刻意去負擔半導體專業知識也能讓機器跑起來。后來，微軟加入了鼠標驅動的視窗環境，BASIC再一次脫胎換骨為VB/VBA，以一夫當關萬夫莫開的氣勢，撐起了大家對Windows的好奇，微軟自然也贏得了小白們的選票，真正演繹了『得小白者得天下』的真理！
2、再問VB/VBA是什么？
如果說MS-DOS是微軟背靠IBM積累家底的量變階段，那后來的VB/VBA就是微軟翅膀硬了，與IBM分道揚鑣各奔前程的資本。以現在的計算機環境，是很難理解VB竟然這么牛叉的。相信不少上個世紀80/90年代過來的程序員，是很清楚當時編程的門檻有多高。
專業程序員，都是寶啊，可遇不可求的那種。突然來一個，拖拖拽拽，三五分鐘就可以弄個示例軟件出來的工具，那必然是爆炸性的。不僅僅因為可以在廣袤的普通百姓心里種下編程的種子，為后來的程序員職業的繁榮立下汗馬功勞。更因為微軟千方百計地通過VB，向廣大小白們演示著Windows的優越性。
要演示系統的優越特性，沒有方便之門怎么行。直到今天，仍然有不少老程序員認為，微軟為VB傾斜了太多的資源。甚至還有極端者認為，比爾-蓋茨只懂BASIC，而不惜改造C/C++規范，就只為VB能用上C/C++庫資源。雖然有點夸張，但對于VB/VBA而言，的確將系統的某些特性運用的爐火純青，這就是VB/VBA在Windows中扎根太深，而難以跨平臺的根本原因，同時也是Linux平臺上類BASIC語言難以超越VB/VBA，有其形而無其魂的原因所在。
后續會不斷分享VB/VBA是如何利用系統特性的，VB/VBA用戶又該如何使用這些特性來提升代碼的性能和編寫效率，歡迎關注哦！
VB/VBA一度是Windows功能的Demo工具，不僅有歷史的原因，更有歷史的機遇。一方面，當年BASIC的教學設計，就重在普適的人機交互，以BASIC起家的微軟，自然門兒清。因為說到底，再牛逼的技術和機器，也是要給人服務的。另一方面，背靠IBM的十余年間，BASIC不僅替微軟摸排了市場的真實需求（痛點），更為微軟培養了無數BASCI粉。所以，當微軟與將IBM分道揚鑣時，具有普適性（視窗+鼠標）的VB自然當仁不讓地挑起了大梁，并伴隨著Windows的不斷完善而得到改進。
其實，這是一個相互成就的過程，并非微軟一心偏袒VB。雖然，今天的VB/VBA確顯老舊，但不可否認VB/VBA一身武藝，都是實實在在的精華。這是不深入Windows和VB，就了解不到的真相。
《什么是腳本語言？為何VBA不算腳本語言？》便是VB的冰山一角，更多背景可閱讀《以史為鑒，編程語言，啟示錄之系統覺醒》《VB前傳，從教學到游戲，再到系統，似乎每步都是精心設計》等文章。
VB/VBA作為與系統相伴成長起來的可視化編程工具，是一個前可見古人，后不見來者的歷史遺產。筆者之所以，極力推薦那些沒有過多精力，但又想通過編程提升效率的職場人士學習VB/VBA，其實就是看中VB/VBA的這種系統功能的膠水能力。在Win上VB/VBA就是那個最強的膠水語言！
3、為何不需要VB/VBA的標準DLL？
弄懂了VB/VBA的背景，自然就好理解為何不需要VB/VBA來制造所謂標準DLL了。在前面說了，VB/VBA本身對標準DLL的需求并非不可或缺，大家責難VB/VBA無法輸出標準DLL，大抵是因為其他編程工具，用函數指針的方式來使用VB/VBA編譯的DLL函數時，不管用了！
這個原因，其實在前面的VTable關鍵字附近，已經回答了。不知道如何調用ActiveXDLL中的函數，純粹是不懂，而并非人家爛。更何況，VB/VBA在編譯時，可以導出函數。只是，筆者會認為VB/VBA的標準DLL，會和市場反應一樣，并沒有人需要。
作為系統特色的表演者，VB/VBA也只是個看菜下飯的家伙，眾物不過工具而已，拼湊才是她的本事。它保留了多種代碼執行模式，不僅可以作為命令行的終極宿主執行各種系統命令，也可以于碼海中隨意抽取逐句執行，更可以直接執行指定的機器指令。不僅面向過程，也面向對象，更有函數式。不僅用作腳本，自動化，輕代碼化，當好護花使者，也可以編譯獨立行走江湖。不僅有編譯器語句打底，更有內置函數、系統和非系統API的裝扮。不僅與所謂標準DLL耍朋友，更是與COM拜把子。但所有這些，都只不過保留了一種能力上的接口，并未過多修飾。
用過的人，都知道VB/VBA在語句和內置函數上表現出來的封裝性并不高，它甚至都無法做到IDE的代碼折疊。一方面VB/VBA容易使用，容易上手，另一方面VB/VBA又很難精通。所以，她注定無法在代碼的流水線上留下自己的職位。
同作為功能的膠水，自然可以拿大家公認的Python來做類比。Python的強大，是因為豐富的庫資源，和她的撮合能力。但是，有幾個直接拿Python去干輪子的？道理是一樣的，VB/VBA擅長的，是使用系統里面各色資源，而非制造資源。VB/VBA在使用上的安全性、包容性無一不是圍繞使用資源而展開的，在VB/VBA的編譯器（解釋器）里充斥著大量讓專業人士嗤之以鼻的模板化的指令，就意味著VB/VBA生而不為輪子，她是輪子的用戶！
道理還是一樣的，這貨制造的輪子，性能不咋地啊！雖然可以通過手術方式進行二次加工，讓其更優化，但已經脫離VB/VBA的高使用效率和低危錯誤的立身之本了。所以，其他語言不需要VB/VBA的標準DLL，VB/VBA也不打算提供標準DLL，就這么簡單！
歡迎關注BtOfficer（收藏、點贊、關注+轉發）,更多精彩仍在繼續哦（專欄文章將更系統，更全面，但需要閣下支持哦），有嚴肅的技術，也有輕松的嘮嗑，期待你的加入！