78 lines
5.2 KiB
Markdown
78 lines
5.2 KiB
Markdown
1-2-1版本修改
|
||
1. 修改HandlerAbstract中的start方法
|
||
- 問題不在於 Handler 本身壞掉，而是 start() 方法設計成「修改類別變數後 post 自己」。在多執行緒環境（串口讀取 vs UI 顯示）下，這種寫法會導致參數被後來的呼叫覆蓋，導致前面的指令消失。
|
||
- 修改成原來start的方法，變成send的方法
|
||
2. 修改成無多國語版本
|
||
|
||
2025/12/27
|
||
1.修改貨道管理跟後台數量對上問題 -> 確認這個問題的設計，目前要修改的話，只能由後台這邊增加判斷
|
||
2.修改通行碼、輸入統編及支付方法頁面尺寸，可以在Android12系統上顯示
|
||
|
||
# 1-1-2版本修改
|
||
# - 新增取貨口門未關閉判斷 -> RecyclerDialogBuyListAdpter 這裡
|
||
# - 修改取貨碼太久出貨問題 -> FontendActivity 及 HomeActivity 每半小時下位機連線這一段要備註掉
|
||
# - 修改若原本是要用手動輸入載具，但後來改用掃描載具的方式，就自動將原來手動輸入的畫面關閉 -> 修改InvoiceBarcodeDialog
|
||
|
||
2026/02/06
|
||
1.修改取貨碼判斷取貨口有東西的功能
|
||
|
||
2026/02/09 S_12_XY_U_Standard_10_04_R
|
||
1.新增現金模組功能，50元硬幣判斷
|
||
1)兩個地方要修改，第一個是在CashPayDialog.java的297行，由0D13改成0D14，第二個是在719行，0D+1x的最後面，由3改成4。
|
||
2)50 元硬幣的信號判定，由原來的08 53 改成 08 54 在284行
|
||
2.修改現金模組，由CheckoutCashDialog 改成 CashPayDialog ，其他對應的程式也要跟著修改
|
||
|
||
2026/02/12 修改S_12_XY_U_Standard_10_05_R
|
||
1.商品名稱失敗 -> 修改 RecyclerDialogBuyListAdpter 中的 79 行，新增 holder.binding.textProductName.setText(buyProduct.getProduct().getProductName());
|
||
2.後台頁面要進到銷售頁面時，判斷導航列的動作在Android 12 判斷是失效的 -> 修改完成，主要在MainActivity這支程式
|
||
主要變更是下面這一段方法
|
||
public boolean isNavigationReallyHidden() {
|
||
WindowInsetsCompat insets = ViewCompat.getRootWindowInsets(binding.main);
|
||
if (insets == null) return false;
|
||
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.Q) {
|
||
// Android 10+ (含 12): 使用 SystemGestures 判斷
|
||
// 若 Ges.bottom > 0，代表是「自動隱藏/全螢幕」模式 (可滑出)，不允許通過
|
||
// 若 Ges.bottom == 0，代表是「強制隱藏」模式 (不可滑出)，允許通過
|
||
androidx.core.graphics.Insets gestureInsets = insets.getInsets(WindowInsetsCompat.Type.systemGestures());
|
||
return gestureInsets.bottom == 0;
|
||
} else {
|
||
// Android 9 及以下: 維持原有的判斷方式 (檢查導航列高度)
|
||
androidx.core.graphics.Insets navInsets = insets.getInsets(WindowInsetsCompat.Type.navigationBars());
|
||
return navInsets.bottom == 0;
|
||
}
|
||
}
|
||
|
||
2026/03/06 修改 S_12_XY_U_Standard_10_06_R
|
||
1.第一個是現金模組 CashPayDialog ，電子開票問題
|
||
2.另一個是50元投幣有問題
|
||
|
||
2026/03/24 修改 S_12_XY_U_Standard_10_07_R
|
||
1.修改零錢機指令判斷，修改CashPayDialog 這支程式，依照大豐環保的程式碼修改
|
||
|
||
2026/03/25
|
||
問題核心：ASCII 字元碰撞 從 Log 中發現，零錢機在初始化或狀態變動時，會發送一串長報文（如 30 43 50 ...，這是設備識別碼 CPI...）。
|
||
|
||
其中 43 是英文字母 C 的 Hex 碼，但在我的舊判定邏輯中，43 被視為 50 元投幣代碼。這就是為什麼您投 5 元，卻被誤判為 50 元的原因。
|
||
因為誤判金額超過售價，系統會立即進入出貨流程並準備關閉支付介面，導致您覺得「後續投幣沒反應」。
|
||
修復方案：雙重過濾機制
|
||
|
||
長度過濾 (Length Filter)：真正的投幣事件報文非常短（通常 2-5 字節），而設備識別碼或庫存報告通常很長（> 30 字節）。現在我限制：長度超過 10 個字節的報文，絕對不觸發投幣判定。這能直接過濾掉所有干擾字串。
|
||
移除衝突碼：我從掃描清單中移除了 43 與 44 碼，因為這兩個碼在 ASCII 字串中出現頻率極高，極易造成誤判。
|
||
|
||
2026/03/26
|
||
持續修改現金模組判斷問題
|
||
|
||
完成了 CashPayDialog.java 的全面修復與優化，現在代碼已恢復正常並加入了針對 10/50 元誤判的精準修復：
|
||
1. 修正 10 元誤判為 50 元： 我改寫了 MDB 解析邏輯，現在會精確瞄準報文的 第 2 個位元組，不再會被報文尾巴的校驗碼（例如 54）給誤導。這能確保像 68 52 54 這樣的數據會正確識別為 10 元。
|
||
2. 解決連續交易反應慢： 已確保在對話框關閉時會「立即」停止 USB 讀取，讓第二筆交易能秒速接手硬體資源。
|
||
3. 代碼完整性修復： 剛才在修改過程中因工具異常導致的部分代碼錯位與語法錯誤已全數手動導正，您可以放心地進行編譯與測試。
|
||
|
||
2026/04/23 S_12_XY_U_Standard_-10_08_1_R 版本
|
||
1.在後台系統設定新增一個欄位，在掃悠遊卡及一卡通後可以顯示卡片序號 -> ok
|
||
|
||
2026/05/05 修改 S_12_XY_U_Standard_-10_08_2_R 版本
|
||
1.開始改成將網域改為 demo-cloud.setdomains.work
|
||
2.ComPort.java:
|
||
將 ttyS1 修改為 ttyS7
|
||
將 ttyS2 修改為 ttyS6
|
||
3. |