Windows UWP C#程式踩雷-TextBox元件

Windows UWP C#程式踩到雷了-TextBox元件,這元件居然有bug,有可能跟我使用最新版開發環境有關。

我使用visual studio 2022(17.14.0 preview 2.0) 開發uwp 藍牙程式,NuGet使用uwp 套件6.2,14(2022年6月)來開發藍牙用戶端程式,使用的範例在此,這範例限制作業系統需為windows 11 22h2版本以上,嚇死人啊,為了這個我也硬升級到此版本。

windows uwp C#開發程式很簡單,將範例程式拉下來,叫出工具箱加入想要的元件即可。

我這次加上TextBox元件,要讓掃描槍BarCode Scanner,將條碼掃到TextBox元件裡面,元件設定當內容變動(TextChanged)就會觸發程式,讓程式檢查內容。

條碼機將掃描的資料輸入到TextBox時,會觸發TextChanged程式檢查輸入內容長度為9,才會進行寫入序號任務。

windows uwp程式讓使用者測試一段時間。挖哩勒,使用者每次掃描條碼,程式都會重複執行寫入序號任務多次,理應只執行一次啊。剛好使用者覺得無所謂,一直都沒回報,直到幾周後才回報問題。

我連過去越南廠線上觀察,發現當地使用windows平板,掃描條碼時,會讓TextBox元件觸發多次一樣內容。

例如,掃描123456789這個字串,程式會觸發9次,每次內容為1(長度1)、2(長度2)…直至9(長度9);很可惜,實際上卻不穩定觸發,如,1(長度1)、9(長度9)、9(長度9)、9(長度9),造成程式秀逗,我在開發時卻沒有,很難歸納是掃描器輸入太快。

最後我只能用lock的方式解決(這每人解法不同,就不多說了)。

使用者升級到windows 11 22h2就頭痛了,這程式還特別挑藍牙硬體,應該是windowns藍牙驅動問題,安裝在筆電或是windows平板最穩定。

藍牙罩門UUID

關於藍芽SDP UUID解釋
需要到 www.bluetooth.org  裡面尋找有關 Service Discovery Protocol訊息

https://www.bluetooth.org/Technical/AssignedNumbers/service_discovery.htm

裡面提到 UUID分成BASE UUID 128bits 與 SHORT UUID(32bits, 16bits)

BASE UUID 格式如下:
00000000-0000-1000-8000-00805F9B34FB

SHORT UUID 再分成 UUID32(2的32次方) 與 UUID16(2的16次方)

UUID32 、UUID16 都是短款的格式

為了相容以往舊款 SDP UUI D格式
在BASE UUID前32bits即是UUID32 , 接下來16bits即UUID16

因此重看BASE UUID:
00000000-0000-1000-8000-00805F9B34FB
桃紅色加上綠色為UUID32, 綠色為UUID16

接下來我們想要使用程式註冊SPP, 透過serial port連線,
根據 www.bluetooth.org 的規範, 須將UUID改成
00001101-0000-1000-8000-00805F9B34FB