昨天在《學習LabVIEW（二）——操作.NET泛型類》給出的代碼，實際上是有錯誤的。按照我們的設想，首先調用了Add，將Key-Value對“eleven”-11放入了Dictionary中，然后調用TryGetValue，查找Key: "eleven"對應的Value。所以查詢必然應該是成功的。然而，反復執行昨天的代碼，偶爾會出現查詢失敗的情況，如下圖所示：


明明已經用Add添加了Key: "eleven"，為什么有時候會查詢失敗呢？原因在于我們使用了錯誤的觀念編寫LabVIEW程序。
傳統的計算機語言，本質上以指令的流動為核心編寫代碼，寫出來的代碼按照順序被一條一條執行。但是像LabVIEW和Simulink這樣的圖形化編程語言，是以數據的流動為核心構造程序的。當程序以數據的流動為核心構造時，有時指令的執行先后順序就不那么明顯了，甚至在不知不覺中一些指令會自動的被并行化執行。關于這一點我曾經咨詢過NI的客服，他們曾明確表示過，LabVIEW的運行時內部會自動利用多線程來處理可以并行執行的函數，無需用戶的干預。這是一個非常好的特性，而且也是非常符合圖形化編程這種以數據流動和核心的編程方式的特點的。
然而，當我們還是帶著以前的以指令為核心編程的觀念畫LabVIEW程序時，就會不知不覺犯下錯誤。昨天寫入和查詢Dictionary的代碼段如下圖所示：


看起來，從左到右執行的話，似乎Add是先于TryGetValue的。這實際上是圖形的繪制方式迷惑了我們。如果簡單調整一下各個節點的位置，如下圖所示：


以數據流動為核心的LabVIEW就不一定會先執行哪一個函數了。如果先執行的是TryGetValue，就會出現查詢失敗的情況。
現在應該怎么解決這個問題呢？LabVIEW以數據流動為核心的編程思想，一方面使自動化的并行編程稱為可能，另一方面，使“順序執行”成了一種需要顯示聲明的結構；這與傳統的語言是非常不同的，傳統語言寫代碼，一行一行的碼，一行一行的被執行，自然就是順序結構。
我們在工具箱的編程這一欄中找到了用以表示順序結構的工具：


用這個平鋪式順序結構將需要先于TryGetValue調用的部分框起來，如下圖所示：


這樣一來，只有框內所有的動作執行完成之后，數據才會繼續往下流動，于是再也沒有出現查詢失敗的情況了。