錯誤修正｜ STK 進銷存管理系統

v2026.10 2026-10-21

遠端服務

手機拍照一直顯示「電腦目前連不上」,但電腦有開、影像伺服器也有開 →已查明原因(處理方式見「詳細處理」)

技術說明:手機拍照的指令要經過該台電腦的遠端服務程式(STK Agent)轉給影像伺服器。遠端服務程式會自動從網路磁碟 W: 更新自己;開機時如果 W: 還沒連上,它會改拿電腦本機 C:\STK\S00X 裡的那一支,而那一支可能是很久以前留下的舊版。舊版不認得拍照指令,手機就只看得到「電腦目前連不上」。之後 W: 恢復了,它也不會再換回新版,所以會一直失敗,重新開機也不會好

詳細處理

手機拍照網頁上方顯示「電腦目前連不上(電腦關機、影像伺服器沒開或遠端服務中斷)」,下方沒有出現任何格子

‧ 現象:在電腦上開「手機拍照」掃 QR Code 後,手機網頁可以開啟,但上方一直顯示「電腦目前連不上(電腦關機、影像伺服器沒開或遠端服務中斷)」,下面沒有出現任何格子(如右圖)。同一家其他電腦可以正常拍照,這台以前也拍過。

‧ 先排除:①該台電腦有開機、STK32 已查零件(Alt+M)讓影像伺服器出現;②重新開一次「手機拍照」並重新掃 QR Code。兩項都正常仍出現如圖畫面,就是下面的情況。

‧ 判斷:查看該台遠端服務程式的紀錄檔(C:\StkAgent\S00X\stk_agent.log),手機每次查詢都記「Unknown command: AWI_STATE」(不認得拍照指令),就是遠端服務程式被換成舊版。再比對檔案大小:C:\StkAgent\S00X 裡 Stk_Agent_A.exe 與 Stk_Agent_B.exe 一新一舊(大小不同),而 W:\S00X\Stk_Agent.exe 是新版;C:\STK\S00X\Stk_Agent.exe 是舊版(檔案日期很舊)。注意:遠端看到的版本時間是「檔案複製的時間」,不是程式版本,看起來像新的,要以檔案大小判斷。

‧ 處理:①把 C:\STK\S00X\Stk_Agent.exe 改名留存(例:Stk_Agent.exe.bak_old_日期_時間),再把 W:\S00X\Stk_Agent.exe 複製過去,讓兩個更新來源都是新版;②把 W:\S00X\Stk_Agent.exe 複製到 C:\StkAgent\S00X 裡「沒有在執行」的那一支(Stk_Agent_A.exe 或 Stk_Agent_B.exe,執行中的那支無法覆蓋),檔案日期就會變成最新,遠端服務程式的守護排程會在下一輪自動切換過去;③等約 5 分鐘,確認紀錄檔出現新版的啟動訊息,再請客戶重新掃 QR Code 拍一張。

‧ 不要只重新開機:守護排程是挑「檔案日期最新」的那支執行,被換上的舊版日期反而最新,重開機後還是舊版;開機時 W: 若又沒連上,舊版還可能把另一支新版也蓋掉。

‧ 根本修正(已修正,2026-10-21 隨遠端服務程式更新派送):W: 拿不到時,本機的備用檔必須比目前執行中的版本還新才採用,不再因為檔案大小不同就換上舊版。已更新的電腦不會再發生;還沒更新到的電腦若出現同樣畫面,仍照上面的步驟處理。

v2026.10 2026-10-20

畫面顯示

圖形登入畫面常常「不見」,其實是被其他程式或 STK32 主畫面蓋在下面 →已修正(隨下次更新生效)

技術說明:登入畫面原本是一個獨立的小視窗,和 STK32 主畫面沒有從屬關係,也沒有置頂;點到主畫面或開啟其他程式就會被蓋住。另外系統啟動較慢、使用者已經在操作別的程式時,Windows 會拒絕讓登入畫面跳到最前面,畫面就直接開在其他程式後面。現在登入畫面改為隸屬 STK32 主畫面、開著期間置頂顯示,不會再被蓋住

詳細處理

‧ 現象:啟動 STK32 後找不到登入畫面,看起來像沒有開;其實它被其他程式或 STK32 自己的主畫面蓋在下面。

‧ 解法:①登入畫面隸屬 STK32 主畫面,永遠顯示在主畫面上面,點工作列的 STK32 也會一起出現;②登入畫面開著期間置頂顯示,其他程式不會蓋住它,登入或取消後即恢復正常;③若 Windows 不允許切換到前景,工作列按鈕會閃爍提醒。

‧ 驗證:以修正前後版本對照測試:修正前登入畫面會被其他程式及主畫面蓋住,修正後兩種情況都維持在最上層;登入完成後主畫面操作正常。

‧ 上線方式:隨下次更新生效。

v2026.10 2026-10-19

系統維護

技術說明：報價單明細的金額欄位上限是 9,999,999.99。單價與數量各自都在範圍內，但相乘後超過上限時，寫入資料會失敗，程式直接中斷、跳出錯誤畫面。銷貨單在今年 8 月已經加上檢查，報價單當時沒有一起補上。現在報價單新增或修改明細時，會先算出這一列的金額，超過上限就跳出提示「單列金額超過上限 9,999,999.99，請檢查數量/單價」，並退回讓使用者重新輸入，不會寫進資料，也不會中斷

詳細處理

‧ 現象:客戶在報價單選零件的視窗新增一列時,程式中斷並自動送出錯誤回報;回報上這一列的金額是 34,020,000,超過欄位上限。

‧ 原因:金額欄位最多存到 9,999,999.99(七位數)。這通常是數量或單價打錯(多打了幾個 0),但程式沒有先檢查就直接寫入,寫不進去就整個中斷。

‧ 解法:新增明細與修改明細兩個地方,都在寫入前先檢查這一列的金額與折讓;超過上限時顯示提示並退回重新輸入,原本的資料不受影響。報價轉銷貨用的是已經存進報價單的金額,一定在範圍內,不需要另外處理。

‧ 上線方式:隨下次更新生效。

v2026.10 2026-10-12

影像伺服器

零件照片「移除圖檔連結」、換照片要等二、三十秒，還出現「還有 999 個零件也使用這張圖」→已修正（隨下次更新生效）

技術說明：移除照片之前，影像伺服器要先確認還有沒有其他零件也在用這張照片。以前的做法是把整個零件資料檔從頭到尾讀一遍：零件資料有十萬筆、一百多 MB，在主機上讀不到一秒，但工作站透過網路讀主機的資料要 24～28 秒，這段時間影像伺服器整個停住，用手機拍照存進零件也跟著卡住。讀到一半網路出錯時，程式又把錯誤顯示成「還有 999 個零件也使用這張圖」，這個數字是假的。現在改用零件的索引直接查，只看可能用到這張照片的那幾筆，透過網路也只要百分之一秒左右

詳細處理

‧ 現象:客戶反映影像伺服器換新外觀後,「移除圖檔連結」要等很久(以前一秒就好);用手機拍照存進零件也感覺很慢;慢的都是透過網路連到主機的工作站。

‧ 追查:從客戶工作站的影像伺服器紀錄看到,按下移除到處理完相隔 24 秒;手機照片存檔後到舊照片處理完相隔 28 秒,而手機照片本身傳輸只要約 1 秒,慢的不是傳輸。另有兩次讀檔錯誤,畫面因此顯示假的「999 個零件」。

‧ 解法:改用零件號碼、車種品名廠牌兩個索引,直接找出可能用到這張照片的零件再逐一比對;同一份零件資料透過網路實測 8～11 毫秒(舊做法同一環境約 0.9 秒,客戶的網路上 24 秒)。讀檔出錯時不再顯示假的數字。

‧ 同時改善:沒有零件在用的照片不直接刪除,改移到回收區保留 90 天,其他零件用得到時會自動搬回(見功能更新 2026-10-12)。

‧ 上線方式:隨下次更新生效(影像伺服器與 STK32 一起更新)。

v2026.10 2026-10-12

列印報表

工作站突然無法列印:新增印表機出現「存取被拒」、已刪除的印表機在列印視窗還看得到 →已解決(Windows 端修復,STK32 不需更新)

技術說明：這台電腦的 Windows 負責「連線網路印表機」的系統檔,被換成了不相容的版本(32 位元的 Windows 被放進 64 位元的檔案),導致它完全無法連到主機上的共用印表機;同時主機的印表機共用名稱也被改過,工作站原本的印表機指向一個已經不存在的名稱。兩條路都斷了,所以怎麼印都印不出來。換回原本的系統檔、重新以系統管理員身分連線主機印表機後即恢復正常

詳細處理

‧ 現象:某家客戶的一台工作站突然無法列印。STK32 送出的列印工作一直卡在佇列裡顯示「錯誤」;想在 Windows 重新新增印表機連接埠時,不管是一般方式還是用系統管理員身分,都跳出「存取被拒」。另外,在 Windows 已經刪除的印表機,STK32 的列印視窗裡卻還看得到。

‧ 追查:從遠端讀取這台電腦的列印紀錄,發現 Windows 每次開機都記下「無法載入網路列印元件(錯誤碼 0xC1)」。進一步檢查這個系統檔(win32spl.dll),發現它是 64 位元版本,而這台電腦的 Windows 是 32 位元 —— 32 位元系統根本無法載入 64 位元的檔案,所以這台電腦連線網路印表機的功能整個失效。原本的檔案被改名成 win32spl.dll.old 留在旁邊,看起來是有人用過網路上流傳的「0x0000011b 印表機修復工具」,工具放錯了版本。

‧ 第二個原因:主機上印表機的共用名稱曾經被改過(多了「(S001)」字樣),工作站上原本的印表機還指向舊名稱,送出的工作找不到地方去。

‧ 解法:①把被換掉的 64 位元檔案改名保留,換回原本 32 位元的檔案,重新啟動列印服務,錯誤紀錄不再出現;②主機的共用名稱改回原本的名稱;③因 2021 年後 Windows 規定建立網路印表機連線必須是系統管理員,以系統管理員身分重新建立指向主機的網路印表機,測試頁正常印出;④在 STK32 的〔印表機別名設定〕把「出貨單印表機」重新指向這台新的印表機。

‧ 為什麼刪掉的印表機還在:Windows 刪除印表機時,如果佇列裡還有沒印完的工作,會先標成「等待刪除」,等工作印完才真正移除;但這些工作送不出去、永遠印不完,所以重新開機也一直留著。清掉卡住的工作、重啟列印服務後即消失。另外,STK32 的列印視窗為了開得快,會把當天第一次查到的印表機清單暫存起來,當天中途增刪印表機要到隔天才會反映;已清除該暫存,下次列印即顯示正確清單。

‧ 後續改善:列印視窗的印表機清單已改成「發現印表機有增減就立即重新抓取」,不必等到隔天(已完成,隨下次更新生效)。

‧ 處理過程使用的指令:以下除了 ⑦ 在主機、⑫ 用一般權限之外,都是在該工作站以「系統管理員身分」開啟的 PowerShell 執行;# 開頭是說明。印表機名稱與主機名稱請依實際環境替換。

# ① 確認目前視窗真的有系統管理員權限(要看到 S-1-5-32-544 和 High Mandatory Level)
whoami; whoami /groups | findstr /i "S-1-5-32-544 Mandatory"
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System').EnableLUA

# ② 列出印表機、連接埠與列印錯誤紀錄(這一步看到「無法載入 win32spl.dll,錯誤碼 0xC1」)
Get-Printer | ft Name,Type,PortName,PrinterStatus -auto
Get-WinEvent -LogName 'Microsoft-Windows-PrintService/Admin' -MaxEvents 5 | ft TimeCreated,Id,Message -wrap
Get-Acl 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Ports' | fl Owner,AccessToString

# ③ 查主機上印表機真正的共用名稱
net view \\S001

# ④ 失敗的嘗試:新增本機連接埠 → 存取被拒(0x80070005),當時網路列印元件已壞
Add-PrinterPort -Name "\\S001\Epson LQ-680C(S001)"

# ⑤ 檢查系統檔是 32 還是 64 位元(0x014C = 32 位元、0x8664 = 64 位元)
$b=[IO.File]::ReadAllBytes('C:\Windows\System32\win32spl.dll'); $o=[BitConverter]::ToInt32($b,60)
'0x{0:X4}' -f [BitConverter]::ToUInt16($b,$o+4)
Get-ChildItem C:\Windows\System32 -Filter 'win32spl*' | ft Name,Length,LastWriteTime

# ⑥ 換回原本的 32 位元系統檔(錯誤的檔案改名保留,不刪除)
Stop-Service Spooler -Force
cd C:\Windows\System32
Rename-Item win32spl.dll win32spl.dll.bak_x64_20261012
Copy-Item win32spl.dll.old win32spl.dll
Start-Service Spooler

# ⑦ 主機端:印表機內容 →「共用」頁籤,共用名稱改回 Epson LQ-680C(也可用指令)
Set-Printer -Name 'Epson LQ-680C' -ShareName 'Epson LQ-680C'

# ⑧ 測試直接寫入主機印表機(結果:存取被拒,所以改走下一步的網路印表機連線)
cmd /c copy /b test.txt "\\S001\Epson LQ-680C"

# ⑨ 建立網路印表機連線(必須系統管理員;一般權限會出現 0x800702E4「需要提高的權限」)
Add-Printer -ConnectionName '\\S001\Epson LQ-680C'

# ⑩ 印一張 Windows 測試頁
rundll32 printui.dll,PrintUIEntry /k /n "\\S001\Epson LQ-680C"

# ⑪ 刪不掉的舊印表機:先清掉卡住的工作,再移除,重啟列印服務,設定預設印表機
Get-PrintJob -PrinterName 'Epson LQ-680C (S001)' | Remove-PrintJob
Remove-Printer -Name 'Epson LQ-680C (S001)'
Restart-Service Spooler -Force
(New-Object -ComObject WScript.Network).SetDefaultPrinter('\\S001\Epson LQ-680C')

# ⑫ 清除 STK32 列印視窗的印表機清單暫存(以使用者身分執行即可,下次列印自動重建)
Rename-Item "$env:TEMP\prnask_prncache.dat" prnask_prncache.dat.bak_stale

# ⑬ 最後在 STK32 按 Ctrl+P →〔別名設定〕,把「出貨單印表機」指定給 \\S001\Epson LQ-680C

‧ 如何清掉卡住的列印工作:印表機刪不掉、工作停在「錯誤」或「正在刪除」時,可以用新的〔列印佇列清除工具 print_queue_fix〕照選單按數字處理;或用系統管理員身分的 PowerShell 手動執行:

# 以系統管理員身分開啟 PowerShell,依序執行(印表機名稱請換成實際名稱)

# ① 看哪一台卡住:狀態有 PendingDeletion(等待刪除)或 Error,就是它
Get-Printer | ft Name,PrinterStatus,JobCount -auto

# ② 看卡住的工作(JobStatus 常見:Error、Deleting = 正在刪除)
Get-PrintJob -PrinterName 'Epson LQ-680C' | ft Id,DocumentName,UserName,JobStatus,SubmittedTime -auto

# ③ 取消這台的全部工作
Get-PrintJob -PrinterName 'Epson LQ-680C' | Remove-PrintJob

# ④ 工作停在「正在刪除」消不掉:重新啟動列印服務
Restart-Service Spooler -Force

# ⑤ 還在:強制清除(停服務 → 把佇列暫存檔搬走 → 啟動服務)
Stop-Service Spooler -Force
md C:\print_queue_backup -Force
Move-Item C:\Windows\System32\spool\PRINTERS\* C:\print_queue_backup -Force
Start-Service Spooler

# ⑥ 要刪掉的印表機:工作清空後再移除
Remove-Printer -Name 'Epson LQ-680C'

# Windows 7 沒有 Get-Printer / Get-PrintJob,可改用:
#   net stop spooler
#   move C:\Windows\System32\spool\PRINTERS\*.* C:\print_queue_backup\
#   net start spooler

‧ 自我檢查:若遇到「列印出現 0x0000011b」,請勿使用來路不明的修復工具替換系統檔,請直接與我們聯絡;若某台印表機刪不掉,先打開它的列印佇列把卡住的文件全部取消;主機的印表機共用名稱一旦更改,各工作站都要重新連線。

v2026.10 2026-10-11

系統維護

技術說明：10 月 8 日為了修正「年度統計在 100x30 畫面少了右邊兩位數」，我們把最下方合計列改成放不下時顯示「####」。其中查詢功能那一段改錯了一行：原本要換掉舊的合計寫法，卻把前一行「取得這一欄」的程式換掉了，程式在處理合計列時找不到欄位，因而跳出錯誤。現在已補回那一行並移除舊的合計寫法，查詢與合計顯示都恢復正常；其他使用同樣寫法的地方也已逐一檢查，只有這一處有問題。

v2026.10 2026-10-09

影像伺服器

主機已換成新版影像伺服器，工作站卻一直使用舊的 Java 版（IS.jar），手動切換也沒有作用 →已修正（隨下次更新生效）

技術說明：舊版影像伺服器是靠 Windows 的「開機自動啟動」捷徑開起來的，新版改由 STK32 啟動時負責開。STK32 會自動把舊的開機捷徑移走，但工作站上有一個捷徑放在「所有使用者共用」的啟動資料夾，必須有系統管理員權限才能移動，結果每次開機舊版都搶先開起來、佔住通訊埠，STK32 看到已經有伺服器在執行就不再開新版。而且移不走時程式仍然記成「已處理」，之後再也沒有重試。現在改成：STK32 啟動時若發現舊版在執行，就直接把它換成新版，不需要系統管理員權限，也不必去動那個捷徑

詳細處理

‧ 現象:主機（直接使用 C:\STK）已經是新版影像伺服器，但所有從網路磁碟（W:）使用 STK32 的工作站，仍然是舊的 Java 版；在工作站手動執行切換工具，跑完也沒有任何變化。多家客戶情形相同。

‧ 追查:從主機上各工作站目錄留下的切換紀錄比對：每一台都是「個人的開機捷徑移走成功，共用的開機捷徑『拒絕存取』」；工作站上 STK32 的紀錄裡，也完全沒有再嘗試切換的動作。

‧ 根因:①共用的開機捷徑需要系統管理員權限才能移動，一般權限移不走，每次開機舊版都先啟動、佔住通訊埠；②移不走時程式仍標記為「已處理」，從此不再重試；③手動執行切換工具時沒有用系統管理員身分，修改那個捷徑同樣被拒，所以看起來「跑完沒變化」。

‧ 解法:改由 STK32 在啟動時直接接手：若發現舊版影像伺服器正在執行，而且工作站目錄裡有新版，就結束舊版、啟動新版，等新版準備好之後才繼續後面的動作（例如開啟資料庫連線），確保照片能正常存檔。只會結束舊版影像伺服器本身，其他 Java 程式不受影響。不需要系統管理員權限，也不必到現場處理。

‧ 影響:每次開機後第一次開 STK32 時，會多等大約 3 到 4 秒完成切換；之後再開 STK32 不受影響。

‧ 驗證:模擬舊版佔住通訊埠的情況實測：舊版被結束、新版在 4 秒內接手；新版已在執行時完全不動作；選擇保留舊版的電腦（放有退回旗標）不會被切換；其他 Java 程式不會被誤關。

‧ 上線方式:隨下次更新生效，工作站下次開啟 STK32 時會自動換成新版，不需要另外操作。如有特殊原因要繼續使用舊版，可在工作站目錄放置 USE_JAVA.FLG。

v2026.10 2026-10-09

片語維護

修改「品名片語」的英文名稱後，國外到貨單依英文名排序的結果完全沒變，重排幾次都一樣 →已修正（隨下次更新生效）

技術說明：系統為了加快速度，會把「代碼 → 名稱」的查詢結果記在記憶體裡，同一個代碼只查一次檔案。但是當您在片語維護裡改掉名稱時，這份記憶體裡的舊名稱沒有被清掉，所以程式拿到的仍然是舊的英文名；而排序的第一個動作就是去查英文名，於是依舊名排序、順序當然不會變。現在改成：只要在片語維護畫面動過代碼表，就立刻清掉這份記憶，而且會通知其他電腦也一起清掉

詳細處理

‧ 現象:在「品名片語基本資料」改掉某個品名的英文名稱之後，回到國外到貨單執行「排序 → 英名」，順序和改之前一模一樣；重新排序很多次也沒有用。

‧ 追查:系統內其實早就寫好一支「清除名稱記憶」的程式，而且註解上寫明「代碼表維護異動後呼叫，讓名稱修改即時生效，否則沿用舊的直到程式重新啟動」。但全面搜尋後發現，這支程式從頭到尾沒有任何地方呼叫它——寫好了卻從來沒有接上。

‧ 根因:名稱記憶是跟著程式一起存在的，不清除就會一直留著。而排序的第一個步驟正是去查英文名，拿到的是舊的，於是「重新排序」等於拿同一份舊資料再排一次，順序當然不變。以備份檔比對確認，這個情形從 2026-06-06 下午（當初為了改善操作變慢而加入名稱記憶）之後就一直存在。

‧ 解法:在片語維護（車種／品名／品牌等）的存檔動作之後，一律清除名稱記憶。同時加上跨電腦的通知機制：A 電腦改了片語，B 電腦最多五秒內就會發現並清掉自己的記憶，不必重新啟動 STK32。另外一併修正：原本連「查不到這個代碼」也會被記住，導致您查過一個尚未建立的代碼、接著把它建起來之後，畫面上仍然是空白——現在查不到就不記住。

‧ 驗證:確認清除動作接在正確的存檔出口上；跨電腦通知的每一條失敗路徑（設定未就緒、通知檔不存在、網路不通）都設計成「維持現狀」，不會因為診斷機制反而拖慢正常作業。

‧ 暫時的作法:在本次更新生效之前，改完片語之後把 STK32 完全關閉再重新開啟，然後再執行一次排序即可；要在執行排序的那一台重開。

‧ 上線方式:隨下次更新生效，不需要調整任何設定。

v2026.10 2026-10-09

國外到貨單

國外到貨單重新開啟時，表身明細可能比實際筆數少顯示 →已修正（隨下次更新生效）

技術說明：單據的表頭會記住「這張單有幾筆明細」當作快取，開單時直接拿來用，不必每次重數。2026-08-03 為了加快進單速度，把「每次開單重數一次」改成「直接相信表頭的數字」；但表頭的數字如果因故不正確，就沒有任何機制會去發現並更正，畫面上就會少顯示幾筆。現在改成：只要程式本來就在重算金額小計（表示上次沒有正常收尾、資料不可盡信），就順便把筆數一起數出來並更正表頭。這個「順便」不會增加任何額外的讀取

詳細處理

‧ 現象:重新開啟既有的國外到貨單時，表身顯示的明細筆數有可能比實際存在的筆數少。

‧ 追查:比對程式的歷史版本，2026-08-03 為了解決「進單顯示第一頁很慢」，把開單時清除筆數快取的動作拿掉了，使得後續的重數步驟不再執行。原本設計的自我修復只在數字「溢位或為負」時才會啟動，救不到「數字合法但是錯的」這一種。

‧ 根因:表頭筆數變成唯一依據，而它沒有任何驗證。

‧ 解法:開單時若判定上次沒有正常收尾，程式本來就會重新加總金額、逐筆走過整張單的明細；現在在同一趟走訪裡順便計數，並把結果寫回表頭。因為是沿用既有的走訪，不會多讀任何一筆資料，速度不受影響。

‧ 同時強化:系統內的「單據筆數對帳」檢查原本必須整張資料表從頭掃到尾，資料量大的公司（四十萬筆以上）要花好幾分鐘，因此被設了五萬筆的上限——結果就是最需要這項檢查的大公司反而從來沒有被檢查過。現在改成只讀取該張單所在的那一小段，與資料表總筆數無關，上限因此取消。經過七百多張單據的逐張比對驗證，結果完全一致。

‧ 驗證:以一百零九萬筆與五十萬筆的實際資料，逐張比對新舊兩種算法的筆數與金額，全部相符；無法完整檢查的極少數單據（約萬分之一）一律回報「未檢查」，不會產生錯誤的警告。

‧ 上線方式:隨下次更新生效，不需要調整任何設定。

v2026.10 2026-10-09

自動更新

主機更新完成後，桌面 STK32 圖示右下角的「新」字一直不消失（工作站正常） →已修正（隨下次更新生效）

技術說明：「新」字是用來提醒有新版本的，更新完成後應該自動消失。負責切換圖示的程式只會到網路磁碟（W:）查看提醒記號，但主機是直接使用本機的 C:\STK，沒有這個網路磁碟，程式一檢查就跳過，主機的圖示因此一直停在「新」字版。現在主機改為查看本機上的提醒記號，更新完成後就會自動換回原本的圖示

詳細處理

‧ 現象:在主機上執行更新、而且更新成功之後，主機桌面 STK32 捷徑右下角的「新」字一直不消失；同一家公司的其他工作站，「新」字在更新完成後都正常消失。

‧ 追查:從各台電腦的紀錄比對：更新程式確實清除了「有新版本」的提醒記號，四台工作站在更新完成的同一分鐘都把捷徑圖示換回原樣；唯獨主機從 10/05 換上「新」字之後，就再也沒有任何動作。主機桌面上的 STK32 捷徑，圖示也確實還停在「新」字版。

‧ 根因:工作站是透過網路磁碟（W:）使用 STK32，主機則是直接使用本機的 C:\STK。負責切換圖示的程式原本只會到網路磁碟去看提醒記號，主機上沒有這個網路磁碟，程式一檢查就直接跳過，所以主機的圖示換上「新」字之後就再也換不回來。

‧ 解法:主機改為直接查看本機上的提醒記號（更新程式本來就是在這裡建立和清除記號），更新完成後圖示會自動換回；工作站維持原本的做法。同時加強保護：修改捷徑前一律先確認 STK32 程式確實存在，找不到就不修改，避免捷徑被改壞而打不開。

‧ 驗證:以實際客戶的紀錄與捷徑內容確認原因；修正後在測試環境實跑：程式存在的捷徑會正確換回原本的圖示，程式不存在的捷徑完全不會被修改。

‧ 附註:如果更新時有站台還開著 STK32，更新會中止、版本沒有換成功，這時「新」字留著是正確的提醒；請所有站台退出 STK32 後再執行一次更新。

‧ 上線方式:隨下次更新生效，生效後主機的「新」字會在幾分鐘內自動消失。若想立刻恢復，可在捷徑按右鍵 →「內容」→「變更圖示」，選回 STK32 程式本身。

v2026.10 2026-10-08

查詢統計

年度統計（銷貨淨額／進貨淨額／銷售毛利）在 100x30 畫面下，每月金額和最下方合計都少了右邊兩位數 →已修正

技術說明：100x30 畫面的欄位比 80x25 窄一些，金額放不下時，畫面原本是把右邊的數字砍掉，於是 2,760,647 變成 27,606，看起來像正常的數字、其實是錯的。現在改成先去掉數字前面的空白再靠右顯示，放得下就完整顯示；真的放不下會顯示「########」提醒把欄位拉寬，不會再出現被截短的錯誤數字

詳細處理

‧ 現象:進入「年度統計」的銷貨淨額、進貨淨額、銷售毛利統計，切到 100x30 畫面後，每個月的金額少了最後兩位數，最下面的合計列也一樣；80x25 畫面正常。

‧ 根因:100x30 的版面為了一次看到更多月份，月份欄寬是 8 格；金額欄位本身是 10 位數，顯示時前面會補空白湊滿 10 格。系統其他畫面在欄位不夠寬時，都會先去掉前面的空白、讓數字靠右，唯獨統計視窗沒有做這一步，結果 10 格的內容硬塞進 8 格，被切掉的是右邊兩位。合計列是另外一段程式產生的，也有同樣的問題。

‧ 解法:統計視窗的每月金額和合計列，都改用和其他畫面相同的顯示方式：先去掉前導空白再靠右顯示。7、8 位數的金額在 8 格欄位裡可以完整顯示；超過欄寬時顯示「########」，請把該欄拉寬即可（拉寬欄位的問題也一併修好了，見同日另一筆）。

‧ 驗證:以 2,760,647 測試：修正前顯示「27606」，修正後完整顯示「2760647」；9 位數放進 8 格時顯示「########」而不是被截短的數字。

‧ 上線方式:隨下次自動更新生效，不需要另外設定。

v2026.10 2026-10-08

畫面顯示

統計視窗拖曳欄位分隔線調整欄寬時，被調整的卻是左邊隔壁那一欄 →已修正

技術說明：程式原本是從視窗最左邊依序累加各欄寬度，推算滑鼠點到的是哪一條分隔線。但欄位總寬度填不滿視窗時，畫面會在凍結欄（年）後面多留空白，而且這個視窗有一欄刻意不畫分隔線，推算的位置因此全部對不上，最後改到隔壁欄。現在改成直接讀取每一欄在畫面上的實際位置來判斷，不論怎麼排列都準確

詳細處理

‧ 現象:在年度統計視窗用滑鼠拖曳某一欄右邊的分隔線想調寬度，結果變寬或變窄的卻是它左邊那一欄；在 100x30 畫面特別明顯。被誤調窄的金額欄，又會造成同日另一筆「少了右邊兩位數」的狀況。

‧ 根因:畫面元件在欄位不夠填滿視窗寬度時，會自動在凍結欄後面補空白（沒有凍結欄時則整組置中），而原本的判斷方式假設所有欄位都從視窗最左邊緊密排列；再加上統計視窗的第 2 欄刻意不畫分隔線，推算出的位置全部落空，程式只好改用備用的判斷方式，結果偏了一欄。

‧ 解法:改成逐欄讀取畫面上的實際起始位置，再判斷滑鼠點的是哪一欄右邊的分隔線；拖曳欄位標題換順序也改用同樣的方式。

‧ 驗證:在三種排列情況（統計視窗的實際配置、欄位很少置中、沒有凍結欄）下，逐條掃描畫面上的分隔線位置比對：新版每一條都對到正確的欄，舊版全部判斷失敗。

‧ 上線方式:隨下次自動更新生效。之前被誤調窄的欄位寬度仍保留在設定中，修正後直接拖曳分隔線即可調回。

v2026.10 2026-10-08

系統維護

資料庫工具 DBX32：修改資料表結構（例如新增欄位）按 F2 套用後程式當掉 →已修正

技術說明：套用新結構時，程式在重新開啟資料表後要重建索引，但重新開啟用的是「共用」模式，而重建索引必須「獨佔」使用，於是發生錯誤；原本寫好的「失敗就還原」又因為缺少一行設定而從未生效，程式直接結束。現在改成先獨佔開啟重建索引、再用共用模式開回來，出錯時也會確實把原檔還原

詳細處理

‧ 現象:在 DBX32 開啟有索引的資料表，進入「修改結構」新增欄位後按 F2 套用，程式立刻關閉，錯誤紀錄寫著「Exclusive required（需要獨佔）」。

‧ 根因:①重建索引必須獨佔使用資料表，但程式重新開檔時用的是共用模式；②程式雖然寫了「套用失敗就把原檔還原」的保護，卻少了讓這段保護真正接手錯誤的設定，所以任何錯誤都會直接讓程式結束，保護從來沒有執行過。

‧ 解法:重新開檔改為先獨佔、重建索引後再以共用模式開回；補上錯誤接手設定，失敗時會還原原檔與索引並清除暫存檔；檔案被其他程式（例如 STK32）開著而無法改名時，會中止並還原，不會留下改到一半的檔案。

‧ 附帶改善:套用前會檢查欄位名稱是否重複或空白。原本新增一個已經存在的欄位名稱（例如資料表裡已有 CAMNAME 又再加一個 CAMNAME），會建出有兩個同名欄位的資料表，之後只讀得到第一個；現在會直接提示「欄位名稱重複」並且不套用。

‧ 驗證:用實際資料表的複本測試：修正前同樣的操作重現了錯誤；修正後新增欄位成功、索引重建完成、筆數一致。

‧ 上線方式:隨維護工具更新提供。

v2026.10 2026-10-08

系統維護

資料庫工具 DBX32：按 Alt+C「複製到」，程式直接關閉 →已修正

技術說明：Alt+C 是開發工具內建的「中斷程式」按鍵，在程式讀到這個按鍵之前就先把程式結束了，所以連錯誤紀錄都沒有。現在已關閉這個內建中斷鍵，Alt+C 會正常打開「複製到」功能

詳細處理

‧ 現象:在 DBX32 瀏覽資料時按 Alt+C 要把資料複製到另一個檔案，程式立刻消失，錯誤紀錄也是空的。

‧ 根因:程式開發工具預設把 Alt+C 當成「中斷執行」的快速鍵，按下去會在程式處理按鍵之前直接結束程式。

‧ 解法:程式啟動時關閉這個預設的中斷鍵，Alt+C 改由「複製到」功能正常處理。

‧ 驗證:修正前按 Alt+C 兩次都直接關閉；修正後不會關閉，正常進入複製流程。

‧ 上線方式:隨維護工具更新提供。

v2026.10 2026-10-08

系統維護

資料庫工具 DBX32：開啟檔名含空白或中文的資料檔（例如「XXX - 複製.DBF」），一關檔程式就當掉，之後每次開啟 DBX32 都會報錯 →已修正

技術說明：DBX32 原本直接拿檔名當作資料表在程式裡的代號，但代號只能用英文、數字和底線，檔名裡的空白、「-」和中文都不合法：開檔時就已出錯但仍被登記成已開啟，關檔時找不到這個代號而當掉；又因為程式會記住上次開的檔，每次啟動都再錯一次。現在會把檔名轉成合法的代號，關檔前也會先確認，不會再當掉

詳細處理

‧ 現象:用 Windows 複製檔案產生的「XXX - 複製.DBF」，在 DBX32 開啟後一關閉就當掉；重新開啟 DBX32 時因為會自動重開上次的檔案，又再跳一次錯誤。

‧ 根因:資料表在程式中的代號直接取自檔名。代號不能含空白、符號或中文，開檔時出錯卻沒有擋下，檔案仍被列為已開啟；關檔時用這個不合法的代號去找資料表找不到，程式就當掉了。

‧ 解法:開檔時自動把檔名轉成合法代號（空白、符號、中文換成底線，例如「DelSub - 複製」→「DelSub_______」）；兩個不同檔案轉出相同代號時自動加上 _2、_3 區分；關檔前先確認代號存在。

‧ 驗證:修正前同樣的檔名開檔與關檔各重現一次錯誤；修正後開檔、關檔、重新啟動自動重開都沒有任何錯誤。

‧ 上線方式:隨維護工具更新提供。

v2026.10 2026-10-05

系統穩定

重建索引、壓縮資料時，程式偶爾突然整個消失（只跳出「Abnormal program termination」），同樣的資料再做一次又正常 →已修正

技術說明：這是一個「看起來是索引出問題、其實兇手在別處」的案例。真正的原因是：STK32 裡負責把指令送給影像伺服器的背景小幫手，和主程式共用了一塊「不能兩邊同時使用」的記憶體。平常兩邊很少同時動作，但重建索引時主程式會大量使用記憶體，若剛好碰上小幫手在等影像伺服器回應，記憶體就會被寫壞，程式被系統強制中止。現在背景小幫手改用 Windows 本身提供、可以同時使用的記憶體，兩邊不再互相干擾

詳細處理

‧ 現象:在「索引資料 → 全部資料」或壓縮資料時，程式偶爾突然整個關掉，畫面只留下一行英文「Abnormal program termination」。沒有任何錯誤訊息，系統的錯誤紀錄也是空的；而且同一台電腦、同一份資料，再做一次又完全正常，時好時壞，無法預測。

‧ 為什麼這麼難查:這個問題處處誤導人。①畫面停在哪一個檔案是假象 —— 重建索引時畫面會延後更新，真正出事的位置早就往後跑了；②每次死在不同的檔案（零件、零件索引、庫存……），看不出規律；③它不是一般的程式錯誤，是被系統直接中止，所以平常用來留下錯誤資訊的機制完全攔不到；④它是從 10/02 影像系統改用新的直送方式之後才開始出現，但影像伺服器是另一支獨立的程式，怎麼看都不應該影響到 STK32 的索引。

‧ 追查過程:第一步，在重建索引的每一個步驟加上記錄，把「出事的範圍」從整段索引縮小到少數幾行；第二步，讓程式在被中止的那一刻自動留下現場資料（當機快照），分析後確定是「記憶體被寫壞、被系統偵測到而中止」，出事的地方只是剛好被抓到的位置，並不是寫壞記憶體的元兇；第三步，比對時間發現每一次當機都發生在影像相關動作之後 0～1 秒內；第四步，用同一份資料在測試環境做對照實驗：影像功能開著，33 次裡當了 3 次；影像功能關掉，30 次 0 次 —— 兇手鎖定在影像這條路上。

‧ 真正的原因:STK32 送指令給影像伺服器時，是交給一個「背景小幫手」在旁邊處理，主程式不必停下來等。問題在於這個小幫手和主程式共用同一套記憶體管理，而這套管理方式只適合一個人用，兩邊同時使用就可能互相寫壞。10/02 改用新的直送方式後，小幫手每次要等影像伺服器回應約 0.2～0.3 秒，正好落在重建索引大量使用記憶體的時間裡 —— 所以影像伺服器本身沒有錯，是它讓 STK32 自己的小幫手「在最忙的時候出現」。

‧ 解決方法:背景小幫手改用 Windows 本身提供、可以多方同時使用的記憶體，不再和主程式搶同一套；印表機查詢紙張大小的另一個背景小幫手也有同樣的寫法，一併改好。其他會派送到客戶端的程式（列印程式、影像伺服器、截圖工具、客服指揮台）都逐一檢查過，不受影響。

‧ 驗證結果:在測試環境，修正前 33 次當 3 次，修正後同樣條件做了 90 次，0 次當機；在實際發生問題的客戶現場，換版後重建索引 2 次、壓縮 2 次，再把 1,049 筆詢價單逐筆瀏覽並顯示圖片，全部正常（修正前這兩種操作都會撞到這個問題）。

‧ 附帶改善:這次加上的「當機自動留下現場資料」與「索引步驟記錄」會繼續保留，萬一日後再有類似狀況，可以直接從記錄看出發生在哪裡，不必再等它重複發生；系統記錄檔滿 3MB 時也改成把前一段另存保留，不再整份清空。

‧ 上線方式:隨下次自動更新生效，不需要另外設定。

v2026.10 2026-10-05

資料安全

報價單存好之後，在彙總視窗（單號欄按 Shift+?）找不到這張單，但明細其實都還在 →已修正（隨下次自動更新生效）

技術說明：新開報價單時，表頭是在存第一筆明細的同時建立的。原本建立表頭時沒有確認是否真的寫進檔案，少數情況下表頭沒寫進去、明細卻已存好，這張單就從彙總視窗消失。本次加上確認，沒寫進去會立刻停下來讓使用者選擇重試或中止，中止時連同剛輸入的那一筆一起撤回，不會再留下找不到的單

詳細處理

‧ 現象:新開的報價單打完、存好之後，在報價單號欄按 Shift+? 開啟彙總視窗，卻找不到這張單；但用單號查明細，明細都還在。

‧ 追查:比對資料檔：當天報價單的表頭記錄是一筆接一筆連續存放的，唯獨這張的表頭從來沒有寫進去（前一張之後直接就是下一張），不是被刪除，也不是被別張蓋掉；它的明細則完整地存在前後兩張單之間。

‧ 根因:新開報價單時，系統是在存第一筆明細的同時建立表頭。原本建立表頭時沒有確認是否真的寫進檔案就直接填資料，在多台電腦同時存檔等少數情況下，表頭可能沒寫進去，明細卻已經存好，這張單就從彙總視窗消失了。

‧ 解法:建立表頭時加上確認：沒寫進去就立刻停下來，讓使用者選擇「重試」或「中止」。選中止時，會把剛輸入的那一筆明細一起撤回、金額退回，請使用者重新輸入，不會再留下「有明細、找不到單」的報價單。發生時也會留下紀錄，方便追查。

‧ 附記:查這件事時，同時發現前一版的報價單在新增明細時，每一筆都會多存一筆空白的記錄（不影響畫面與金額，但會佔用空間），已一併修正；已經產生的空白記錄會再另行清理。這次遺失表頭的報價單已協助客戶補回。

v2026.10 2026-10-04 最新

截圖工具

awiCapture 截圖工具已隨更新送到各站台，但工作站開啟 STK32 時沒有跟著啟動 →已修正

技術說明：awiCapture(截圖、錄影、剪片工具)會隨 STK32 的自動更新送到每一台電腦，原本的設計是「開啟 STK32 時順便把它帶起來，放在畫面右下角待命」。不過這個「開啟時順便啟動」的設定原本預設是關閉，而且每一台站台各有自己的一份設定 —— 除非逐台打開，否則程式雖然已經送到，開 STK32 時並不會出現。更不容易發現的是，設定關閉時系統完全不留紀錄，從紀錄上分不出是「設定沒開」還是「程式沒送到」。現在預設改為開啟，設定關閉時也會留下紀錄。

詳細處理

・現象:主機上看得到 awiCapture，工作站開了 STK32 卻沒有；檢查後工作站的程式檔確實已經送到

・原因:各站台設定都是「不啟動」，STK32 啟動時直接略過，也沒有寫下任何紀錄

・ 改法一:「開啟時啟動截圖工具」預設改為啟動(新站台的設定、設定工具的預設值都一併改好)

・ 改法二:設定為「不啟動」時，系統紀錄會寫下一行「設定為不啟動」，日後一看就知道原因

・ 已經設定過的站台:原本的「不啟動」會保留，可以在設定工具中一次改成「啟動」；不需要截圖工具的電腦，也可以單獨設回「不啟動」

v2026.10 2026-10-04

系統維護

少數站台在遠端管理清單中不顯示 IP，更新時被整台略過 →已修正

技術說明：站台的連線程式在開機時就啟動，如果那一刻網路還沒準備好，它會取不到本機 IP；問題在於這個「空白」結果被記了下來，而重新查詢的條件是「過了五分鐘且沒有人在操作電腦」—— 主機整天有人使用，等於永遠不會重新查，空白就這樣卡住一整天。期間所有需要 IP 的派送（例如辨識元件）都會跳過那一台，而且不會報錯，不容易發現。

詳細處理

・現象:遠端管理清單中該站台的 IP 欄位空白，更新紀錄出現「has no IP, skip」

・驗證:該台電腦本身網路完全正常；重新啟動連線程式後立刻恢復，確認是記錄問題而非取值問題

・改法:取得到 IP 時行為完全不變；取不到時改為最多一分鐘重試一次，且不受「有人在操作」影響

・附帶:真的取不到 IP 時會留下診斷紀錄，日後同類問題可直接查明原因，不必到現場

v2026.10 2026-10-04

自動更新

更新失敗時只顯示「失敗 1 項」，查不出是哪個檔案出問題 →已改善

技術說明：系統更新時會檢查並調整資料檔結構，掃描的是整個目錄下的所有檔案。原本若其中任何一個檔案打不開，只會回報「失敗 1 項」，既看不出是哪一個檔，也沒說明失敗原因，必須請人到現場逐一檢查。另外提示訊息指向的紀錄檔並不是真正記載明細的那一個，查問題時容易繞路。

詳細處理

・ 改善一:打不開檔案時會一併記下原因與系統錯誤碼，可直接分辨是檔案損壞、被其他程式占用、還是索引毀損

・ 改善二:主要紀錄檔會補上「成功幾個、略過幾個、失敗幾個」，並指向真正記載逐檔明細的紀錄檔

・ 改善三:新增排除清單，可指定不需要處理的檔案。原本只要有一個檔案長期打不開，該客戶的更新就會每一輪重複失敗、版本永遠無法前進

・ 實際案例:某客戶有兩個版面檔無法開啟，導致每次更新都顯示失敗；其餘 396 個檔案其實全部正常

v2026.10 2026-10-03

進銷存作業

技術說明：背景代理程式會回報自己的內網 IP，派送大型安裝檔(例如文字辨識、瀏覽器元件)時要用到。它為了不拖慢操作，取得 IP 後會記住 5 分鐘，而且「有人正在用電腦時」一律沿用記住的值。問題是取不到的空值也被記住了：開機當下網路還沒就緒 → 記成空白 → 主機整天有人在用 → 永遠不重新取得。現在取不到 IP 時最多 60 秒就重試一次，不受「有人在用」影響；取得到之後的行為完全不變。

詳細處理

・現象:更新紀錄出現「S001 沒有 IP，略過」，所有需要 IP 的派送都跳過主機，而且不會報錯

・ 確認方式:那台電腦的網路設定完全正常；把背景程式重新啟動後立刻正確回報 IP —— 確定是「記住了空值」而不是取值的方法有問題

・另外:真的取不到任何 IP 時會記下診斷資訊，方便查出網路設定哪裡不對

v2026.10 2026-10-02

資料安全

開啟既有單據時，明細筆數與表頭記載對不上（索引異常或明細短少） →已加上自動核對

技術說明：單據表頭本來就記著「這張單應該有幾筆明細」，但過去一旦對不上，沒有任何機制會察覺，往往要到出貨或對帳時才發現。現在開啟舊單時會自動核對一次，並且自動分辨是「索引壞掉、資料其實還在」還是「明細真的少了」—— 這兩種情況的處理方式完全不同，過去只能靠人工逐筆比對才分得出來。預設只留紀錄、不打斷作業，不會干擾您開單。

詳細處理

・ 判斷方式:以「照索引清點」與「不經過索引、直接清點資料」兩邊對照為準。表頭記的數字只是暫存值，開單途中本來就可能還沒更新，單看它會誤判

・ 索引異常:紀錄會直接寫明「資料還在，索引讀不到」，執行索引重整後再試一次即可

・ 表頭沒跟上:資料本身正確、只是表頭數字還沒更新，這種情況不算異常，只留一行紀錄

・ 不會拖慢作業:明細筆數超過設定上限時自動略過重新清點，避免開單途中停頓

・ 預設不中斷:確認長期沒有誤判之後，才會考慮開啟「中斷作業」模式

v2026.10 2026-10-02

資料安全

報價轉銷貨時明細沒有全部轉過去，要到出貨或對帳才發現 →已加上完整性檢查

技術說明：轉單完成後，系統會回頭確認明細是否真的全部寫進銷貨單。過去程式只要「認為」自己寫完就算成功，萬一資料沒有真正寫入也不會有人察覺，往往要等到出貨或對帳時才發現少了東西，那時現場早就過去了。現在只要數目不符就會當場提示，請您刪單重轉。

詳細處理

・ 比對基準:比的是「本次實際要寫入的筆數」與「實際寫入成功的筆數」，所以只勾選部分項目的部分轉單不會誤報

・ 不影響速度:先用索引快速清點，只有在對不上時才付出代價重新細查，正常轉單幾乎沒有額外負擔

・ 留存紀錄:不符時記下報價單號、銷貨單號、應寫入與實際寫入的筆數，方便事後追查

v2026.10 2026-10-02

資料安全

兩張報價單指向同一張銷貨單（轉單後回寫註記寫到別張） →已加上防護

技術說明：轉單完成後，系統要回到報價單上註記「已轉出」與對應的銷貨單號。這個動作萬一寫錯位置，註記就會落到別張報價單上。現在回寫之前會先確認目前停留的確實是原來那一張報價單，不是才動手，並把確認結果一併記錄下來。

詳細處理

・ 目前狀況:只確認了現象，還沒抓到是哪一步造成記錄位置被移動，所以先加上防護避免再次寫錯，同時留下紀錄繼續追查

・做法:回寫前比對目前位置是否仍是原報價單，不符就不寫入並留下紀錄

v2026.10 2026-10-02

畫面顯示

技術說明：報表檔尾有一個「換頁」指令，而判斷「後面還有沒有東西要印」的那段程式不認得它，把換頁指令本身當成了內容，於是又開了一張新紙；接著真正處理換頁的地方發現新紙是空的、正確地沒有再換頁，於是那張空白紙就留了下來。只有在內容剛好印到頁面最底下時才會發生，所以不是每張報表都看得到。

詳細處理

・現象:列印或預覽時最後多一張空白頁，實際列印會多吐一張紙

・ 為什麼以前修過還會再發:同一個判斷有兩個入口，先前只補了其中一個，另一個遲早會漏出來

・ 一併修正:實際列印與畫面預覽兩條路徑都改用相同的判斷，不會再有一邊對一邊錯

・驗證:同一份報表修正前 2 頁、修正後 1 頁，內容逐字相同；另取 13 份多頁報表回歸，頁數全部不變

v2026.10 2026-10-02

查詢統計

客戶檔的清單快查，找不到代號排在最後面的客戶（例如 Z 開頭）→已修正

技術說明：資料其實有找到，是畫面沒有跟著捲過去。清單視窗在定位之後會把「目標那一筆」畫出來，但當那一筆後面剩下的資料不足一個畫面時，視窗填不滿，目標就被擠出可見範圍，看起來就像沒找到。代號最大的那幾筆（Z 開頭）正好符合這個條件。

詳細處理

・現象:客戶檔按清單鍵後直接打代號，A 到 Y 都正常，只有 Z 開頭找不到；改按查詢鍵就找得到，而且之後快查會暫時能用，離開清單再進來又不行

・ 為什麼有的客戶沒事:要「目標後面剩下的資料不足一個畫面」才會中。這家客戶 Z 開頭之後只有 7 筆；資料較多的客戶永遠碰不到

・處理:清單定位後自動把上方的資料補滿，目標那一筆就一定看得到

・ 一併做的事:把這個條件做成常設的自動測試，日後有人改到這段程式會立刻發現，不必再等客戶遇到才知道

v2026.10 2026-10-02

自動更新

自動更新顯示「更新成功」，但程式其實沒有換成新版 →已修正

技術說明：更新器原本是靠「過程」判斷成敗：把每一行紀錄分類成成功或失敗再彙總。只要有任何一種「跳過」沒被正確歸類，成功就是假的 —— 例如更新當下程式還開著、檔案被鎖住而沒換成，卻被當成正常跳過。改為在派送完成後直接比對各站實際的程式檔，與這一版應有的內容不符就判定失敗，並明確指出是哪一站、哪一支程式。

詳細處理

・影響:同一天有三家客戶同時回報同一個問題，追到最後是這些站根本沒換到新版；而這類症狀平常不明顯，可以悶很久

・改法:不再只看過程，改看結果：比對實際檔案。不管是檔案被鎖、權限不足、還是其他沒想到的原因，只要沒換成功就不可能回報成功

・同時:驗證沒過就不寫入新版本號，下一輪會自動重試，不需要人工介入

・提醒:更新時請先關閉所有站台的程式，被鎖住的檔案是最常見的原因

v2026.10 2026-10-02

自動更新

自動更新顯示「更新失敗」並停住畫面，但其實已經成功 →已修正

技術說明：兩種情況被誤判成失敗：一是下載時遇到短暫的網路中斷、程式自動重試並且成功了，但那行「第一次失敗，稍後重試」的訊息被當成整輪失敗；二是更新完成後要回傳結果報告，那一刻剛好連不上伺服器，更新本身毫髮無傷，卻顯示紅色失敗。

詳細處理

・現象:畫面跳出紅色的「這一步失敗了」並停住，實際上該更新的檔案都已經更新完成

・改法:這兩種訊息改列為提醒（黃色），不再當成失敗

・ 安全性:真正的失敗仍然會紅色顯示並中止整輪 —— 重試用盡時會有另一行明確的錯誤訊息，而且會阻止寫入版本號，下一輪自動重試

・附帶:結果報告沒送達仍會提醒，因為那會讓我們看不到該站的更新狀況

v2026.10 2026-10-02

自動更新

有電腦沒有退出系統時，自動更新會一直卡住不動，也沒有任何結果回報 →已修正

技術說明：自動更新的最後一步是「資料庫結構升級」，需要把每個資料檔重新整理一次，整理時不能有人正在使用。原本的設計是「有人在用就等一下再試，等到對方退出為止」，在人工操作時可以按 ESC 跳過；但自動更新是在背景執行，沒有人可以按 ESC，而且背景模式下的「等一下」其實沒有真的停，變成一秒鐘重試上千次、不停寫紀錄，只要那台電腦一直沒退出，更新就永遠結束不了。現在改為：背景執行時每秒重試一次，最多等 2 分鐘；還是有人在用，就把這一項記為失敗並繼續往下，這一輪不算完成，下一輪會自動重做。

詳細處理

・現象:更新程式一直在跑、畫面停住，好幾天都沒有更新結果；主機上兩個紀錄檔 15 分鐘就長到 300MB

・ 真正原因:有一台電腦開著 DOS 版進銷存（STK.EXE）沒有退出系統，正在使用資料檔；請那台退出後，更新很快就完成

・驗證:用舊版重現：10 秒內重試了 3 萬 4 千多次、寫出 9MB 紀錄；新版：資料檔一直被占用時第 120 秒判定失敗並寫明原因，中途放開則立刻接著完成，紀錄只有幾行

・提醒:更新前請所有電腦退出系統（包含 DOS 版與 Windows 版），更新會最順利

v2026.10 2026-10-02

自動更新

有電腦開著系統時，自動更新照樣往下做而撞到資料檔，失敗訊息又看不出是誰沒退出 →已修正

技術說明：自動更新開始前會通知各台電腦退出系統，並等到大家都關掉才開始。但原本只認得 Windows 版的進銷存，開著 DOS 版（STK.EXE）、會計、人事薪資等其他程式時，系統以為大家都退出了，就直接開始更新，結果撞到正在使用的資料檔而失敗，紀錄上只寫「Open error」，看不出原因。現在更新開始前會直接逐一檢查資料檔有沒有被開著，不管是哪一種程式開的都查得到；有就等待最多 2 分鐘，還是沒關就停止這一輪（不會更新到一半），並在更新報告寫明是哪台電腦開著哪些檔案。

詳細處理

・現象:更新失敗，紀錄寫「HotKey (Open error)」，連續兩輪都一樣

・ 以前為什麼抓不到:舊的檢查方式只看 Windows 版主程式有沒有在執行；DOS 版是所有電腦共用主機上同一支程式，而且收不到「請退出」的通知，自動關閉也只會關 Windows 版

・ 現在的做法:不看是什麼程式，直接看資料檔本身有沒有被使用，以後新增的程式也自動涵蓋

・ 看得到是誰:更新結果報告新增「占用者」欄位，寫明哪台電腦開著哪些資料檔，客服一看就知道要請哪一台退出

・ 錯誤訊息:資料檔打不開時，訊息改為「檔案使用中（可能有電腦未退出系統）」

v2026.10 2026-10-02

自動更新

主機上開著「設定編輯器」時，自動更新每次都失敗 →已修正

技術說明：執行中的程式檔不能直接覆蓋。各工作站的程式早就有對應做法：先把舊檔改名讓位、再放入新檔，舊程式繼續用到關閉為止，下次開啟就是新版。但主機上的工具資料夾（設定編輯器等）漏了這一步，只要工具開著就覆蓋失敗，整輪更新被判定失敗並在下一輪重來，結果每一輪都一樣。現在工具資料夾也套用同一套做法，工具開著也能完成更新。

詳細處理

・現象:更新紀錄出現「INI_Editor.exe 拒絕存取」，連續兩輪都失敗

・影響:整輪被判為失敗，連帶其他已經更新好的部分也不會記錄成「已是最新版」，每次都重做

・驗證:讓工具保持開啟執行中，用舊做法覆蓋會被拒絕（重現客戶狀況）；新做法覆蓋成功、執行中的工具不受影響

・ 生效時機:設定編輯器關掉重開後就是新版

v2026.10 2026-10-01

查詢統計

查零件圖片（Alt+M）時影像視窗開得出來，但圖片區一片空白 →已修正，並已主動為所有客戶清除隱患

技術說明：一項為了加快網路查詢而新增的索引參數，因為被寫在設定檔的錯誤位置而「換了位置卻換不掉舊的」，使系統實際採用了非標準的索引格式；主系統支援這個格式，但負責看圖的影像伺服器所用的資料庫驅動只支援標準格式，於是查不到任何零件資料 —— 它不會報錯，只會回傳空的，所以視窗照常開啟卻沒有圖

詳細處理

‧ 現象:在零件資料按 Alt+M 叫出影像視窗，視窗、外框、按鈕都正常，開關也正常，就是該顯示圖片的區域完全空白。重新啟動影像伺服器也沒有用。同一時間多家客戶、而且是全部站台一起發生。

‧ 根因:設定檔裡有一項「索引頁大小」參數，原本應該放在設定檔的共用區，卻被放進了某個分類區段底下。系統更新時會把「客戶還沒有的新設定」自動補上，於是同一個設定在同一個檔案裡出現了兩份（共用區一份、分類區段一份），而自動整理重複設定的機制是以「區段＋名稱」比對，認定這是兩個不同的設定，因此永遠清不掉；主系統讀取時不分區段，實際採用的是後面那一份。這也是為什麼用設定工具修改後「怎麼改都沒效」。

‧ 為什麼突然發作:這個參數只有在「重建索引」的當下才會真正寫進索引檔。所以設定錯了多久都不會有事，客戶一執行索引整理，當天就全站發作。

‧ 為什麼只有看圖壞、其他功能正常:主系統本身支援這種索引格式，所以進銷存作業完全不受影響；但影像伺服器是透過另一套資料庫驅動讀取零件檔，它只支援標準格式，讀到非標準索引就查不到任何記錄，而且不會產生錯誤訊息，只是回傳空白。

‧ 解法:①把該參數移回設定檔的共用區，預設值改回標準格式，並在設定說明中明確標註「有影像系統的客戶請維持預設」;②設定工具加入自動修復：存檔時會偵測並清除被放錯區段的設定，不必人工處理;③我們已主動為所有客戶完成清查與清除 —— 掃描 19 家客戶，其中 11 家存在這項隱患，連同各站電腦的本機副本共清理 121 個設定檔，每一個檔案都先備份;④已經受影響的客戶，另需重新整理一次索引即可完全恢復。

‧ 附帶說明:未受影響的客戶也已一併清除，避免日後執行索引整理時才發作。

v2026.10 2026-10-01

技術說明：結構升級的作法是「依新結構建一張空表 → 把舊資料搬進去 → 換檔」。問題是換檔只換了資料檔，索引檔留在原地，而索引檔裡存的是「這筆資料在第幾筆」的位置指標——新表是重建出來的，位置不保證跟原來一樣。再加上搬資料時會跳過「已刪除但尚未清除」的記錄，筆數一少，後面每一筆的位置都往前移，舊索引就會指到錯的記錄。程式裡原本是有重建索引的指令，但它被包在一段「出錯就忽略」的保護裡，失敗不會回報，而且不論成敗都印「OK」。本次改為換檔後一定重建、失敗明確回報並於下一輪自動重試，搬資料時也不再丟掉已刪除記錄

詳細處理

‧ 怎麼發現的:沒有客戶回報。是在處理上一筆（更新回報成功但沒安裝）時，客戶提醒我們「統計檔的索引好像跟資料檔的欄位有關，欄位大小一改可能會有問題」，順著這條線查出來的。

‧ 客戶原本的顧慮:客戶擔心的是索引的排序鍵裡有把數字轉成文字的寫法，欄位加寬之後鍵的長度會跟著變。這個方向完全正確，只是這次剛好沒踩到：那些排序鍵都有明確指定長度，長度是固定的；而且這次加寬的是「每個月」的金額欄位，排序鍵用的是「全年合計」欄位，兩者沒有交集。

‧ 真正的問題:比對檔案時間就看出來了：資料檔是升級當天下午更新的，索引檔卻還是半個多月前的日期——一個位元組都沒有動過，而紀錄檔裡寫的是「OK」。重建索引那段從來沒有真正生效。

‧ 為什麼特別危險:這種錯不會當機、不會有錯誤訊息。排序鍵的內容是對的、長度也是對的，只是指到了錯的那一筆。症狀會是「查詢找不到明明存在的資料」或「統計數字對不上」，而且完全看不出是索引造成的。

‧ 影響範圍:我們逐表檢查了所有受影響的統計檔，目前「已刪除但尚未清除」的記錄都是零筆，所以資料位置沒有位移，沒有客戶因此受到影響。這次沒出事是運氣好，不是原本的設計有保障。

‧ 解法:換檔之後一定重建索引，而且使用客戶自己的索引定義（不是出廠預設）——客戶可能有自行增加的索引，照出廠定義重建會把它們弄掉。同時要求「沒有出錯」之外還要「索引檔真的產生出來」才算成功；失敗會明確列入失敗項，下一輪自動重試。搬資料時也改為保留已刪除記錄，升級只改結構、不動資料內容。

‧ 驗證:在測試環境刻意標記三筆為已刪除，並記下第一、五、十二與最後一筆的代號當作位置基準。修正前：筆數從 2,895 掉到 2,892、位置基準全部跑掉、索引檔沒有變動。修正後：筆數維持 2,895、刪除標記三筆都在、位置基準完全一致、索引檔確實重新產生。

‧ 建議:已經升級過的站台，建議執行一次系統內的〔重建索引〕。依前述檢查應該沒有位移，但確認過比較安心。

v2026.09 2026-09-30

查詢統計

年度統計報表的月金額欄位放不下，顯示成一整排星號 →已加寬（需執行統計資料檔重算）

技術說明：這幾張年度統計檔的「每月金額」欄位，當初設計的寬度只夠放到約一億。金額成長超過之後，系統的行為是把整個欄位填成星號而不是報錯，所以報表上看到的是一排 *。本次把年度統計、客戶年度、零件年度與廠商年度四張表的每月金額欄位一併加寬。★加寬本身不會把已經存成星號的金額救回來——那些值在當初就沒有寫進檔案，必須執行〔統計資料檔重算〕從交易明細重新累計

詳細處理

‧ 現象:年度進銷統計、客戶年度統計、零件年度統計與廠商年度統計的報表上，部分月份的金額顯示為一整排星號；金額較大的客戶與熱門零件最容易遇到。

‧ 根因:欄位寬度不足。這類系統在數字放不進欄位時，不會產生錯誤，而是把欄位填滿星號——所以它會一路寫進檔案裡，直到有人看報表才發現。

‧ 解法:把四張表的每月金額欄位加寬，並在更新完成後主動顯示提醒，請使用者執行〔進階管理 → 統計資料檔重算〕。

‧ 一個容易漏掉的地方:廠商年度統計原本不在第一批加寬名單裡。我們在覆查時才發現它和另外三張是同一個家族、同樣的問題，第一批卻漏了它。已於本次補上。這類「同一家族漏一張」的情況我們已改為直接解析結構定義檔一次比對全部，不再靠人工列名單。

‧ 務必執行重算:更新只會把欄位變寬，不會自動還原已經存成星號的金額。請在更新後執行一次〔統計資料檔重算〕，系統會從交易明細重新累計，原本顯示星號的數字就會回來。

v2026.09 2026-09-30

系統穩定

詢價製單「匯入資料檔」後選擇列印未匯入清單，整個畫面凍住、按什麼都沒反應 →已修正

技術說明：問題出在列印那一步用的是一種早期 DOS 時代的列印寫法——直接把檔案倒進作業系統的「印表機裝置」。在現在的 Windows 上，如果這個裝置不存在或沒有回應，這道指令會一直等下去而且永遠等不到結果，整個系統就停在那裡。更麻煩的是，我們原本為這一段加過保護，但那道保護只擋得住「程式出錯」，擋不住「程式卡住不動」，所以它一次也沒有發揮作用。本次改為交給系統原有的列印程式處理（其他報表早就是這種作法），問題根除

詳細處理

‧ 現象:在「國內：詢價製單」中匯入廠商報價檔，匯入完成後系統會問「未匯入的報價是否列印？」，選「是」之後畫面就完全靜止，滑鼠鍵盤全無反應，只能強制關閉重開。同一天在同一台電腦重複發生三次，每次都在同一個地方。

‧ 追查:最棘手的地方是系統紀錄裡什麼線索都沒有留下——沒有錯誤訊息、沒有錯誤紀錄檔，連我們平常每五秒寫一次的「系統還活著」訊號也一併停止。這個組合本身就是關鍵證據：它代表程式不是在「等使用者按鍵」，而是整條運作被卡在更底層的地方。我們先在這段流程的每一個步驟加上紀錄點，重現一次之後，紀錄停在「準備送印表機」的下一行不見了，位置立刻確定。

‧ 根因:這段程式沿用早期版本的寫法，把清單檔案直接複製到作業系統的印表機裝置。這在 DOS 時代是標準作法，但現在的電腦多半已沒有實體的並列埠印表機；當這個裝置無法開啟或沒有回應時，作業系統不會回報失敗，而是讓程式無限期等待，於是整套系統跟著停住。

‧ 一個容易誤判的地方:我們在九月稍早其實已經替這一段加過防護，用意正是攔截列印失敗。但那種防護只能攔截「程式發生錯誤」，對於「程式卡住不動」完全無效——卡住不會產生錯誤，防護自然永遠不會被觸發。這也解釋了為什麼加了防護之後問題照樣發生。

‧ 解法:改用系統既有的列印程式來處理這份清單，與其他報表走同一條路。它會先確認檔案存在、再交給印表機，失敗時明確回報而不是卡住。我們同時檢查了全系統，確認這是最後一處還在使用舊式列印寫法的地方，其餘早已全數改寫完畢。

‧ 附帶強化:同一次檢查中發現另一個同類風險——系統呼叫外部程式時也是無限期等待，若被呼叫的程式沒有結束，同樣會拖住整套系統。已一併加上時間上限，超過就放手繼續執行，不再讓單一外部程式有機會癱瘓整個系統。

v2026.09 2026-09-29

進銷存作業

單據表頭「結帳日期」按 ? 帶入日期沒有反應（銷貨／進貨／報價皆受影響） →已修正

技術說明：此功能的程式碼一行都沒有被移除，按鍵也仍然掛著，問題出在「日期欄位被寫入了文字格式的值」。本系統的日期欄位有固定的資料型態，而這段功能沿用早期版本的寫法，是把日期轉成文字再填回欄位；早期版本容許這種做法，改用新版開發工具後型態檢查變嚴格，就不再成立。加上日前為了防止某客戶端當機所加入的一道保護機制（偵測到快捷鍵把欄位型態改掉就自動還原），這個值一填進去便立刻被還原，於是按下去看起來毫無反應。本次將寫入方式依欄位型態分開處理——日期欄位就給日期、文字欄位才給文字，保護機制不再被觸發，功能恢復正常

詳細處理

‧ 現象:進銷貨單表頭的【結帳日期】欄位，原本按 ? 可以交替帶入「下個月同日」與「今天」，使用者反映此功能消失，按下去畫面完全沒有任何變化。

‧ 追查:先確認功能是否真的被移除 —— 按鍵掛載與程式進入點都還在，且與三個多月前的備份逐字比對完全相同，確認不是近期改動所造成，因此轉向追查「是什麼把它擋住了」。

‧ 根因:系統紀錄中留下了決定性的線索，顯示該欄位的資料型態在按鍵執行後由「日期」變成了「文字」，隨即被保護機制還原。也就是說，值確實有寫進去，只是在畫面更新之前就被撤銷了。這段填值的寫法沿用自早期版本，當時的欄位內部就是以文字保存，因此長年運作正常；改用新版開發工具後型態要求嚴格，該寫法便會造成型態改變。日前新增的保護機制（用於防止快捷鍵改變欄位型態後造成系統中斷）正確地偵測並還原了它，副作用就是這個功能一併失效。

‧ 解法:不取消保護機制（那等於把當機風險放回來），而是從源頭修正：填值時先判斷欄位型態，日期欄位直接給日期值、文字欄位才給文字值。型態不再改變，保護機制自然不會觸發，功能即恢復。此修正同時作用於銷貨、進貨與報價三處的日期欄位，不需更換表單或調整任何設定。

‧ 附記:保護機制本身並無錯誤，它是為了避免系統中斷而設的防線；真正的問題在於這段填值寫法長年以來是「靠早期版本的寬鬆規則僥倖運作」。此次一併從源頭修正，往後不會再因為型態檢查而失效。

v2026.09 2026-09-29

標籤信封

連續標籤紙印到第二張就開始往上偏，越印偏越多；調整印表機驅動設定後 →已解決

技術說明：兩個原因都在印表機驅動的設定，程式不需要更動。其一是舊驅動設定「頁長」時只能以行為單位（1/6 吋），1.1 吋的標籤換算成 6.6 行、表達不出來，被取整成 6 行＝1.0 吋，每張就少走 0.1 吋（約 2.5 mm），一張一張累積下去；改用支援 ESC/P2 的驅動（頁長單位 1/360 吋）即可精確表達。其二是換驅動後「可列印區域」預設為標準，上下保留約 8.6 mm 不可列印邊界，1.1 吋的標籤只剩 0.76 吋可用，內容第四行以後就掉出紙外；改成最大即可

詳細處理

‧ 現象:8×1.1 吋連續標籤紙，第一張位置正確，第二張開始內容就往上偏，越後面偏越多，到第十張左右整行已經跑到標籤框外。畫面預覽完全正常，只有實際印出來才會發生。

‧ 追查:先確認程式端無誤 —— 記錄顯示每張標籤都正確換頁、每頁高度都是 1.1 吋、每一頁的文字位置完全相同，程式沒有累積誤差的餘地。接著以標籤上已知寬度的紅框當比例尺，量測印出來的成品，得到「印表機每張實際只走 1.0 吋」，比標籤的 1.1 吋短了 0.1 吋，與肉眼看到的偏移量完全吻合，確認問題出在進紙距離而非排版。

‧ 根因:點陣印表機的頁長設定指令，在舊規格（ESC/P）中只能指定「幾行」，而行距固定為 1/6 吋。1.1 吋 ÷ (1/6 吋) = 6.6 行並非整數，印表機只能取 6 行（1.0 吋）或 7 行（1.167 吋），兩者都不等於標籤的實際間距。這也是為什麼在紙張尺寸上反覆微調（例如 2.79 公分改成 2.80 公分）完全沒有任何變化 —— 送過去的值都落在同一個取整區間裡。

‧ 解法:改用支援 ESC/P2 規格的印表機驅動（本例為 EPSON LQ-695C ESC/P2），其頁長指令以 1/360 吋為單位，1.1 吋可精確表達，偏移立即消失。更換驅動後若出現「最後幾行印不出來、前面幾行正常」，是新驅動的可列印區域預設為「標準」所致，於印表機內容中改為最大即可。此兩項皆為印表機端設定，系統程式與報表格式均不需要修改。

‧ 自我檢查:若貴公司使用連續標籤紙且遇到類似情形，可依序檢查以下四項：(1) 標籤高度是否為非整數吋（如 1.1 吋）—— 是的話優先確認驅動是否為 ESC/P2 版本；(2) 印表機內容 →「紙張來源」請選拖曳器或連續紙，不要選自動進紙器／單頁（單頁模式為了防止夾紙會保留較大的上下邊界）；(3) 若有「無邊界列印」或「縮小邊界」之類的選項，一併開啟；(4) 若僅最後幾行缺漏而前幾行正常，請將驅動的「可列印區域」由「標準」改為「最大」。

v2026.09 2026-09-29

查詢統計

月對帳單（摘要格式）的「現金」「支票」兩欄變成 0，舊版明明印得出來 →已修正

技術說明：現金與票據的金額原本是在「列印明細」的迴圈裡邊印邊累加，而摘要格式的設計就是不印明細、不跑那個迴圈；早年因為一個判斷式的瑕疵，這個「不跑」的指令其實從未生效，數字才一直是對的。該瑕疵被修正後，指令首次真正生效，兩欄就靜默變成 0

詳細處理

‧ 現象:客戶月對帳單右欄的「現　金：本月」「支　票：本月」，在舊版印出來是正確的（例如現金 7,000 ＋支票 92,640 ＝本月銷貨 99,640），換版之後兩欄都變成 0.0。只有使用「摘要格式」且表單上有這兩欄的客戶會遇到。

‧ 追查:我們保留了歷年每一次改版的原始碼，逐一比對後精確定位到變化發生在 2024 年 11 月中的一次改版 —— 確認與後來的系統轉換無關，也不是任何優化拿掉的。

‧ 根因:程式語言的一個經典陷阱：用來判斷「呼叫時有沒有給這個參數」的寫法，會把「給了、但值是否」誤判成「沒有給」。因此「摘要格式不要跑明細迴圈」這個指令長年被忽略，明細迴圈照跑（只是表單沒有明細欄位所以看不出來），而現金／票據的累加正好寫在那個迴圈裡，數字才一直正確。2024 年那次改版把這個判斷寫法修正了（修得正確），指令第一次真正生效，累加也就跟著停了。

‧ 解法:不把舊寫法改回去（那等於把陷阱放回來），而是把「統計」從「列印」裡搬出來 —— 改在系統整理該客戶當月單據時就先算好現金與票據，再交給列印。四種列印格式（總表／明細／摘要／其它）從此一律正確，摘要格式也不必為了湊數字而多跑一趟明細。分類規則完全沿用原本的作法：銷貨單明細的備註欄以「現」開頭者計入現金，其餘一律計入票據，退貨為負，確保數字與客戶手上的舊對帳單完全一致。表單不需要更換。

v2026.09 2026-09-26

自動更新

自動更新出現「更新失敗」：部分檔案送不到某一台電腦

現象：執行自動更新後，畫面最後顯示紅字「更新失敗」，明細寫著某個檔案傳送到某台電腦失敗、連線逾時。其餘更新其實都已完成，只有那一台漏掉。
原因：電腦如果裝了遠端連線或 VPN 類的軟體（例如 Radmin VPN、Hamachi），系統中會多出一張「虛擬網路卡」。我們的服務程式原本是用「哪一張網路卡設有對外閘道」來判斷自己的內部網路位址，偏偏虛擬網路卡也符合這個條件，結果回報了一個只有該 VPN 內部才連得到的位址，主機依這個位址送檔案當然送不到。
已修正：改用「是不是內部網路位址」來判斷（一般公司內網一定是 192.168、10、172.16~31 開頭），VPN 軟體用的位址不在此範圍，自然會被排除。判斷方式不依賴網路卡的名稱，不會因為系統語言不同或使用者改了名稱而失效。
影響範圍：我們同步檢查了目前所有連線中的電腦，共 6 台受此影響、其中 5 台是各公司的主機。主機回報錯誤位址時，派送檔案、遠端協助、檔案傳輸都可能指向錯的位置，建議都更新至最新版。此檢查是透過服務程式原本就有的回報訊息進行，沒有連入或影響您的電腦。

v2026.09 2026-09-26

系統操作

高解析度螢幕：系統畫面在登入時突然縮小一半

現象：系統啟動時畫面大小正常，但登入畫面出現的瞬間，整個系統視窗突然縮小，登入完成後也維持在很小的狀態。只發生在把 Windows 顯示比例調成 125%、150%、175% 的高解析度螢幕上；一般 1920×1080、顯示比例 100% 的電腦完全不受影響。
原因：Windows 對於「沒有宣告支援高解析度」的程式，會自動把畫面等比放大，系統的文字畫面就是靠這個機制維持正常大小。而新版登入視窗在開啟時，會向 Windows 宣告「本程式自行處理高解析度」——這個宣告是整支程式共用、而且一旦宣告就無法收回，於是 Windows 立刻停止放大，主畫面當場縮水。
已修正：改用可還原的宣告方式，只在登入視窗存在的期間生效，關閉後立即還原，主畫面全程維持原本大小。登入視窗本身則會依螢幕的顯示比例自動放大到相稱的尺寸——視窗、欄位與文字大小一起等比放大，不會出現框變大、字卻很小看不清楚的情形。
順帶修正：同樣的情形原本也潛藏在「訊息」與「營運儀表盤」功能中（在少數設定下會走到相同流程），此次一併解決。

v2026.09 2026-09-26

零件資料

零件資料視窗縮小或拖曳分隔線時跳出錯誤畫面

現象：進入零件資料，把視窗調小、或拖曳中間的分隔線之後，畫面跳出錯誤訊息被迫離開。有客戶一天內發生十多次，不同電腦都會。
原因：畫面重新排版時，程式先設定下方視窗的「底部位置」、後設定「頂部位置」。設定底部的那一瞬間，頂部還是舊的數值，兩者對不起來就會被系統判定為錯誤。視窗愈小愈容易踩到。
已修正：改成依照視窗變大或變小，自動決定先調整哪一邊；若視窗高度已經不夠放下子視窗，就維持原樣不動，不會再跳錯誤。

v2026.09 2026-09-26

進貨作業

國內到貨時跳出「除數為零」錯誤

現象：國內訂購到貨處理時跳出錯誤畫面，該筆到貨無法完成。
原因：程式要重算零件的加權平均成本，公式的分母是「原庫存量＋本次到貨量」。當零件原本是負庫存、而這次到貨量剛好把它補到零時，分母就變成 0，計算失敗。
已修正：遇到這種情形，加權平均本來就沒有意義，改為直接採用這筆到貨的進貨單價當成本，不再中斷作業。

v2026.09 2026-09-26

列印報表

列印「廠商報價未匯入清單」時跳出錯誤畫面

現象：詢價作業匯入廠商報價後，選擇列印未匯入的清單，畫面直接跳出錯誤。
原因：這份清單走的是早期 DOS 時代「直接送印表機埠」的老方式。現在的 Windows 電腦多半沒有對應的印表機埠，程式就會開啟失敗。
已修正：改為顯示清楚的提示訊息而不是錯誤畫面。清單本來就會自動用記事本開啟，需要列印時從記事本的「檔案／列印」即可。

v2026.09 2026-09-26

進貨作業

進貨單輸入中按下快速鍵後跳出錯誤畫面

現象：進貨單資料輸入途中按下某些功能快速鍵，回到原欄位時畫面跳出錯誤。
原因：快速鍵叫出來的功能，有可能把您正在編輯的欄位換成了不同性質的內容（例如金額欄變成文字），程式回到該欄位重畫時就對不起來。
已修正：程式會記住欄位原本的內容型態，發現被改掉就自動還原，不再跳錯誤畫面。同時把發生當下的詳細狀況記錄下來，方便我們找出是哪一個快速鍵造成，後續徹底解決。

v2026.09 2026-09-24

列印報表

對帳單／報價單印在小張紙（一張裁成兩半或三段）時，每張只印出前面一小段，後面的明細整段不見 →已修正

技術說明：報表因為每頁開頭都重複輸出一次紙張設定指令，被列印程式誤判成「標籤貼紙」，而標籤的規則是「一張貼紙放不下就不續印」，於是超出紙張的明細被直接丟棄；同時換頁時未將游標歸位，導致下一段從半途開始排而多出頁數

詳細處理

‧ 現象:月份對帳單設定成「一張報表紙裁成三段」列印時,每一段只印得出大約三分之一的明細,後面的資料完全不見;報價單設定成「裁成兩半」時,則是中間夾一張全空白的紙,而且最後的「總計」被擠到多出來的一頁。用原本沒有裁切的整張紙列印卻看起來正常,所以這個問題一直沒被發現。

‧ 原因:列印程式要分辨「報表」和「標籤貼紙」——貼紙的規則是一張放不下就不再續印(因為實體貼紙就那麼大)。判斷方式原本是看報表開頭的紙張設定指令出現幾次,而這幾張報表每一頁開頭都會重複輸出一次,於是被誤認成貼紙,套用了「放不下就丟掉」的規則。另外還發現兩個相關問題:①換頁之後應該要「一切從頭算起」,但程式在某些情況下沒有把位置歸零,導致下一段報表從前一頁剩下的半途接著排,整段被往後推而多出一頁;②判斷「這一頁有沒有印過東西」的旗標從來沒有在換頁時歸零,使得「不要印出空白頁」之類的保護一直沒有真正生效。

‧ 解法:①用「報表有沒有使用換頁符號」來區分報表與貼紙,兩者互斥,報表不再被誤判;②有資料的行絕對不丟棄——放不下就自動續印到下一張,寧可多印一張也不讓資料消失;③換頁後一律回到頁面最頂端重新起算,下一段不受上一段影響;④若當前這張紙還沒印任何東西就要求換頁,改為沿用同一張,不再多吐一張空白紙。修正後實測:對帳單裁三段 → 正確 9 張、裁兩半 → 6 張;報價單裁兩半 → 4 張、整張 → 2 張,內容逐字相同、沒有空白頁,每一張的行數也與紙張容量完全吻合。

‧ 附帶提醒:若您在列印設定裡調過上邊界(例如 0.2 公分),它會佔掉紙張可用高度,小張紙原本剛好能放 22 行就會變成只能放 21 行,每張紙的尾巴因此被擠到下一張、頁數變多。這不是程式問題,但遇到「頁數比預期多、而且每張尾巴只有一兩行」時可以先檢查邊界設定是不是被設成非 0。

v2026.09 2026-09-22

網頁遠端

Windows 7 電腦「跨站複製貼上」有時沒反應、老是顯示沒有新內容 →需安裝微軟更新(非程式問題)

技術說明：負責回答「這台是哪一站」的本機信標小程式,在缺少特定 Windows 更新的 Win7 SP1 上無法啟動(載入網路元件時失敗),信標起不來,瀏覽器就判斷不出本機身分,跨站貼上因而找不到來源

詳細處理

‧ 現象:在 Windows 7 電腦上用網頁版遠端桌面做「跨站複製貼上」時,常常貼不過去,畫面回覆沒有新內容;同樣的操作在 Windows 10／11 的電腦完全正常。另外開機或重新啟動檔案總管時,螢幕可能閃出一個英文錯誤視窗(內容提到 DLL load failed 與 _socket)。

‧ 根因:跨站貼上要先知道「操作的人現在坐在哪一台」,這是由一支常駐的小程式(本機身分信標)負責回答。這支程式在沒有安裝某個 Windows 更新的 Win7 SP1 上會啟動失敗——它需要的載入功能要靠那個更新才有。信標沒起來,網頁端就認不出本機是哪一站,於是每次都回「沒有新內容」。因為錯誤視窗常在重新啟動檔案總管時才冒出來,很容易誤以為是當下執行的別支工具出問題。這不是程式的錯誤,是那台電腦缺更新,所以同一版程式在其他電腦都正常。

‧ 處理方式:在該台 Windows 7 電腦安裝微軟的系統更新(離線安裝包,對應 KB3063858,它取代了已經下架的 KB2533623),裝完重新開機即恢復正常,程式本身不需要更新。實際案例中,同一個客戶的兩台 Win7 裝上更新後跨站貼上立即恢復。若離線包顯示「不適用於您的電腦」,通常是該更新已被更新彙總套件包含,或下載到位元數不符的版本(32 位元機器要用 x86 版),請與我們聯繫協助確認。

v2026.09 2026-09-21

系統穩定

換過印表機之後，那台電腦一開就停在黑畫面、跳紅色錯誤框，完全進不了系統（同一家店其他電腦都正常） →已修正

技術說明：啟動流程中「印表機設定失效」的提醒視窗出現得太早，早於畫面元件初始化完成，導致程式在主程式進入前就中止

詳細處理

‧ 現象:某一台電腦點開系統後畫面整片黑，中央紅框顯示「BASE/1003 Variable does not exist: AFRAME」，只能選結束或重試。最關鍵的線索是同一套程式在同店其他電腦全部正常，看起來像那台電腦壞掉。實際觸發條件是該台換過印表機（原本的點陣機換成新機種、或驅動重裝、印表機改名）。

‧ 根因:系統會記住上次選用的印表機名稱。印表機被換掉後這個名稱不存在了，啟動時就會想跳出提醒視窗；但這個提醒發生在啟動流程的第 11 步，而畫面元件（訊息框的框線與配色設定）要到第 13 步進入主程式時才建立，於是訊息框取用尚未存在的設定而中止。其他電腦因為印表機找得到，根本不會走進這段流程，所以完全不受影響。

‧ 解法:兩層處理：①訊息框本身加防護——啟動流程中任何一步要顯示訊息時，都會先確認畫面元件是否就緒，未就緒就改用內建的預設框線與配色，保證畫得出來、不再演變成黑畫面；②印表機提醒不再擋開機——啟動時只記錄下來並自動改用設定檔中的印表機繼續執行，把提醒延到第一次要列印時才顯示一次，那時印表機選擇視窗正好會出現，可以當場改選新的機器。

v2026.09 2026-09-21

列印報表

印表機清單出現兩個同名的「二號印表機」，其中一台其實已經不存在，選到就印不出來 →已修正

技術說明：印表機別名的設定只以「實體印表機名稱」為索引，不檢查該別名是否已指派給別台，換機器後新舊兩筆並存

詳細處理

‧ 現象:把兩台舊印表機設了別名「二號印表機」「三號印表機」，後來換裝新機種並重新指定同樣的別名，結果列印時的印表機清單裡「二號印表機」「三號印表機」各出現兩個，外觀完全一樣分不出來，挑到舊的那一個就印不出東西。

‧ 根因:別名設定在寫入時只用「實體印表機名稱」當索引鍵，換機器時舊機器那筆對應仍留在設定檔裡，新機器又另外新增一筆，兩筆指向同一個別名因而並存。舊機器雖然已經移除或改名，它的別名設定卻沒有人清掉。

‧ 解法:同一台電腦內一個別名只會屬於一台印表機：設定別名時會自動移除其他指向同一別名的舊設定，並且明白顯示「別名『二號印表機』原本是某某機器的，已改指到這一台」，讓操作者清楚知道剛才動到什麼，不會在不知情的情況下被改掉。

v2026.09 2026-09-23

系統維護

Windows 7 電腦執行「桌面捷徑修復工具」等於沒按：跑完沒有任何錯誤，捷徑卻還是壞的 →已修正

技術說明：修復工具的核心步驟用到 .NET 4.0 才有的系統元件，Windows 7 內建環境不支援，整段修復靜默失效

詳細處理

‧ 現象:桌面上的系統捷徑被 Windows 改寫成網路路徑（\\S001\stk\S00X\STK32.EXE）之後點不開，依指示執行修復工具，畫面顯示跑完而且沒有出現任何錯誤訊息，但捷徑完全沒有被修好，只有 Windows 7 的電腦會這樣。

‧ 根因:修復工具把「改回正確路徑」這段交給 PowerShell 執行，其中取得「公用桌面」位置用的系統元件是 .NET 4.0 才新增的。Windows 7 內建的是 PowerShell 2.0、跑在舊版執行環境上，遇到這個元件會直接中止，而中止訊息沒有被顯示出來，所以看起來像是「跑完了但沒效果」。

‧ 解法:新增 Windows 7 專用版，把修復改用 Windows 7 本身就內建的腳本元件執行，功能與原版完全相同；登錄檔設定的部分維持原本的做法。Windows 10／11 請用 fix_shortcut.bat，Windows 7 請用 fix_shortcut_win7.bat，兩者都放在 W:\TOOLS\。

v2026.09 2026-09-24

系統穩定

主機（或網路）斷線時，畫面連續跳出三、四個看不懂的英文錯誤 →已改善為一句看得懂的中文提示

技術說明：網路中斷後，第一個錯誤是資料檔讀取失敗，接著因為資料檔已失效，後續每一個欄位存取都再各噴一個錯誤；系統原本只把原始錯誤碼照實顯示，真正的原因（網路斷了）反而被後面的連鎖錯誤淹沒

詳細處理

‧ 現象:網路線鬆脫、網路卡休眠、或主機重開機時，工作站畫面跳出「DBFCDX/1010 Read error … (DOS Error 2)」，按了繼續之後又接連跳出「Variable does not exist: CBRAND」等看不懂的訊息，一次斷線常常收到三、四個錯誤畫面。

‧ 根因:系統本來就有「網路瞬斷自動重試」（斷一兩秒會自己接回來，使用者完全無感）。但重試用盡、網路真的斷掉時，就會把原始錯誤碼直接顯示出來，並且仍提供「重試／忽略」選項——在網路已經斷線的狀態下按繼續，等於讓程式帶著失效的資料檔往下跑，於是連鎖產生後面那一串二次錯誤。

‧ 解法:重試用盡後，系統會實際去確認「資料目錄是不是真的不見了」。確認是斷線時，改為顯示「與主機的網路連線中斷／資料目錄 … 目前無法存取／請檢查網路線、確認主機開機後重新進入系統」，並且只保留「結束」一個選項，讓程式安全收斂，不再連鎖出後面那些看不懂的錯誤。同時回報給我們的診斷紀錄會標註這是斷線事件（含當天已自動重試的次數），讓我們一眼分辨是網路問題還是程式問題，也能主動發現長期網路不穩的據點。

v2026.09 2026-09-24

進銷存作業

比價單自動帶入建議進貨資料時，只要其中一筆金額超過千萬，整張單就當掉 →已修正

技術說明：比價單明細的金額欄位長度只留到七位數（上限 9,999,999.99），自動批次帶入時若某零件的「單價 × 建議進貨量」超過這個上限，寫入就會失敗並中止整張單的建立

詳細處理

‧ 現象:執行比價單的自動帶入（依歷史用量／安全存量產生建議進貨明細）時，程式中途跳出「Data width error」而中斷，整張比價單建不起來，前面已經帶好的明細也一併中止。

‧ 根因:明細金額欄位定義為七位整數，實際帶入的金額（例如 40,504,500）已超過容量。同系列的訂購單、採購單、排程單先前都已經加寬過，唯獨比價單與到貨單的欄位沒有跟著調整。

‧ 解法:①先行止血——寫入前檢查該筆金額是否放得下，放不下就記錄下來並跳過該筆，其他零件照常帶入，整張單不再中斷；②同時我們已排定將這些金額欄位加寬到九位整數（上限 999,999,999.99）的資料結構更新，屆時會透過更新程式自動套用到各據點，並同步檢查畫面與報表欄寬，確保加寬後的數字能完整顯示。

v2026.09 2026-09-24

查詢統計

報表查詢畫面按 F9 重新查詢、查不到資料後離開，系統當掉 →已修正

技術說明：查詢畫面離開時會還原「進來之前的資料表與游標位置」，但按 F9 重查且查無資料時，那個暫存資料表已經被關閉，還原動作在沒有資料表的狀態下執行而當機

詳細處理

‧ 現象:在報表查詢的瀏覽畫面按 F9 重新輸入條件，若新條件查不到資料，再按離開時系統直接跳錯誤中止。

‧ 根因:瀏覽畫面在離開時會把使用者進來之前的資料表、索引順序與游標位置一併還原。按 F9 重查會先關掉舊的暫存查詢結果，查無資料時就不會再建新的——此時離開，還原動作找不到那個資料表。先前的修正已經保護了「索引順序」的還原，卻漏了緊接著的「游標位置」還原，於是問題仍在。

‧ 解法:把兩個還原動作綁在同一道保護內——確認資料表仍然存在且成功切換回去，才還原索引與游標；資料表已關閉就安靜略過。同時檢查了同一支程式的其他三處離開路徑（查無資料、自動新增失敗、視窗不可重複開啟），它們有同樣的寫法但症狀不是當機，而是可能跑到別的資料表上亂動游標（更難察覺的資料錯位），一併補上相同保護。

v2026.09 2026-09-23

進銷存作業

進貨單刪除明細項目要停頓一、兩秒（銷貨單刪除卻很快） →已修正

技術說明：刪除進貨明細時若「該零件目前庫存量正好等於要刪掉的數量」，重算平均成本的算式分母會變成 0；這個除以零的錯誤被系統自動吞掉、不影響資料，但吞掉之前已先花約 1.9 秒自動擷取了一張畫面截圖，使用者感受到的就是那一、兩秒的停頓

詳細處理

‧ 現象:同樣是刪除單據明細，銷貨單瞬間完成，進貨單卻常常要等一、兩秒；但不是每一筆都慢，看起來毫無規律。

‧ 根因:銷貨單刪除明細不需要重算成本，進貨單則必須重新計算該零件的平均成本。當「庫存量－刪除數量＝ 0」時，算式的分母為零而產生錯誤。系統的錯誤處理判定這是可以安全忽略的情況（成本維持原值，資料不受影響）而自動吞下，但在吞下之前，它已經依照標準流程先擷取了一張畫面截圖以備回報——那張截圖要花約 1.9 秒。因為只有特定庫存數字才會觸發，所以時快時慢、找不出規律。

‧ 解法:①在算式加上防呆，庫存量等於刪除量時沿用原本就有的處理分支，不再產生除以零；同一個函式另外三處相同算式（含進貨退回）也一併補上；②調整錯誤處理流程，可以安全忽略的錯誤不再擷取截圖，只有真正要顯示給使用者、需要回報的錯誤才截圖，順帶消除了這類錯誤造成的所有停頓；③這類被安靜吞掉的錯誤現在也會回報給我們（只傳幾 KB 的文字紀錄，不含截圖），以便及早發現類似的潛在問題。

v2026.09 2026-09-22

進銷存作業

國內／國外比價製單「表身批增（依交易歷史）」選全部零件時要等 37 秒、畫面像卡住 →已修正

技術說明：逐筆重複查主檔，在區網上被網路往返放大

詳細處理

‧ 現象:客戶反映批增後畫面不動,進度框停在「2/…」「5/…」,實測整段耗時 37 秒。客戶自行重建索引後沒有任何改善。

‧ 診斷:在批增流程埋入分段計時後得到關鍵數字——走訪交易歷史只花 0.10 秒,其餘全部耗在「每筆明細各查一次零件主檔與庫存再寫入」。問題不在索引,也不在資料量,而在重複的隨機查詢次數乘上區網的每次往返延遲。

‧ 解法:改為兩段式——先掃描整段交易歷史,在記憶體以雜湊表把同一零件的數量預先加總;再針對真正有交易的零件各寫入一次。同時補上批次寫入機制,避免每寫一筆就強制落盤。

‧ 實測:同一台客戶主機,資料量由 237 筆增為 542 筆(增 2.3 倍),總時間由 36.84 秒降為 11.78 秒;換算每筆由 155ms 降為 21.7ms,約快 7 倍。

v2026.09 2026-09-21

列印報表

客戶／供應商「貨款結帳」本來就不列印，做完卻還是跳出列印詢問視窗 →已修正

技術說明：無條件開啟列印緩衝檔產生空檔，收尾又只檢查檔案存在與否

詳細處理

‧ 現象:客戶帳款結帳/供應商帳款結帳選「貨款結帳」(純結帳、不列印),選好框線按確認後,仍跳出列印詢問視窗,必須手動關掉。

‧ 根因:兩個各自獨立的問題疊加。(1) 結帳流程不論選哪一種模式都會先開啟列印緩衝檔,於是產生一個只有換行、沒有內容的空列印檔;(2) 收尾程序只用「檔案存不存在」判斷要不要叫出列印程式,沒有檢查內容,空檔一樣被當成有東西要印。

‧ 解法:兩道防線一起補。第一,貨款結帳(不列印模式)不再開啟列印緩衝檔;第二,在列印收尾處加上守門——去掉換行、空白後長度為零的列印檔一律刪除且不啟動列印程式,這是全系統共用的防線。其餘列印功能逐項確認不受影響。

v2026.09 2026-09-18

列印報表

單據內容同時含「品」字、且後方欄位是「Z+數字」（如儲位 Z424）時，列印成 PDF 明細行會跳到下一頁頁首、版面錯亂 →已修正

技術說明：中文（BIG5 編碼）裡「品」這個字的後半個位元組，剛好與列印控制碼的起始符號「~」相同。轉檔引擎在「預先偵測下一行行高」時逐位元組掃描、沒有以中文字為單位跳過，把「品」的一半誤認成控制碼開頭，接著把後面資料中的「Z424」誤解讀成「文字垂直放大 424 倍」的指令，行距瞬間暴增造成跳頁

詳細處理

‧ 現象:兩張幾乎一樣的銷貨單，儲位欄是 B1 的那張列印正常；儲位欄是 Z424 的那張，明細行被推到第 2 頁頁首、字元間距也被拉開。

‧ 根因:列印控制碼以「~」開頭、以「;」結束（例如 ~Z2 表示文字垂直放大 2 倍）。引擎預掃下一行行高時逐位元組找「~」，而「品」字的 BIG5 編碼第二個位元組正好等於「~」——引擎誤入「控制碼模式」，往後掃到資料裡的 Z424 便當成放大 424 倍，行高變成原本的 424 倍，直接爆頁。必須「含品字＋後面有 Z 接數字」同時出現才會觸發，所以此問題潛伏許久才被發現。

‧ 解法:掃描控制碼一律以「完整中文字」為單位跳過（雙位元組整字略過），且控制碼只在「~ … ;」之間才解析、資料區一律不解析。修正後兩張單據版面完全一致，原本正常的單據也逐一驗證無任何變動。

v2026.09 2026-09-17

遠端桌面

遠端桌面（WebScreen）無法用滑鼠雙擊，必須先點一下再按 Enter →已修正

技術說明：先前為了防止高權限點擊元件卡在舊連線而加的一道保護，在快速拖曳滑鼠時會誤判成「元件卡住」，導致改走一般點擊方式、進不了需要權限的視窗，雙擊因此失效

詳細處理

‧ 現象:更新後，所有遠端桌面都不能用滑鼠雙擊——選程式執行、開資料夾都要先點選再按 Enter；快速操作時有時整台遠端看起來像沒反應。

‧ 根因:遠端的點擊會先交給一個高權限元件代為執行。系統為了偵測這個元件有沒有卡死，會統計「送出後還沒收到回覆的筆數」，超過 40 筆就判定卡住、改走一般方式。但使用者快速拖曳時操作連續送出、還沒回覆的筆數會短暫衝高，連健康的元件也被誤判卡住；一改走一般方式就進不了需要權限的視窗，而雙擊的兩下又分別走了不同路徑，於是表現為雙擊無效。

‧ 解法:把判定改成「不只筆數超過，還要連續 2 秒完全沒有任何回覆」才算真的卡住。快速拖曳時只要回覆還在陸續回來就不會誤判，真正卡死才切換。實測連續高速灌入 1500 次操作，誤判 0 次。

v2026.09 2026-09-17

遠端桌面

技術說明：詢問來源的順序不對，先問到伺服器暫存裡更早的內容

詳細處理

‧ 現象:在自己電腦上複製了新的東西，貼到對方電腦時，出現的卻是之前某一次複製的舊內容。

‧ 根因:貼上時一律先問伺服器端的暫存區，而暫存區裡可能還留著更早、來源是別台電腦的內容，於是就把那份舊的貼了出去。

‧ 解法:改為依實際情境判斷：最近兩分鐘內曾在遠端桌面畫面按過 Ctrl+C（代表要貼的是遠端複製的東西），才以伺服器暫存為準；否則就是使用者在自己電腦上複製，優先取自己這台的剪貼簿。

v2026.09 2026-09-16

遠端桌面

遠端桌面：本機複製的內容永遠貼不過去（判斷條件過嚴）→已修正

技術說明：保護條件誤設為「對方剪貼簿必須是空的」，實務上幾乎不可能成立

詳細處理

‧ 現象:從自己電腦複製、貼到對方電腦完全沒作用；反方向（對方複製、貼回自己電腦）則正常。

‧ 根因:為了避免蓋掉對方剛複製的東西，原本的條件寫成「對方剪貼簿必須是空的」才允許使用本機內容。但對方的剪貼簿幾乎永遠有東西，等於這條路永遠走不到。

‧ 解法:改用剪貼簿變更序號判斷：序號和系統上次記錄的一樣，代表對方沒有新的複製動作，就用本機內容；序號變了（使用者剛在對方電腦上複製過），才讓給對方電腦自己的貼上。序號基準在「複製登記時、貼上成功後、開始操控時」三個時機都會更新。

v2026.09 2026-09-16

遠端桌面

遠端桌面：貼文字到對方電腦時畫面亂跳、選單亂開→已修正

技術說明：原本用模擬打字送文字，字母被 STK 當成快速鍵

詳細處理

‧ 現象:把文字貼到對方電腦（尤其是 STK 畫面）時，畫面會亂跳、跳出不相干的選單。

‧ 根因:文字原本是用「模擬鍵盤逐字打字」的方式送過去，而 STK 主畫面上單一字母就是功能快速鍵，於是每個字母都觸發一個功能。另外打字不會改變對方的剪貼簿，使用者再按一次貼上時又會拿到舊內容。

‧ 解法:改成先把文字放進對方電腦的剪貼簿，再送出 Ctrl+V，全程不再模擬打字；兩個動作走同一條通道依序執行，順序有保證。

v2026.09 2026-09-16

遠端桌面

遠端桌面：複製大資料夾後，對方電腦停住很久不能操作→已修正

技術說明：複製當下就整包搬運；改為複製只記清單、真正要貼時才傳

詳細處理

‧ 現象:在對方電腦上複製一個內容很多的資料夾後，那台電腦會停住一段時間，鍵盤滑鼠都沒反應。

‧ 根因:按下複製的當下，系統就把整個資料夾壓縮、編碼、整包送回伺服器；這段期間遠端代理程式忙著搬運，沒空處理鍵盤滑鼠。

‧ 解法:改成商用遠端軟體的做法：複製時只記錄「有什麼」（種類、名稱、大小），真正貼到另一台時才傳送內容。實測複製動作由原本的等待縮短到 0.05 秒。

v2026.09 2026-09-16

遠端桌面

遠端桌面：傳大檔期間，對方電腦的鍵盤滑鼠卡住→已修正

技術說明：改為一塊一個指令，每塊之間讓代理程式回頭處理操作

詳細處理

‧ 現象:跨電腦傳送較大的檔案時，來源那台的鍵盤滑鼠會卡住，要等傳完才能動。

‧ 根因:整包資料在同一個指令裡一次傳完，遠端代理程式是單執行緒，這段時間內排隊的鍵盤滑鼠指令全都得等。

‧ 解法:改成「一塊一個指令」，每傳完一塊就回到主迴圈處理排隊的操作。實測傳送 6.3MB 期間，來源電腦的回應時間最慢 0.16 秒（原本被佔住 0.63 秒），全程可操作。

v2026.09 2026-09-16

遠端桌面

遠端桌面：鍵盤滑鼠突然完全沒反應，要重開才恢復→已修正

技術說明：高權限輸入小幫手只接受單一連線，舊連線殘留就把它塞住

詳細處理

‧ 現象:遠端操作到一半，整台電腦的鍵盤滑鼠都送不進去（畫面還在更新），必須重新啟動才恢復。

‧ 根因:為了能點選需要系統管理員權限的視窗，輸入指令會先送到一支高權限小幫手；它一次只接受一個連線，網路異常留下的舊連線會把它佔住，後來的連線全部進不去。

‧ 解法:小幫手改為可同時處理多個連線，並在每次輸入後回覆確認；代理程式若連續多次沒收到確認，就主動切斷重連並改用一般權限注入，不再整台失去反應。

v2026.09 2026-09-16

遠端桌面

遠端桌面：滑鼠操作不精準（中鍵被當左鍵、滾輪捲過頭、拖曳放開後卡住、連點兩下時好時壞）→已修正

技術說明：按鍵對應、滾輪換算、放開事件與雙擊判定全面修正

詳細處理

‧ 現象:滑鼠中鍵與側鍵（上一頁／下一頁）被當成左鍵；觸控板滑一下就捲過頭且不能左右捲；拖曳時滑出畫面再放開，對方電腦的左鍵會一直被按著；連點兩下選字有時有效有時無效。

‧ 根因:按鍵只分左右；滾輪每次事件固定捲一格；放開事件只掛在畫面元素上，滑出畫面就收不到；雙擊原本用程式模擬，反而多送了一次點擊，被系統判定為取消選取。

‧ 解法:按鍵改為照實傳送五個鍵；滾輪依實際滾動量換算格數並支援左右捲；拖曳期間改在整份文件接收放開事件；雙擊改為只送「按下」交由系統自行判定，與本機行為一致。

v2026.09 2026-09-16

遠端桌面

遠端桌面：畫面固定比實際慢一格→已修正

技術說明：影像組裝要等下一格開始才送出上一格

詳細處理

‧ 現象:遠端畫面看起來總是慢半拍，尤其在快速移動視窗或捲動時特別明顯。

‧ 根因:影像資料在組裝時，必須等到「下一格開始傳」才確定上一格結束，於是每一格都固定晚送一格的時間。

‧ 解法:讓影像來源在每一格標上長度，收滿就立刻送出。實測畫面延遲減少約 0.07 秒（每格提早一整格）。

v2026.09 2026-09-16

遠端桌面

遠端桌面：iPhone／iPad 畫面反覆頓一下、延遲累積→已修正

技術說明：三個原因疊在一起：監看機制每 2 秒硬跳、播放器內建的追延遲用「跳著追」、追得太猛把緩衝抽乾

詳細處理

‧ 現象:用 iPhone／iPad 觀看時，畫面會反覆頓一下、亂跳；中途調整後一度變成持續閃爍。

‧ 原因一(頓、延遲累積):監看機制的門檻設得太低，正常播放時就一直觸發「直接跳到最新畫面」，等於每 2 秒打斷一次解碼。

‧ 原因二(亂跳):播放元件本身也有一套追延遲機制，作法同樣是「直接跳」，在 iPhone 上只要緩衝超過 0.5 秒就跳一次——手機網路下非常頻繁，畫面就一直亂跳。

‧ 原因三(閃爍):改成用「稍微加速播放」吸收延遲之後，一開始設得太猛(1.5 倍速)，而 iPhone 上的緩衝本來就很薄(約 1 秒)，加速會把緩衝抽乾 → 播放反覆停住再補，看起來就是閃爍。

‧ 解法:①監看機制只在明顯重播舊畫面(落後超過 3 秒)時才跳；②iPhone／iPad 關閉播放元件內建的「跳著追」，改由平順加速吸收；③加速改得很輕——落後 1.5 秒才開始、最多 1.15 倍(肉眼幾乎看不出)、追到 0.8 秒就停手，永遠保留約 0.8 秒的緩衝當墊底，不會被抽乾。

‧ 實機驗證(iOS 18，連續操作約 4 分鐘、185 次操作):斷線 0 次、串流中斷 0 次、未退到備援播放；使用者確認不再閃爍、延遲可接受。修正前同一支手機在 2 分鐘內出現 4 次以上串流中斷。

v2026.09 2026-09-14

列印報表

Windows 10/11 開機後第一次列印,STK 畫面停住、鍵盤滑鼠沒反應→已修正

技術說明：Windows 10/11 新版列印元件被載入 STK 主程式,使鍵盤滑鼠送不進 STK;改由列印小幫手(PrnAsk)在旁邊列印、背景啟動,並排除防毒首次掃描延遲

詳細處理

‧ 現象(客戶 [0028] 各台「直接列印」的電腦、[0046] S002、[0081] S004):每天早上開機後,第一次進 STK、印第一張銷貨單(出貨單)之後,畫面停在下一張單頭的提示框,按鍵盤、點滑鼠都沒有反應;視窗標題沒有出現「沒有回應」;只能從工作列按右鍵把 STK 關掉再重開,重開後當天再印都正常。

‧ 發生條件:Windows 10(21H2 以上)或 Windows 11,且列印設定為「不詢問、直接列印」(列印時由 STK 自己把資料送到印表機)。設定為「列印前先詢問」的電腦(列印交給列印小幫手 PrnAsk)沒有發生,例如 [0007] 的三台 Windows 11 電腦。

‧ 鑑別方法(卡住當下遠端實測):(1)STK 其實沒有當機:Windows 判定它「有回應」、CPU 使用幾乎為 0、正在等待按鍵;(2)鍵盤焦點、最前面的視窗都是 STK 自己,沒有被別的程式搶走;(3)用遠端模擬實際按 ESC、方向鍵、點選單都沒反應,但把 ESC「直接投遞」給 STK 視窗,STK 立刻回到主選單 → 證明 STK 本身正常,是 Windows 把實體鍵盤滑鼠的輸入擋在 STK 外面;(4)第一次列印後,STK 程式裡多了 Windows 10/11 新版列印元件(Print.PrintSupport、CoreMessaging),而 Windows 的 32 位元列印轉接程式(splwow64)正是由 STK 在第一次列印時叫起的。

‧ 已排除的可能:輸入法吃掉按鍵(關閉輸入法仍無效)、按鍵卡住、焦點被搶、視窗被停用、把視窗縮小再還原、畫面重繪設定、印表機名稱錯誤、列印佇列卡件、資料鎖定等待,都已逐一實測排除。

‧ 根因:在 Windows 10(21H2 以上)與 Windows 11 上,開機後第一次列印時如果由 STK 在自己程式內直接列印,Windows 新版列印元件會掛進 STK 的主執行緒,之後實體鍵盤滑鼠就送不進 STK。已受影響的 STK 無法自行恢復,只能重開;同一次開機內之後再印不會再發生,所以症狀是「每天第一次」。

‧ 補充:Windows 10 也會(2026-09-15):客戶 [0081] S004 為 Windows 10 21H2,同樣發生「印完畫面不動、關掉重開才能印」;遠端檢查同樣是 STK 在第一次列印時叫起 Windows 的 32 位元列印轉接程式,STK 程式裡也同樣載入這組列印元件(Print.PrintSupport、CoreMessaging),確認不限 Windows 11。同一家的其他電腦:設定「列印前先詢問」的主機不受影響;同為 Windows 10、設定「直接列印」的 S006 有同樣風險,已列入更新;Windows 7 沒有這組元件。修正方法相同:更新 STK 主程式與列印小幫手。

‧ 解法一:列印改交給列印小幫手(解決畫面不動):原本「直接列印」由 STK 自己送印表機,改為由 STK 叫起列印小幫手 PrnAsk,以參數 /DIRECTPRINT /PRINTER:"印表機名稱" /LOCSYS:"設定目錄" "列印暫存檔" 在另一個獨立程式中列印,印完就自動結束;STK 不再載入 Windows 列印元件,因此不會再被擋住。印表機、紙張、邊界沿用原設定(兩邊共用同一套列印引擎)。列印小幫手新增 /PRINTER: 參數:STK 選印表機時會先看 printer.cfg,而小幫手原本只看 System.ini,兩者可能不同,所以由 STK 直接告訴小幫手要印哪一台。找不到 PrnAsk.exe 時才退回原本由 STK 自己列印。

‧ 解法二(方法2):STK 不等列印小幫手啟動:STK 叫起小幫手時改在背景執行緒啟動(新增 STK_SHELLEXECASYNC,不繼承 STK 的系統資源),STK 馬上回到畫面可以繼續打單;就算小幫手啟動較慢,也只是紙晚幾秒出來,不會擋住操作。STK 內所有叫起小幫手的 6 個地方(直接列印、列印前詢問視窗、預覽)都改用這個方式;背景啟動失敗時才退回原本方式。舊式外部列印程式 dospntgo 與開啟 PDF 的地方不變。

‧ 解法三(方法1):排除防毒軟體的首次掃描:改完後發現開機後第一次列印仍要等約 4 秒才回到畫面。實測時間:STK 送出 21:13:04.672 → 小幫手到 21:13:08.982 才開始執行,列印本身只花 0.5 秒;檢查確認是 Windows Defender 在開機後第一次執行 PrnAsk.exe(約 8MB)時先做完整掃描。加入防毒排除後,同樣情況只等 0.1 秒(22:09:22.516 → 22:09:22.619)。已把 Defender 排除 C:\STK(各站 STK 主程式與列印小幫手)與 C:\StkRdp(遠端共看程式)寫進安裝程式與網路安全設定工具。

‧ 方法1 與方法2 各處理什麼:方法1(防毒排除)讓列印小幫手開機後第一次啟動變快,但每台電腦都要執行設定才生效;方法2(背景啟動)保證 STK 畫面不會被小幫手的啟動時間擋住,不需要每台設定。兩者互補,都已完成。

‧ install_agent.bat(安裝程式)修改:原本只把 C:\StkAgent 與 4 個遠端代理程式加入防毒排除;在同一行排除指令中加入 C:\STK 與 C:\StkRdp,原有排除全部保留,並把完成提示改為「Defender 排除 C:\StkAgent C:\STK C:\StkRdp」。此修改在該台電腦重新執行安裝時生效。

‧ unblock_all.bat(網路安全設定工具)修改:新增 C:\StkRdp 的「清除網路下載標記」步驟(與 C:\StkAgent 相同做法),並加入 C:\StkRdp 防毒排除;原有 C:\STK、C:\StkAgent、\\S001\stk\ 的排除不變。此工具會重新啟動檔案總管、關閉 SmartScreen,最後等待按鍵,建議在現場執行。

‧ 實測結果(客戶 [0028] S001):更新後每次重開機第一次列印都不再卡住,Windows 列印統計皆為 0 錯誤;加入防毒排除後,第一次列印的等待時間由 4.3 秒降為 0.1 秒。

‧ 修改檔案:HBSTK\compat\print_spool.prg(直接列印改交小幫手、背景啟動)、HBSTK\c_code\printer_c.c(新增背景啟動函式)、PRNASK\source\main.prg 與 PRNASK\source\fw_prnout.prg(新增 /PRINTER: 參數)、SOCKET\StkAgent\build\install_agent.bat 與 unblock_all.bat(防毒排除)。另加入診斷用的空閒心跳紀錄(HBSTK\compat\writedebuglog.prg、HBSTK\source\STK.PRG,只在開啟除錯紀錄時運作)。

‧ 升級注意:STK 主程式(Stk32.exe)與列印小幫手(PrnAsk.exe)必須一起更新;PrnAsk.exe 要放在設定 PRNASK_HOME_PATH 指定的目錄(通常是 C:\STK\站號)。只換主程式時,舊版小幫手仍能列印,但無法保證與 STK 選定的印表機一致。

v2026.09 2026-09-13

系統穩定

開啟「營運儀表盤」後整台電腦操作變慢→已修正

技術說明：儀表盤每 10 秒同步重掃大量歷史交易,卡住主程式

詳細處理

‧ 現象:打開營運儀表盤後,同一台電腦操作(打單、選單)變得很遲鈍、像卡住;關掉儀表盤就恢復正常。

‧ 根因:儀表盤每 10 秒自動更新時,會一次重掃近一年的交易明細(單次掃描達 5 萬多筆、約 1.2 秒),而且是在主程式同一條執行緒上同步進行 → 這 1.2 秒內鍵盤滑鼠全都得等它,每 10 秒卡一次。

‧ 解法:①只有儀表盤在最前面時才自動更新(縮到背景就不掃、不干擾打單)②把最耗時的「歷史高峰」計算改成只在開窗與按「重新整理」時做一次並暫存,例行更新只算當期少量資料③自動更新間隔由 10 秒放寬為 30 秒。

‧ 修改檔案:source\P78.PRG。

v2026.09 2026-09-13

統計查詢

技術說明：虛擬監視器(usbmmidd)在不同會話下無法同步

詳細處理

‧ 補齊:先前只做 usbmmidd(不黑)半段;本次把解析度守護 setres.ps1 也讓 agent 自動化。

‧ clone 確保:VIRTUAL_MONITOR=1 站接回實體螢幕+開電源會變延伸雙螢幕(幽靈螢幕/滑鼠視窗跑掉/WebScreen座標錯亂)→ setres.ps1 偵測 VirtualScreen>PrimaryScreen 就 DisplaySwitch /clone 強制同步顯示,消除副作用。

‧ agent 三處:SyncAgentSelf 加拉 setres.ps1;EnsureVirtualMonitor 開頭呼叫新函式 EnsureResKeeper(部署 setres.ps1 + 用 GetDesktopUser 建 STK_SetRes 每分鐘 /it 互動排程,冪等 query 沒有才建);比照 L1328 watchdog 範本。

‧ 踩坑:agent 自身 session 碰不到顯示 API(EnumDisplaySettings 回空),故解析度/clone 必須靠 /it 互動排程在桌面使用者 session 內跑。

‧ uninstall_agent.bat:加刪 STK_SetRes 排程 + 逐站清 setres.ps1/.vmon_res/keeper log。

‧ INI_Editor:ini_editor.py + ini_template.json 都登記 VIRTUAL_MONITOR(預設0)+VMON_RES(預設auto)於 stk_agent.ini [Display]。uploader 納入 setres.ps1。三 EXE(INI_Editor/uploader/updater)+agent 都重編。

‧ build:Stk_Agent.exe exit0 無警告;setres.ps1 PSParser 驗證無語法錯。

v2026.09 2026-09-09

網頁遠端

RDP 遠端切換時推流中斷無畫面→已修正

技術說明：session_pusher 崩潰後未啟動備用

詳細處理

‧ 現象(客戶 [0007] S006/S007,不用 MS 遠端桌面卻連不上):S006 WebScreen 一直重連;S007 FPS:30 黑畫面。同客戶其他站正常。

‧ 根因(S006 log 定論):agent 處在 RDP 跟隨模式(RDP_FOLLOW=1,疑似全站誤推),START_STREAM 不自己開 pusher 而寫 session_req.json 交給 SYSTEM 的 session_pusher;但 log 明確「session_pusher dead」→ 沒人執行請求 → pusher 從未啟動 → 一直重連。S007 為 session_pusher 活著但把 pusher 丟進無可見桌面的 session(Session 0)→ 有推流但全黑。

‧ 防呆(使用者要求):新增 SessionPusherAlive()(tasklist 查 session_pusher.exe);START_STREAM 委派前檢查,若 RDP 跟隨模式且 session_pusher 已死 → LogMsg fallback + 喚醒 STK_RDP_Watch + s_lRdpActive:=.F. 退回「直接在本 session 開 pusher」。不用 RDP 的站誤設 RDP_FOLLOW=1 也不再黑畫面/連不上。

‧ 同版另含:SyncAgentSelf 修正(exe 已最新仍同步 install_agent.bat 等輔助檔)。

‧ 正解提醒:RDP_FOLLOW=1 不該全站無差別推,只有真用 MS 遠端桌面的站才開;不用的站維持 0(直接開 pusher 最穩)。

‧ 即時處理 S006/S007:Commander CONFIG_PUSH RDP_FOLLOW=0 + RESTART_AGENT(現行 agent 即生效);根治=部署本次防呆 agent。

‧ 修改檔案:source\stk_agent.prg(備份 .bak_pusherfallback_20260909)。重建 Stk_Agent.exe(21:37)。待上傳。

v2026.09 2026-09-09

系統穩定

更新結束畫面誤判失敗(0 筆卻標紅)→已修正

技術說明：正則誤抓略過數字、檔案佔用誤判失敗

詳細處理

‧ 現象(客戶迷惘):更新全成功(351 檔部署、各站 fail=0),結束畫面卻紅字「更新失敗 —— 有 5 項失敗」。

‧ 兩個誤判根因:

1. `_fail_count` 正則把「S001 -> OK (ok=0 skip=7 fail=0)」的 skip=7 的 7 誤抓成失敗數;且 fail=0 分隔是 = 沒涵蓋 → fallthrough 到「含 fail 字樣=失敗」。→ S001~S004 的 OK 行全被標紅。

2. 「FAIL stk_updater.exe: [WinError 32] 檔案正由另一程序使用」= 更新器執行中無法覆蓋自己(1475 行註解已明講正常,WatchDog 從 FTP 換版兜底),卻被當失敗。

‧ 解法(全在 stk_updater.py):

‧ _fail_count v2:數字正確綁定 fail(分隔含 = : 全形冒號;fail=0/失敗 0 判 0;N FAIL 用負向前瞻避免抓到前面 skip 的數字)。

‧ 自我覆蓋 WinError 32 → 改記「執行中鎖定,改由 WatchDog 換版(正常)」不觸發紅色。

‧ _classify 加良性略過白名單(unchanged/no-overwrite/exists/未變/執行中鎖定/watchdog)→ 正常略過不列警告;全好時=乾淨綠色「[OK] 更新成功」。

‧ _colorize(逐行即時上色)改共用同一個 _classify,避免兩套邏輯分歧;良性略過 live 由黃改白,減少噪音。

‧ 驗證:13 條 _classify + 8 條 _colorize 迴歸測試全過;PyInstaller 重建 stk_updater.exe(19:43, 32-bit)。

‧ 修改檔案:HBSTK/build/update_server/stk_updater.py(備份 .bak_classify_20260909)。待隨 updater 一併上傳。

v2026.09 2026-09-09

資料更新

打包時唯讀檔殘留導致失敗→已修正

技術說明：清不掉唯讀舊 exe 使複製撞「已存在」

詳細處理

‧ 現象：跑 stk_uploader 打包時 `[WinError 183] 當檔案已存在時，無法建立該檔案: ...\update_pack\UPDATE`。

‧ 根因：pack() 開頭用 `shutil.rmtree(PACK_DIR, ignore_errors=True)` 清舊包，但 UPDATE 內含唯讀的 stk.exe(3MB)，ignore_errors 清不掉唯讀檔 → update_pack\UPDATE 殘留 → 後面 `copytree(usrc, dst)` 撞「目的已存在」。與 make_update_pkg 同一個唯讀坑。

‧ 修法：stk_uploader 新增 `_force_rmtree()`（onerror chmod S_IWRITE 重試），pack() 開頭改用它清 PACK_DIR。重編 stk_uploader.exe(32-bit, 31.5MB)。

‧ 修改檔案：`HBSTK\build\update_server\stk_uploader.py`。

v2026.09 2026-09-09

資料更新

資料庫結構更新崩潰(索引失效)→已修正

技術說明：內含 exe 日期比里程碑新使結構更新被跳過

詳細處理

問題：資料庫結構更新崩潰(索引失效)

根因：內含 exe 日期比里程碑新使結構更新被跳過

處理方法：補全結構檔+統一日期標準。

v2026.09 2026-09-09

資料更新

批次更新卡死(共用/覆蓋/無回應)→已修正

技術說明：每站誤判、設定覆蓋環境、未處理錯誤彈窗

詳細處理

問題：批次更新卡死(共用/覆蓋/無回應)

根因：每站誤判、設定覆蓋環境、未處理錯誤彈窗

處理方法：改單次執行+環境優先+批次不彈窗。

v2026.09 2026-09-09

進銷存作業

詢價/詢購批增「銷貨異動」誤帶其他客戶→已修正

技術說明：掃描軸錯誤

詳細處理

‧ 問題:INQUIRY/ENQUIRY 詢價(購)單「批增」選銷貨異動時,抓到所有客戶的銷貨,客戶要求只抓「該詢價單廠商進過貨」的零件

‧ 根因:AppendByIdHistory 外層以索引2(cId+dAccDate)固定 dbSeek 廠商代號;進貨單 cId=廠商(正確),但銷貨單 cId=客戶,過濾軸錯誤,對銷貨無效

‧ 解決:nSellType=2 時先蒐集「該廠商(aHead[ID]/EM_ID)在交易天數範圍內進過貨的零件」成 hSupParts,再改用索引4(dActDate)掃描期間內全部銷貨,明細迴圈頂端閘門只保留 hSupParts 內的零件;進貨異動走 ELSE 完全不變

‧ 踩坑:LOCAL 錨點在兩函式重複→改用含 "ActMain" 的唯一兩行錨點;LOOP 前須先 dbSkip,否則跳過原迴圈尾 dbSkip 造成無限迴圈

‧ 修改檔案:INQUIRY.PRG(2761/2821-2851/2860-2865)、ENQUIRY.PRG(同結構,廠商常數 EM_ID)

v2026.09 2026-09-07

列印報表

列印字高會跳動→已修正

技術說明：PDF 字級遞增

詳細處理

問題:[0139] FONT_FIT=1 下同一張單「中文高度逐漸長大」(PDF 字級 9.6=>10.56=>14.08)。PDF 字級萃取鐵證+紅框比對=v1 設計缺陷:FIT 基準用「每行實際行前進量」,分段行距表單(表頭 L9/表身 L20)字高必跳+取樣落後一段(第一行明細被表頭行距污染)。

演進:v2(字級x倍率)語意變更被否決(已有客戶用 0.80 原定義,不能逼客戶改值);v3b 定案=RATIO 保留原定義(行距比例),基準改「文件首行行距鎖定」(每份文件重置,AdvanceLine 首次鎖定,首行前以當下字級+行距即時估)=全文單一基準,同字級恆同高。倍率夾 0.5~1.5。驗證:RATIO=0.80 全文只剩英數 16.56/中文 18.72 各一種,通過。

踩坑:函式整段替換用短錨(RETURN nPt)誤中函式中段縮排更深的同字串,切壞函式(E0010)——區段替換要用「下一個函式頭」當終點錨。

修改檔案:compat/prn_to_pdf.prg(.bak_fitv2/.bak_fitv3);部署區 PrnAsk+STK32 已更新。0139 換版後 FONT_FIT=1+RATIO=0.80 直接可用。

v2026.09 2026-09-07

列印報表

換印表機後直接列印死當→已修正

技術說明：直印依賴的印表機記憶未同步

詳細處理

‧ 問題:客戶 Ctrl+P(P77)切換印表機後立刻列印,STK32 鍵鼠全無反應只能強殺。

‧ 根因:直接列印(PRNMETHOD=1+SKIPASK=1+AUTOFMT=1)走行程內 SpoolDirectPrint,

用的印表機是 STATIC s_cLastPrinter,只在啟動 InitPrintSpool() 載入一次(printer.cfg 優先、次 System.ini PRINTER=)。

P77 存檔只寫 System.ini,static 從未更新 → 換機後仍印舊印表機。S002 啟動值為

Epson LQ-1170C(lp1)(網路埠),目標不通時 CreateDC/StartDoc 行程內阻塞 = 假死。

「調整視窗大小才會當」為巧合,與 resize 無關。

‧ 解決:

1. print_spool.prg 新增 SetLastPrinter():更新 s_cLastPrinter + 同步寫 printer.cfg;

2. P77.PRG lChanged 存檔時呼叫 SetLastPrinter(cPrinter) + SetPrnPaperOpt(cPaper)(紙張 static 同病);

3. SpoolDirectPrint 加防呆:STK_PRINTEREXISTS 不存在就 fallback 預設印表機。

‧ 踩坑:遠端用 PS ReadAllText/WriteAllText 開 DEBUG_LOG 把 BIG5 System.ini 中文全毀(UTF-8 FFFD);

以 S003 同客戶範本逐行「模擬毀損比對」證明原文+殘留 bytes 反推(自訂=A6DB AD71)完整救回。

遠端改 BIG5 檔一律 ReadAllBytes/WriteAllBytes。

‧ 修改檔案:compat/print_spool.prg(SetLastPrinter、SpoolDirectPrint 防呆)、source/P77.PRG(存檔同步)。

另 0046 S002 System.ini 已開 DEBUG_LOG=1 供後續驗證。

v2026.09 2026-09-07

進銷存作業

詢價轉銷貨很慢→已修正

技術說明：反覆開關統計檔+逐筆寫碟

詳細處理

打點鐵證鏈:INQ2SELL(迴圈)32筆=0.65s 無罪 => 尾段 gap 8.2s => INQ2SELL-TAIL 指名 stat=6.45(StatUpdate)=> 每筆 StatOneUpdate 呼叫 2~3 個 XxxYearUpdate,每個「網路開DBF+載CDX+用完關」=~100 次開關檔。

三層優化:

1. StatUpdate 迴圈前預開四統計檔(CusYear/SupYear/ParYear/YearIO)+YearBatchMode,XxxYearUpdate 見已開直接用;結束只關本函式開的(P723 .bak_statbatch)。全部走 StatUpdate 的轉單(含 QuotToSell)一起受益。

2. GetSPriceFromInq:修「存 PartKey 還原給 Parts」張冠李戴 bug+單內價格快取(InqPriceCacheSet 開關,非轉單期間行為不變)(.bak_inqpricecache)。

3. 轉單區間關 HARDCOMMIT+結束 dbCommitAll 一次落盤(比照 DOMPUR 匯入案;失敗出口也還原)(.bak_inqhc)。

★舊版 Clipper 完全沒優化卻更快之謎:功能一模一樣(StatUpdate 等全有)——Harbour HARDCOMMIT 預設開=每次解鎖強制 flush DBF 檔頭到網路;Clipper 無此概念靠 DOS 緩衝。=Harbour 轉寫系統「天生慢」的通病,任何逐筆寫入迴圈都該考慮區間關閉。

待辦(用戶提醒):客戶忙,晚點請 0007 S006 實測轉單+撈 INQ2SELL/TAIL 打點見證 8s=>1s;9999 驗證統計數字正確後更新部署區;DEBUG_LOG=2 診斷完建議降 1。

v2026.09 2026-09-06

查詢統計

適用零件視窗品名欄重複顯示年份→已修正

技術說明：欄位組字資料驅動共用

詳細處理

問題:PartsList/ListByKind(PartsSearch 內)品名-適用規格欄尾端重複顯示年份(年份已有獨立欄),客戶堅決反對。

追查(繞三圈的教訓):DBF 資料乾淨(cSpec 空/cYear 有值)=>組字問題。改 QUOT 建陣列兩輪無效=>埋 log 發現該畫面根本不走 ListByKind=>PartsList 走 Table() 引擎,欄位定義存 SET/SUBFORM1.DBF(不在程式碼),「品名-適用規格」欄全版面共用 ShowPartKeyName(2)=真兇在 P113.PRG:8137 尾端接 cYear。

修改(STK32,全部同步 STK16):

1. P113 ShowPartKeyName(2) 移除年份拼接(Table 版面共用,一處修全版面生效)。

2. QUOT MakePartsArray/RamPartsList 建陣列同款移除(BrrayBrowse/ListByKind 路徑)。

3. TOOLS 的 MakeFTSArray/GetPartsArrayBy2 本來就沒接年份,不動。

心法:Table() 畫面的欄位組字在 SUBFORM1.DBF 的 CGETBLOCK(資料驅動),改程式碼前先 dump 該 alias 的欄位定義;BrrayBrowse 畫面才是程式內 aSetGetBlock。兩引擎並存,同名畫面兩條路都要修。

修改檔案:P113.PRG/QUOT.PRG(STK32+stk16 各一套;STK16 備份保留待 DOSBox 重編驗證)。STK32 驗證 OK,部署區已更新(14:47)。

v2026.09 2026-09-06

列印報表

Ctrl+P 破壞呼叫端畫面→已修正

技術說明：列印詢問誤被非選單呼叫

詳細處理

1. Ctrl+P 畫面破壞:P77 出口無條件 Status() 重繪狀態列,從訂單等畫面按 Ctrl+P 回來畫面被污染。修=P77CallerIsMenu() 沿 ProcName 鏈跳過 codeblock/InKeyWait/MsReadKey 等通用取鍵層,第一個真實呼叫者=PullDownMenu 或含 MENUSEL(滑鼠路徑帶模組前綴)才准 Status();其他呼叫者一律禁止(使用者規則:其他呼叫者皆不可存在)。踩坑:InKeyWait 是通用層不能入白名單,要跳過往上找。實測選單鍵盤/滑鼠都立即更新、作業畫面不再被破壞。(P77.PRG .bak_statusgate/statusgate2)

2. WV2 恆橫印事故(自責):FONT_FIT md5 測試用 /D:scratchpad,FwSaveSkip 把輸出目錄持久化進 System.ini PRN_OUTDIR=>之後列印 PDF 掉到 scratchpad,與 PRN 不同目錄=>FwDoPrint GDI direct 分支失效退回 PDF 送印=>方向被 PDF 頁面吃死恆橫印。止血=刪 PRN_OUTDIR 行;根治=main.prg /D: 設 FwSetOutDirCmd 旗標,FwSaveSkip gate 住不寫 PRN_OUTDIR(fw_prnout/main .bak_outdircmd)。踩坑:函式插進檔頭 STATIC 宣告區中間=E0004。

3. GDI 寬紙橫印:9.9x5.5 寬紙選橫印=與直印相同是 20260730 定案(僅窄紙+紙前進旋轉90),維持現狀(使用者選 B)。

4. P77 主視窗:垂直 clamp 寫死 23(80x25 時代)=>只能左右移。改動態 MaxRow()+無保存幾何時預設置中(100x30 垂直可動 1~6)。(.bak_p77center)

5. 0139 log 追蹤:字高同步鏈已生效(07:20 ADJ=7 -> 07:23 ADJ=3 即時讀到,W:/C: 一致);PrnAsk 09/05 18:55 版;四份 PDF 驗證=同字高 bit 級相同(GDI/WV2 產 PDF 同引擎本來就一樣)、3vs5 不同=字高生效。

v2026.09 2026-09-04

系統維護

自動同步時間戳判斷錯誤導致 A/B 槽檔案判別失靈→已修正

技術說明：batch %%~tF 時間字元在 CP950 跨午夜歧義

詳細處理

問題(使用者實測):watchdog 說好挑最新槽執行,實際像隨機挑——新版寫進槽後常不切換(9999 S001 曾 A 槽較新卻一直跑 B,要 RESTART_AGENT 才換)。

根因:watchdog_user.bat 用 %%~tF 取「本地化日期時間字串」再用字串 gtr 比較。繁中 Windows 格式=「2026/09/04 下午 04:47」:跨上午/下午時比到「上」「下」字的 BIG5 碼位(上0xA457>下0xA455→上午被判較新!);12 小時制 01:xx(下午)字串小於 11:xx(上午);不同 Windows 日期格式行為各異=實質亂數。

修:改 PowerShell `Get-Item A,B | Sort LastWriteTime -Desc | Select -First 1` 比真實檔案時間,天然處理單槽缺檔;移除 DA/DB/gtr 全套。

部署:uploader SOCKET_AGENT_FILES 含 watchdog_user.bat;各站 agent SyncAgentSelf 的 SyncOneNewer 會自動拉新版到本地。9999 已鋪。

心法:★bat 的 %%~t 是本地化字串,永遠不要拿來排序/比較;要比檔案時間一律 PowerShell LastWriteTime。

備份:watchdog_user.bat.bak_newestfix_20260905

v2026.09 2026-09-04

系統維護

檔案同步僅比較修改時間導致代理無法更新→已修正

技術說明：只靠 mtime 判斷有精度問題

詳細處理

問題：客戶按 SYNC_NOW 後 PrnAsk 都不更新要等很久;Stk_Agent 更新更慢(5~11分鐘)。

根因：

1. SyncFilesFromNetwork copy 模式只比 mtime 不比 size(stk_agent.prg:825)——新版 mtime 湊巧不比 C: 新就永遠 SKIP(updater 20260601 同款假新版事故,agent 端沒補)。PrnAsk/prn2xlsx 從本機 C:\STK\S00X 執行(print_spool.prg ResolvePrnAskPath),全靠這段同步。

2. RdpSyncToLocal(2817)、SyncAgentSelf(926)同款只比 mtime——共三處。

3. CMD_SYNC_NOW handler 沒掛 SyncAgentSelf——按 SYNC_NOW 不會更新 agent 自己,只能等輪詢。

4. updater 派完 W: 後只能等各站輪詢(SYNC_SEC=600 且需閒置)。

修改：

‧ stk_agent.prg 三處比較全加 size:大小不同一定同步(SyncFilesFromNetwork/RdpSyncToLocal/SyncAgentSelf)

‧ CMD_SYNC_NOW handler 加掛 SyncAgentSelf():點 SYNC_NOW 後新版寫空 slot,watchdog 一分鐘內換版

‧ PULL OK/SKIP 回報附檔案大小供驗證

‧ stk_updater.py 新增 relay_sync_now_all() 於 Step 9c:distribute+SET merge 完成後經 relay 廣播 SYNC_NOW,各站秒級同步(收15秒回報逐站印 ok/skip/fail;relay 連不上僅記log不中斷)

架構確認(三路研究)：STK32 從 W:\S00X 執行(SMB,同步僅備份);PrnAsk/prn2xlsx 從 C:\STK\S00X 執行(本地,同步是生效關鍵);agent 從 C:\StkAgent A/B 槽執行。

生效鏈(改後)：updater 派送完→自動廣播 SYNC_NOW→PrnAsk/prn2xlsx 秒級落地+agent 一分鐘內換版,全鏈零人工。

備份：stk_agent.prg.bak_syncsize_20260904、stk_updater.py.bak_syncbcast_20260904

注意：stk_updater.exe 需重新打包(Py3.12)才會帶到廣播功能;新舊混布安全(舊 agent 認得 SYNC_NOW,只是沒 size 修正)。

v2026.09 2026-09-03

系統維護

備份目的地磁碟不存在時備份無法進行→已修正

技術說明：備份 bat D:/E: 缺失會中止

詳細處理

問題：備份目的地磁碟不存在時備份無法進行

根因：備份 bat D:/E: 缺失會中止

處理方法：新增遞補:無 E: 用 D:、無 D: 用 C:。

v2026.09 2026-09-03

效能速度

彙整大量資料時當機→已修正

技術說明：頻繁開關資料檔

詳細處理

問題：彙整大量資料時當機

根因：頻繁開關資料檔

處理方法：改批次模式預開檔案節省資源。

v2026.09 2026-09-03

資料安全

轉單廠商過濾污染→已修正

技術說明：以代號變數過濾避免作用域污染

詳細處理

問題：轉單廠商過濾污染

根因：以代號變數過濾避免作用域污染

處理方法：發號查詢優化。

v2026.09 2026-09-03

系統穩定

網路瞬斷時報錯畫面呈現→已修正

技術說明：遇網路瞬斷時原本直接彈系統錯誤畫面

詳細處理

問題：網路瞬斷時報錯畫面呈現

根因：遇網路瞬斷時原本直接彈系統錯誤畫面

處理方法：新增網路狀態偵測,轉單/列印遇瞬斷改為友善提示並自動重試,不再中斷作業。

v2026.09 2026-09-02

標籤信封

標籤一張跳成兩張根治→已修正

技術說明：標籤高+上邊界使行溢出被推出頁底

詳細處理

‧ 現象:TSC TTP-345 條碼標籤 GDI 預覽 4 張變 8 頁,OEM/PSA 行被拆到下一頁(客戶版面設定有上邊界)。

‧ 根因:標籤高僅 85pt,z2 修正後行距變正確(內容多 9.6pt),最後一行餘裕只剩 9.8pt;版面上邊界 MT>0.62cm 就把最後一行推出頁底->GDI 立即換頁攔腰拆。pre-0901 靠 z2 疊行「省高度」擦邊沒事(MT>1.23cm 才拆)。

‧ 兩解並行:A(急救)客戶取消該印表機上邊界->立即正常(已證);B(治本)引擎加 s_lLabelPitch:載入預掃 ~I 後 60 字內含 [? 的個數>=2(=每張標籤自帶紙張起點,貼紙/信封型)自動啟用->換頁只在 ~I 錨點(不看 ExplicitPaperBreak),段內行溢出不自動換頁(超出裁切,同實體貼紙機)。一般報表(1 個 ~I,靠 FF/自動分頁)完全不受影響。

‧ ★機制釐清:~I 內的 [?紙張] 會設 s_lExplicitPaperBreak,把既有 966 行 ~I 換頁(s_lLabelMode)擋死->標籤一直靠「行溢出」換頁,才會被邊界一推就拆。

‧ 驗證:MT=0.8cm 原拆 6 頁->修後 4 頁;無邊界全套回歸 bc=4/lbl=6/env=11(Z2)/對帳單=1/bc2=5 全過;bc2 p1 四行齊全含被拆走的 PSA 03AM。

‧ 修改檔案:HBSTK\compat\prn_to_pdf.prg(+STATIC s_lLabelPitch/預掃/~I 錨點/AdvanceLine gate,備份 .bak_labelpitch_20260902);18:52 deploy_stk32.bat 發佈。

‧ 另釐清:「條碼出不來」兩份 PRN=列印時選到無條碼項的標籤格式(資料面),有條碼格式渲染正常。

v2026.09 2026-09-02

標籤信封

標籤跳頁/信封偏下回歸修正→已修正

技術說明：前次改動誤動到組合碼 nMax

詳細處理

‧ 詳見 PRNASK/doc/UpdateList.md 同時間條目(共用 compat\prn_to_pdf.prg)。標籤 6頁、信封 11頁正確;已發佈。

v2026.08 2026-08-31

列印報表

列印/預覽頁尾兩行重疊→已修正

技術說明：行距沒掃到縮放碼 ~Z

詳細處理

‧ 現象:對帳單頁尾兩行 `~x2Z2;`(垂直縮放2倍)在列印+預覽重疊擠在一起(客戶指 Z2 紅框處)。

‧ 根因:prn_to_pdf.prg 渲染字高有乘 `s_nVScale`(~Z),但算行距的 `PeekNextLineMaxT` 只掃 `~T` 字級、沒掃 `~Z` → 2倍高的字配1倍行距 → 重疊。標題也用 Z2 但後接空行有緩衝才沒露餡;頁尾連續兩行 Z2 才爆。

‧ 修法:PeekNextLineMaxT 補掃下一行 `~Z` 存模組 STATIC `s_nPeekVScale`;AdvanceLine 把行高乘上該 vscale(>1才乘)。呼叫點零改動。無 `~Z` 報表 vscale=1、乘1零影響。

‧ 驗證:silent PDF(batch.ini MODE=2)轉出 PDF→PyMuPDF 渲染 PNG 目視:頁尾兩行正常分行不重疊。

‧ 修改檔案:HBSTK\compat\prn_to_pdf.prg(BIG5 bytes-only,備份 .bak_vscale_20260901);共用引擎故 PrnAsk + Stk32 都重建。

v2026.08 2026-08-31

報表轉檔

轉 Excel 標頭掉第一個字→已修正

技術說明：正則 \S* 貪婪吃掉中文

詳細處理

‧ 現象:PrnAsk 轉 Excel,標頭第一個字被吃掉(「國內比價單」→「內比價單」、「報價單」→「價單」)。

‧ 真兇:prn2xlsx.py 移除控制碼的正則 `~[A-Za-z]\S*;?`,`\S*`(貪婪、任何非空白)在吃掉 `~W2;`(放大字碼)後,繼續吃掉緊貼的第一個中文字(中文也是非空白),到空格才停 → 移除了 `~W2;國`。字在轉 Excel「之前」就消失,不是儲存格切割造成的。

‧ 修法1(治本):`\S*` → `[!-~]*`(只吃 ASCII 可見字元,遇中文即停)。新範圍是舊的子集,只會少吃不會多吃,零副作用。

‧ 修法2(採納建議,美化):主標題(第一列)改整列跨所有欄合併 + 置中(A1:I1),落在整張表正中央;其餘表頭列(單號/日期/客戶名/頁次)維持左右分欄。

‧ 驗證:真實 PRN 實跑,A1=「國內比價單」5 字完整、合併 A1:I1、置中。

‧ 修改檔案:prn2xlsx.py(HBSTK\build 與 PRNASK\build 同步,備份 .bak_titlefix_20260831);py38 spec 重建 prn2xlsx.exe(Py3.8.10 32-bit + UCRT x86,Win7 相容),放 HBSTK\build + PRNASK\build。

‧ 部署:uploader 每次 rmtree 重建 pack 並從 HBSTK\build 抓 prn2xlsx.exe,故更新 HBSTK\build 那份即可;隨下批更新推送。

v2026.08 2026-08-31

畫面顯示

登入大寫鎖定狀態顯示錯誤→已修正

技術說明：遠端連線環境下大寫鎖定狀態抓不到、顯示錯誤

詳細處理

‧ 游標停字首:AskLoginBox 三處(開窗初始/預填帳號後/切換欄位)aPos 由字尾改 0,配合覆寫模式直接重打逐字蓋掉舊值。

‧ CapsLock 警示「失效」結案:程式正常(實體鍵盤/WebScreen 皆有效,WebScreen buildVK 有轉送 VK 0x14 會真切狀態);TeamViewer 只轉譯字元不同步鎖定鍵,客戶機 CapsLock 狀態沒變,wapi_GetKeyState 讀恆為關->警示不出現,屬遠端工具特性非 bug。驗證=客戶機實體鍵盤按 CapsLock 即出現。

‧ 修改檔案:source/RIGHTS.PRG。BUILD OK(22:48),截圖驗證通過。

v2026.08 2026-08-31

系統穩定

索引錯誤累積灌爆(0156)→已修正

技術說明：索引/壓縮時序衝突

詳細處理

問題：索引錯誤累積灌爆(0156)

根因：索引/壓縮時序衝突

處理方法：加獨占鎖+預檢+診斷強化。

v2026.08 2026-08-31

進銷存作業

交易刪除提醒視窗不顯示→已修正

技術說明：刪除確認視窗阻斷更新

詳細處理

問題：交易刪除提醒視窗不顯示

根因：刪除確認視窗阻斷更新

處理方法：改訊息隊列非同步提醒。

v2026.08 2026-08-30

系統維護

手動回報錯誤截圖 FTP 上傳逾時→已修正

技術說明：FTP 上傳阻塞

詳細處理

‧ 實測(2026-08-30 通過):STK32 端按 `Ctrl + 數字鍵盤 +` 觸發,agent ~1 秒內上傳 FTP,成功。

‧ B方案 Agent 端:主迴圈每秒讀本機 C:\StkAgent\S站號\errkick.flg,內容變了(STK32 有新錯誤)就強制立即掃描 error_pending 上傳,不等 ERR_SCAN_SEC(10 秒);平常只讀本機小檔,不狂掃 W:。

‧ 改動(stk_agent.prg,4 處):

1. 加 STATIC s_cErrKickLast(記上次旗標內容)。

2. RelayListenLoop 加 LOCAL cErrKick。

3. 主迴圈 idle recv timeout 2000ms→1000ms(每 1 秒轉一圈,旗標反應 ~1 秒)。

4. 錯誤掃描前插旗標檢查:內容變了就 nLastErrScan:=0 強制本輪立即掃描上傳。

‧ 關鍵:s_cStation(STATION_NAME,格式 Sxxx)= STK32 的 "S"+PadL(cTopWare,3,"0"),路徑對得上;旗標失效時 10 秒掃描為後備不漏送。

‧ 修改檔案:stk_agent.prg(備份 .bak_errkick_20260829);hbmk2 stk_agent.hbp -comp=bcc 建置 OK(1.22MB)。

v2026.08 2026-08-29

網頁遠端

安卓手機喚醒後遠端連線黑屏無法操作→已修正

技術說明：GPU 2D context 被系統回收仍沿用

詳細處理

‧ 現象(客戶,安卓手機):手機閒置→熄螢幕→點亮→回到連線就起不來。桌機不會(桌機不凍結 JS)。兩種畫面:①顯示「⚠️ 此站串流無法啟動」但沒重試鈕、無法重新整理(卡死)②重連後 FPS 30+ 卻一片黑、沒轉圈沒訊息(大部分,偶爾回得來)。

‧ 根因②(最常見,真兇):安卓走 WebCodecs;手機背景後 canvas 的 GPU 2D context 被系統回收(lost),回前景重連時 `startWebCodecs` 的 `if(!wcCv){...}` 沿用舊 canvas→`drawImage` 到失效 context 靜默失敗(不報錯)→畫面全黑,但 `wcFrames++` 照跑→FPS 30+ 假活。★visibilitychange 雖有移除 canvas,但走「凍結 watchdog / wcWs.onclose」的重連路徑沒移除→沿用失效 context。

‧ 修②:startWebCodecs 每次(重)連都重建 canvas(先 remove 舊的再 createElement 拿新 context),不再靠 `if(!wcCv)` 只建一次。根治「重連後 FPS 30+ 卻黑」。

‧ 根因①(我 v0828f 保險絲太激進):桌機重連 1~2 次就好碰不到 DEAD_LIMIT=6;手機喚醒後網路要重穩、重連較慢,連 6 次還沒好就被 `showStreamDead()` 判死停住,且死訊的重試鈕在手機沒顯示→卡死無法自救。

‧ 修①:死流保險絲改先自動 location.reload()(手機萬用解,勝過顯示死訊);用 `sessionStorage._stkDeadRl` 記上次重載時間,90 秒內只重載一次防迴圈;剛重載過還是不行=該站真的壞→才顯示死訊。

‧ 修改檔案:stk_webscreen.py(startWebCodecs canvas 重建、reconnectStream 死流分支改 reload-first、WS_VER→v0828g)。build+部署 `\\SERVER\SOCKET\StkWebScreen` 熱抽換。

‧ 心法:行動裝置「FPS/幀數正常卻黑屏」=顯示層(canvas GPU context lost),非串流問題→每次重連一律重建 canvas(別靠 if(!wcCv) 沿用);手機任何「連不上」的最終保險絲用 reload(F5 萬用解)而非停住顯示訊息。

v2026.08 2026-08-29

網頁遠端

遠端畫面無限重連死循環一片黑→已修正

技術說明：Agent 跑在非互動桌面 pusher 秒死 0KB

詳細處理

‧ 回報:WebScreen 重連常失敗、一片黑、狂重連死循環(切 APP/螢幕熄燈回來就死)。

‧ 診斷(重要,真兇不在 webscreen):client 修法(conn.settimeout/visibilitychange/wake/reload 保險絲)+relay keepalive 全在生效(整檔 REJECT=0)。死循環是撞上一台 pusher 給不出畫面的站:viewer 連上→START_STREAM→該站 pusher 秒死 0KB→10s viewer.settimeout 收不到幀→STOP→client 重連→無限(relay log 該站 pusher `0KB in 0s` 累積 1199 次)。真兇=站端 Agent 跑在非互動桌面(見 StkAgent UpdateList 2026-08-29 條 + Memory)。

‧ 本次 webscreen 端只做「保險絲」(治標,避免無限重連狂敲 relay 且誤導成 webscreen bug):`reconnectStream` 加計數 `_deadTries`,連續 `DEAD_LIMIT=6` 次重連之間都沒收到任何幀→`showStreamDead()` 停止自動重連,顯示「⚠️ 此站串流無法啟動…請重開/檢查該站電腦」+🔄重試鈕;收到正常幀(watchdog 有前進分支)即清 `_deadTries`/`_streamDead`;回前景(visibilitychange)重置給新機會。

‧ 修改檔案:stk_webscreen.py(`_streamDead/_deadTries/_gotFrame/DEAD_LIMIT`、`showStreamDead`、`reconnectStream` 計數、watchdog 有前進分支、visibilitychange 重置、WS_VER→v0828f)。build+部署 `\\SERVER\SOCKET\StkWebScreen` 熱抽換。

‧ 心法:重連死循環先看 relay log 該站 pusher 是不是 `0KB`——是就往站端查(非 webscreen);client 端該有「連 N 次無幀就停+顯示明確訊息」的保險絲,別讓壞站包裝成 webscreen 死循環。

v2026.08 2026-08-28

網頁遠端

虛擬鍵盤中英切換鈕失效→已修正

技術說明：Ctrl+Space 組合被 IME 吞

詳細處理

問題：虛擬鍵盤中英切換鈕失效

根因：Ctrl+Space 組合被 IME 吞

處理方法：改單鍵 Shift(注音內建切換)無修飾,Win7/10 均成功。

v2026.08 2026-08-28

系統穩定

進銷貨索引診斷錯誤→已修正

技術說明：並發開檔衝突

詳細處理

問題：進銷貨索引診斷錯誤

根因：並發開檔衝突

處理方法：索引/壓縮改獨占鎖,開檔用完即關。

v2026.08 2026-08-25

網頁遠端

iPad 按虛擬鍵盤時螢幕局部放大→已修正

技術說明：iOS Safari 雙擊智慧縮放誤觸

詳細處理

‧ 現象(客戶):iPad 上按虛擬鍵盤↑↓等按鈕,螢幕變成局部放很大;安卓平板/手機不會。

‧ 根因:iOS Safari 的「雙擊智慧縮放(double-tap smart zoom)」——快速連按同一顆按鈕被判定 double-tap→對該區域局部放大。Android 尊重 viewport user-scalable=no,iOS 無視。

‧ 解法:①CSS `html,body,button{touch-action:manipulation}`=禁 double-tap zoom,保留正常點擊/pan/自製雙指縮放(對 video 的 pinch 不受影響) ②iOS 專有 `gesturestart` preventDefault 補刀(擋頁面級縮放手勢)。

‧ 修改檔案:stk_webscreen.py(CSS 兩行+JS 一行、WS_VER→v0825a)。佈署 server .new。

v2026.08 2026-08-25

系統穩定

關機旗標殘留無法完全關閉→已修正

技術說明：關閉順序不當

詳細處理

問題：關機旗標殘留無法完全關閉

根因：關閉順序不當

處理方法：結束前先關資料庫再離開。

v2026.08 2026-08-25

系統穩定

索引卡住「使用中請稍後」根治→已修正

技術說明：被自己主機其他作業獨占

詳細處理

問題：索引卡住「使用中請稍後」根治

根因：被自己主機其他作業獨占

處理方法：加互斥鎖+自動清理殘留連線。

v2026.08 2026-08-25

進銷存作業

品名備註查詢無限迴圈→已修正

技術說明：迴圈條件用 dbSeek 缺陷

詳細處理

‧ 錯誤(FTP):0077 基念 BOSS 刪「品名片語」即炸 DBCMD/1001 Argument error: DBSEEK @ P113 DelPhrase:7076。

‧ 根因:NameNote/TypeNote 連動刪除迴圈 `DO WHILE xxx->(dbSeek(cPartsId))`——cPartsId 是從零件備註段抄來的殘留,此路徑未定義→dbSeek(NIL) 炸;cPartsId 恰有值的路徑則靜默刪不到。外層 IF 用 cCode 才是正確變數。

‧ 修:兩處(TypeNote/NameNote,僅活碼,跳過註解區同名舊碼)改 dbSeek(cCode)。BUILD OK。

‧ 連鎖:客戶端 NameNote.cdx 損壞=DelPhrase 開檔後半途炸掉未正常關檔所致;復原=刪壞 cdx 讓 EnsureCdx 自癒或跑全部索引。

‧ 心法:FTP 錯誤 stack 行號要「精確對行」,別用約略範圍猜段落(第一次誤標 TypeNote,實為 NameNote)。

v2026.08 2026-08-24

網頁遠端

斷線重連後之前的操作自動重新執行→已修正

技術說明：fetch keepalive 斷線期間排隊重連補送

詳細處理

‧ 現象(客戶):遠端桌面連到一半斷線,重連之後「之前的動作自己重新執行一次」。

‧ 根因:wsSend 的 HTTP 退路 fetch('/input',{keepalive:true})——keepalive 的語意=瀏覽器背景排隊、網路恢復後補送。斷線期間 WS 死掉,使用者的每個按鍵/點擊都進 keepalive 佇列,重連後瀏覽器一口氣補送→遠端把整段操作重放一次。

‧ 解法:斷線期間的輸入「不可排隊」——去掉 keepalive,改 AbortController 1.5s 逾時:斷網立即失敗直接丟棄,HUD 提示「連線中斷,操作未送出」(2 秒節流)。即時操作送不出去就該丟,重放比丟失危險。

‧ 修改檔案:stk_webscreen.py(wsSend、WS_VER→v0824a)。佈署 server .new。

v2026.08 2026-08-24

進銷存作業

交易刪除復原確認→已修正

技術說明：復原鍵邏輯

詳細處理

問題：交易刪除復原確認

根因：復原鍵邏輯

處理方法：改正確的還原流程。

v2026.08 2026-08-24

畫面顯示

單行插入變成打出重複字→已修正

技術說明：雙位元組截字錯誤

詳細處理

問題：單行插入變成打出重複字

根因：雙位元組截字錯誤

處理方法：改相容瀏覽引擎的插入邏輯。

v2026.08 2026-08-23

技術說明：經瀏覽器中介無法裝檔

詳細處理

‧ 根因總結(弄很久的原因):①使用者習慣「複製圖檔案」=CF_HDROP,先前只做點陣圖 CF_DIB→一直讀到檔名文字35字;②Ctrl+V keydown 被 preventDefault→瀏覽器不發 paste 事件;③copySmart 先注入 Ctrl+C 蓋掉使用者剛複製的內容;④注入 Ctrl+V 與大圖設剪貼簿的時序競賽。

‧ 終極架構:跨站不再經瀏覽器剪貼簿(它裝不了檔案)。Ctrl+C→鍵直送遠端 app 複製→700ms 後 /copysync 伺服器自動拉存來源站剪貼簿(file/img/text,存 CTRL.xclip[kmsn],5分鐘新鮮期);Ctrl+V→paste 事件先問 /pastesync→伺服器 SET_CLIPBOARD_ANY 到目標站→同一條 relay 通道接著送 REMOTE_INPUT Ctrl+V(agent 依序執行=順序保證,零猜延遲)→無伺服器內容才退回本機剪貼簿(圖/文字)。

‧ UI:⧉複製鈕=xclipPull(拉存;圖/文字順便寫回本機剪貼簿);📋貼上鈕=先 /pastesync 再本機。HUD 全程提示(已擷取檔案「x.jpg」/已跨站貼上檔案…)。

‧ 權限:檔案 kind 受 stk_agent.ini FILE_XFER 閘門(agent 端 GET/SET 都擋);圖/文字不受限。

‧ 修改檔案:stk_webscreen.py(xclipbuf/xclip、get_clipboard_any/paste_xclip、/copysync /pastesync、xclipPull、paste handler 重寫、按鈕改接、WS_VER v0823a);agent 見 StkAgent UpdateList 16:13。

‧ 佈署:WebScreen server .new 已丟;★Agent(16:13)待重推 S001~S004。

v2026.08 2026-08-21

網頁遠端

工具列容器整片蓋住遠端畫面點擊無效→已修正

技術說明：#bar z-index 蓋在畫面上

詳細處理

‧ 客訴:8443 連 [0007]S012,STK32 八個選單左4可點、右4點不到/lost focus;TeamViewer 正常、S011 正常。

‧ 排查旅程(逐層無罪化):DPI(96排除)→pusher殭屍/雙開(清掉一隻真殭屍,非主因)→幽靈螢幕(單螢排除)→webscreen monlist快取(正確)→agent注入(閉環 move+GetCursorPos 5/5全中)→前端map()(Playwright實算9點全對)→STK32命中(注入點擊右選單全開)→padMode觸控板模式(平板預設相對移動,切直接模式,次要因素)。

‧ ★真兇:工具列容器 #bar 整片(z-index 40)蓋在 video 上,Playwright elementFromPoint 8/8 tap 命中 DIV#bar;使用者工具列在右側=擋右緣。展開/收合狀態決定攔截範圍→時好時壞。

‧ 根治:#bar{pointer-events:none} 容器空白區穿透;button+四個下拉選單 auto;★.hide 時子元素顯式 none(子 auto 會蓋過父 none)。任何位置/狀態的工具列永不遮擋遠端點擊。

‧ 驗證:修正後 elementFromPoint 左/中/最右全命中 VIDEO#v;實機驗收 OK。

‧ 方法論:閉環注入(REMOTE_INPUT+GetCursorPos)量化注入精度;Playwright 模擬平板 evaluate map()/elementFromPoint 直接解剖前端;截圖+注入點擊驗證 STK32 行為;逐層無罪化收斂。

‧ 修改檔案:StkWebScreen/stk_webscreen.py(操控頁CSS;備份 .bak_barpassthru_20260821_0831);重編 Stk_WebScreen.exe(6,980,038) .new 部署 SERVER watchdog 已換版。

v2026.08 2026-08-18

技術說明：高解析度字高誤差

詳細處理

問題：直書 GDI 字型角度與浮點污染

根因：高解析度字高誤差

處理方法：精確計算字級與斜度。

v2026.08 2026-08-11

網頁遠端

切其他 APP 後回到遠端卡轉圈或一片黑→已修正

技術說明：後台凍結 JS 旗標卡住+pusher 沒重啟

詳細處理

‧ v0812c(conn timeout)不夠:客戶切其他APP不到一分鐘再切回,仍空轉(loading轉不停)或一片黑(無loading),必須返回站台頁才能用。兩個 client 端根因:

‧ 空轉根因(狀態機卡死):手機背景瀏覽器凍結 JS→期間 wcWs.onclose/凍結 watchdog 把 _reconnecting 設 true,但 setTimeout(start) 被凍結沒執行→旗標卡 true;回前景 reconnectStream 開頭 if(_reconnecting||_maint)return 直接被擋→永遠不重連。只有整頁重載(返回站台)才清狀態。修=visibilitychange 回前景先強制清 _reconnecting/_maint/_maintTimer/_mmsGuard 再 reconnectStream。

‧ 一片黑根因(pusher 沒重推):重連了但 viewer count 因時序非 first→webscreen 不重發 START_STREAM→pusher 沒推新流→連上卻收不到幀→canvas 停黑(不觸發 loading)。修=新增 /wake 端點強制 CTRL.start_stream(冪等重發,不依賴 count);client 回前景 fetch /wake→reconnectStream 內建 1.5s 延遲剛好等 pusher 重啟推流。

‧ 部署:Stk_WebScreen.exe(v0812e)+update_pack+\SERVER\SOCKET\STKWEBSCREEN\Stk_WebScreen.exe.new(watchdog swap)。

‧ 修改檔案:stk_webscreen.py(visibilitychange 強制清狀態+fetch /wake、server /wake route、WS_VER)

v2026.08 2026-08-11

網頁遠端

遠端閒置一兩分鐘後無法重連只能返回重進→已修正

技術說明：server 對卡住瀏覽器 sendall 無限阻塞堆滿殭屍連線

詳細處理

‧ 現象:客戶閒置一兩分鐘(手機鎖屏/背景)後,回來一直重新連線怎樣都連不上,只有「返回選站台重新進」才能恢復。

‧ 根因(server 端殭屍 viewer):client 背景/凍結時,server 對它 conn.sendall(送瀏覽器)因 TCP 送出緩衝塞滿而無限阻塞→_ws_stream 迴圈卡在 sendall 出不來→永遠不 release→殭屍 viewer 累積到 cap(MAX_VIEWERS_PER_STATION=8)→之後所有重連被 try_acquire REJECT(連不上);且殭屍讓 count>0→重連 acquire 非 first→不重發 START_STREAM,但 pusher 早被 release 的 STOP 停掉→就算連上也沒流。「返回重進」=關頁所有連線斷→count 歸 0→重進 first→START_STREAM 復活。

‧ 修:_ws_stream 對送瀏覽器的 conn 設 conn.settimeout(20)→卡住的殭屍 20s 自動清→count 歸正→下次 acquire=first→重發 START_STREAM 復活 pusher。(原本只有 viewer.settimeout(10) 收 relay 端逾時,送瀏覽器端無逾時=殭屍破口。)

‧ 部署:Stk_WebScreen.exe(v0812c)+update_pack/SOCKET/webscreen。

‧ 修改檔案:stk_webscreen.py(_ws_stream conn.settimeout、WS_VER)

v2026.08 2026-08-10

進銷存作業

詢價/報價彙總視窗按 Alt+F10 複製為新單完全沒反應 → 已修正

技術說明：複製動作被編輯狀態旗標誤擋

詳細處理

‧ 問題:INQUIRY/QUOT 訂單畫面在單號欄位按 `?` 叫出彙總查詢視窗後,按 Alt+F10 想複製該單為新單完全沒反應。詢價、報價兩個視窗皆然。

‧ 排查過程(三次翻案):先懷疑 Alt+F10 本體(QUOT 三個 Ask 框綁 CopyAskArray,INQUIRY 沒綁)→ 再懷疑 CHK_COPY 權限閘門(轉換版 DBFWIN.PRG:809 比 900 多加了 `MEMVAR->aPrgChk[CHK_COPY]`,而 QuotMain/InqMain 的 LCOPY 只有權限 01 才 T)→ 使用者提示查 C10(Clipper 只認前 10 碼、Harbour 認 63 碼,QuotMainWin=11 碼、CopyQuotInq=11 碼)。加無條件 WriteDebugLog 實測後真相大白。

‧ 根本原因(LOG 證實):LOG 顯示 `mode=4(DE_EXCEPT) pri=01 CHK_COPY=T copyNIL=N lEdit=F`。CASE 條件(權限)通過、bCopyBlock 有值(CopyQuotInq),真正卡住的是下一行 `IF DbfMWin->lEdit`——彙總查詢視窗在執行期 `LOC_SET=900\set` 的 DBFMWIN.DBF 裡 lEdit=F(唯讀查單),導致複製區段整段跳過。不是 CHK_COPY、也不是 C10。

‧ 關鍵踩坑:①先讀錯 SET 目錄(讀了 900\SET32 顯示 lEdit=T,誤導;執行期實際用 stk.ini 的 LOC_SET=900\set,那裡 lEdit=F)——查資料前務必先確認 stk.ini 的實際路徑。②C10 假設:雖 QuotMainWin/CopyQuotInq 都 >10 碼,但 PrgChk.DBF 的 CPRG 欄存的是完整名(未截斷)、彙總視窗本身能開(11 碼的 QuotMainWin 檢查有過),證明非 C10。③`IF DbfMWin->lEdit` 這層 900 版也有(第 537 行),非轉換 regression,而是複製功能被誤綁在 lEdit 底下。

‧ 解決方法:DBFWIN.PRG 第 809 行 CASE(K_ALT_F10)移除最外層 `IF DbfMWin->lEdit`,改為跟同檔 Alt+F9 列印一致、只看 `IF MEMVAR->bCopyBlock = NIL / ELSE Eval(bCopyBlock)`。複製為新單只需 copyblock,與能否編輯查詢視窗無關。影響範圍僅有設 copyblock 的 QuotMain/InqMain;ACTMAIN/DAYMAIN 的 copyblock 為空,拿掉 lEdit 後仍 bCopyBlock=NIL 無動作,不受影響。零改 DBF 資料。

‧ 修改檔案:source/DBFWIN.PRG(DbfWinEdit 的 DE_EXCEPT / K_ALT_F10 段)

v2026.08 2026-08-08

標籤信封

熱感標籤機 LOGO 印不出→已修正

技術說明：驅動二值化成全白

詳細處理

‧ 客戶熱感標籤機 LOGO 印不出,連環三個獨立 bug:

1. 熱感驅動把彩色/灰階圖二值化丟成全白:gdi_print_c.c GDIDRAWHBMP 偵測單色裝置(BITSPIXEL<=1或NUMCOLORS==2)自行以亮度閾值192二值化+COLORONCOLOR,並加 StretchDIBits 失敗備援 SetDIBitsToDevice。log 證實 mono=1 sdib=1000 生效。

2. PDF/WebView2 首張圖在建頁前被丟:DrawPdfImage s_page==NIL 先 NewPdfPage(昨天修)。

3. GDI 直印首張圖在建頁前被丟(同源但漏補):GdiDrawImg 開頭加 s_nPageNum==0 先 NewPdfPage 保護(今天修)。

‧ ★診斷關鍵:Debug_PrnAsk.txt 舊版行1529「DrawPdfImage - no page/doc」→圖丟→才 NEWPAGE pg=1;新版 pg=1 直接 DrawPdfImage OK/GDIIMG OK,no page/doc 歸零。C 層 gdi_print_dbg.log(免DEBUG開關,%TEMP%,512KB自限)每次 sdib=1000。

‧ ★大坑:build 完沒 deploy!W:\各站與 C:\STK\各站跑的是 01:57 舊版(缺 GDI guard)→客戶一直測到缺圖。教訓=改完必 build+deploy(RDS_MODE=1 席位讀 C:\STK\Sxxx 本機非 W:,兩處都要 copy)。

‧ 附加:fw_prnout.prg 兩預覽視窗標題加日期時間戳(WebView2 行1989/GDI 行2708,DToC(Date())+Time()),視窗每次列印重建=顯示本次列印時間,方便辨識版本/新舊列印。

‧ 修改檔案:gdi_print_c.c、prn_to_pdf.prg、fw_prnout.prg(HBSTK+PRNASK 共用);17:44 版已 deploy W:\S001-4 + C:\STK\S001-4;客戶端待跑 uploader(EXE群組)。

v2026.08 2026-08-07

畫面顯示

視窗最大化後移動選單/瀏覽出現散落灰黑雜訊塊 → 已修正

技術說明：畫面重繪的邊界填充以「髒區」當基準,局部重繪時把背景刷在畫面中央蓋掉內容

詳細處理

‧ 問題:STK32 最大化後移動選單/瀏覽出現散落灰黑塊雜訊。原以為(08-06)是27/32" 4K上採樣+間歇無法重現,實測推翻:與螢幕尺寸無關(1080p開發機穩定重現)、最小化非必要條件,真正觸發=最大化狀態+局部重繪

‧ 根因:gtwvt.c:3336 WM_PAINT 最大化margin填充段用 ps.rcPaint(髒區)當基準算邊界;整頁重繪(髒區=全client)剛好填在真實邊界故正常,但局部重繪時髒區是畫面中央小塊→把背景刷填在髒區的左右上下緣(位於畫面中央)→蓋掉內容=雜訊。非最大化margin=0→if(Margin>0)跳過故永遠正常

‧ 診斷關鍵:①1080p本機用ShowWindow+SendKeys自動化重現(截圖對照乾淨vs破損)②破損後強制整頁InvalidateRect完全恢復→證明cell度量正確、問題純在局部重繪路徑③TEST B(不最小化只max+move也破)隔離出最小化非必要

‧ 解法:改用client絕對座標算四條真實margin帶(左[0,ML)/右[內容右緣,client右)/上[0,MT)/下[內容下緣,client下)),各自與ps.rcPaint取IntersectRect只填交集;局部重繪沒碰真實margin→交集空→不填→不蓋內容。整頁重繪行為不變

‧ 修改檔案:gtwvt_patch/gtwvt.c(3336-3357);備份.bak_marginfill_20260807_1105;經build_StkGTWVT.bat重編合併lib+裝Harbour gtwvt.lib+重建Stk32(13:15,7634944);★共用lib故Dbx32同受惠

‧ 驗證:本機A/B實測,最大化+移動、及完整序列(最大化→最小化→還原→移動)修復後皆乾淨(fixed1/fixed2截圖)

v2026.08 2026-08-07

畫面顯示

視窗最小化再還原後右/下緣殘留紅框、灰條 → 已修正

技術說明：還原時最大化位置漂移使字型重算縮小

詳細處理

‧ 問題:最大化本身正常;但「最小化→還原」這段後,視窗右/下緣出現紅框+灰條後遺症(使用者回報)

‧ 根因(C層log實測):最大化時字型16x32放大到19x33剛好填滿1900x990(ML=MT=0乾淨);但min→restore後最大化尺寸漂移成1844x979(字型相依,無WM_GETMINMAXINFO固定),FitSize被迫把字型縮成18x32→content 1800x960塞不滿client→右44px/下19px殘留帶;舊碼只在bMaximized填margin、視窗化端露灰底(COLOR_BTNFACE)+app紅框

‧ 診斷手法:C碼加臨時geolog(fopen寫檔記wParam/client/zoom/font/margin每步),重編後SC_MAXIMIZE/MINIMIZE/RESTORE序列跑,讀log一刀看清尺寸漂移1900x990→1844x979

‧ 解法:margin殘留帶填充從「if(bMaximized)」改成「每條band依自身extent判斷」——左/上帶看Margin>0,右帶看client.right>contentR,下帶看client.bottom>contentB;有殘留就填bg、正常content==client時band為空零影響;各帶與ps.rcPaint取交集只填交集(承Bug①不蓋中央內容)。涵蓋最大化置中+視窗尺寸漂移兩種殘留,與zoom狀態無關

‧ 修改檔案:gtwvt_patch/gtwvt.c(WM_PAINT殘留帶填充block,3355起);build_StkGTWVT.bat重編合併lib(14:31);★共用lib Dbx32同受惠

‧ 驗證:本機max→min→restore後drifted-maximized(1844x979)端右緣0紅色像素、乾淨黑底,紅框消失;un-max端1600x960內容對齊乾淨

‧ 殘留設計債(未動):最大化尺寸font相依會漂移屬既有現象,殘留帶填充已讓視覺乾淨;若要根治漂移需加WM_GETMINMAXINFO釘死尺寸(風險較高,暫不動)

v2026.08 2026-08-06

遠端桌面

網頁遠端轉橫向時虛擬鍵盤跑到畫面外消失 → 已修正

技術說明：點一下就寫死直向座標

詳細處理

‧ 現象:直向鍵盤可用可移動,橫向時鍵盤不見

‧ 根因:_vkbDragStart 一碰「關閉/移動」鍵(即使只點一下)就立即寫 inline left/top(直向座標);轉橫向後直向座標超出矮螢幕→鍵盤跑畫面外

‧ 修正:①點一下不寫 inline,位移>5px確定拖曳才切定位寫座標 ②加 resize 監聽,轉向/尺寸變清掉 inline 讓 CSS(直向滿寬貼底/橫向半寬靠右)重新接管歸位

‧ 修改檔案:stk_webscreen.py(Stk_WebScreen.exe 23:40)

v2026.08 2026-08-06

遠端桌面

網頁遠端多螢幕切換卡住、RDP 同步死結 → 已修正

技術說明：串流中檔案被鎖無法換版

詳細處理

問題：網頁遠端多螢幕切換卡住、RDP 同步死結

根因：串流中檔案被鎖無法換版

處理方法：換版流程改為先停串流再抽換,免代理重啟。

v2026.08 2026-08-06

進銷存作業

F12 一覽表點選 F5/F6/F8(車種/品名/品牌)毫無反應 → 已修正

技術說明：滑鼠選取沒送出真實按鍵而是直接求值

詳細處理

‧ 問題:F12鍵盤一覽表點選 F5:車種/F6:品名/F8:品牌毫無反應;鍵盤方式選卻正常

‧ 根因(探針證實):bit6=OFF時 F1~F8 全綁通用 Window(),它靠 LastKey() 鍵碼字串查 MAINWIN.DBF;

滑鼠點選 PickList 後 LastKey()=1002(K_LBUTTONDOWN)→查 "1002" 無定義→靜默返回;鍵盤選時 LastKey 恰為該鍵碼故正常

‧ 解決:ShowHotKeys 選取後改 hb_SetLastKey(鍵碼)+hb_keyPut(鍵碼) 送出按鍵,與真按一致;

hb_SetLastKey 先覆寫滑鼠殘留,避免 20260723 QUOT 迴圈誤觸滑鼠移動舊案復發(原直接Eval設計因此而生,一併取代)

‧ 修改檔案:TLIB.PRG(ShowHotKeys);診斷探針已全數移除(P11/WINDOW/APPSETUP)

v2026.08 2026-08-06

資料安全

單筆金額過大(超過欄位上限)存檔當場中斷 → 已修正

技術說明：單價×數量×折數超過金額欄位上限

詳細處理

‧ 問題:S006進銷貨明細單價x數量x折數=32,715,000 超過 ACTSUB/DAYSUB NSUBAMOUNT 欄寬 N(10,2) 上限 9,999,999.99,DBFCDX/1021 當場中斷(舊Clipper僅寫成星號續跑,亦是壞資料)

‧ 解決:BUYSELL.PRG 加 STATIC FUNCTION SubAmtOver 統一檢查,四站點防護:

1. 1101 新增明細:超限警告並 LOOP 退回重輸

2. 1362 修改明細:防護放 UpdateStock 之前(庫存不異動),還原畫面退回

3. 1771 重算迴圈:警告並跳過該筆(保留原值,自帶 dbSkip 防死迴圈)

4. 5022 SellOrder批次轉單:警告並金額歸零寫入,提示事後修正

‧ 修改檔案:BUYSELL.PRG(備份 .bak_subamtguard_20260806_*)

v2026.08 2026-08-06

系統穩定

啟用「按會計日期統計」的站台開單當機 → 已修正

技術說明：會計日期為空值傳入年度統計

詳細處理

‧ 問題:0155 開單(BUYSELL:1645)當機 BASE/1113 Argument error: MONTH;.stack 新機制第一戰直接給出 YEARS.PRG:240 / BUYSELL.PRG:1645

‧ 根因:該站啟用 Flag8-Bit4 按會計日期統計,aHead[ACCDATE]=NIL 傳入 YearIOUpdate → Month(NIL) 崩潰;同檔 Cus/Sup/ParYearUpdate 三支先前都補過 ValType(dActDate)!="D" 防護,唯獨 YearIOUpdate 漏掉(同段 1643/1644 收同樣 NIL 都靜默略過)

‧ 解決:YearIOUpdate 開頭補與其他三支相同防護(非 D 型別或空 → RETURN .F. 略過統計)

‧ 修改檔案:source/YEARS.PRG(YearIOUpdate 開頭 +4 行);備份 .bak_yeario_guard_20260806_1420;build OK(Stk32.exe 08-06 14:04)

‧ 註:上游 aHead[ACCDATE] 為何 NIL(會計日期未帶)屬單據流程另題,待觀察;.stack 上傳機制(昨 22:15 版)已在客戶端驗證運作

v2026.08 2026-08-06

畫面顯示

技術說明：取消回傳 0 造成陣列從第 0 筆越界

詳細處理

‧ 問題:三益行 S004 於「網路印表機切換」按 ESC 取消 → 當機 BASE/1132 Bound error: array access(FTP 錯誤回報,ARGS=A:ARR[3]|N:0)

‧ 根因:TLIB.PRG SwitchWinPrn 第 4421 行 nChoice:=VerticalMenu(aPrinter,nChoice),ESC 取消時 VerticalMenu 回 0,下一行 aRecNo[nChoice]=aRecNo[0] 陣列從 1 起算 → 索引 0 越界

‧ 解決:VerticalMenu 之後加 IF nChoice < 1 防呆,視為取消 → 關 Spool/還原按鍵顏色工作區後 RETURN .F.,不切換印表機

‧ 踩坑:同檔有三處同模式 —— SwitchWinPrn(4421,當機處)、SwitchPrinter(1087,相同潛在 bug 一併修)、SetWinPrn(4471,VerticalMenu 已註解且 nChoice 恆 >=1 不需動;勿盲改)

‧ 修改檔案:source/TLIB.PRG(SwitchWinPrn、SwitchPrinter 各加 ESC 防呆);備份 TLIB.PRG.bak_prnswitch_esc_20260805_1140

‧ build:Stk32 BUILD OK

v2026.08 2026-08-05

效能速度

詢價單匯入比舊版慢很多(29 秒 vs 9 秒) → 已修正

技術說明：進度提示以「傳值」方式反覆複製整份資料

詳細處理

‧ 問題:客戶反映詢價單 Alt+R 外部匯入新版 29 秒、Clipper 舊版 9 秒(刪除表身也稍慢但已改善)。

‧ 根因:DOMPUR 匯入迴圈 15 處 ProcessBox(msg, lInitial) 用「傳值」——ProcessBox 內部把

lInitial 改 .F. 傳不回呼叫端,每筆都走初始化分支=清畫面+畫整框,原節流(更新分支)從未生效;

Clipper 畫框近乎免費所以 9 秒,GTWVT 同步重繪就是 3 倍稅。

‧ 彎路(已還原):先在 ProcessBox 內加 lBoxUp 降級想一處治全部 → 誤傷重建索引

(連續多個「合法新框」1 秒內被誤判重複而不畫框=畫面空白);教訓=共用底層勿加情境猜測,

病灶在呼叫點就修呼叫點。

‧ 最終解:ProcessBox 完全還原;DOMPUR 15 處呼叫改 @lInitial 傳參考(同 IndexDbf 既有正確

寫法):第一筆畫框、之後走原節流,重建索引不受影響。

‧ 驗證:重建索引畫面正常(已確認);匯入速度待客戶實測。刪除表身打點(FORARR/INQUIRY t0~t7)

保留待測。

‧ 附:ProcessBoxThrottle 本就 stk.ini 可調(LoadIni->GETE,預設0.1,開發機1.0),

INI_EDITOR+模板×3 先前備份功能時已同步,無需再補。

‧ 修改檔案:TLIB.PRG(還原)、DOMPUR.PRG(@lInitial×15)。備份 DOMPUR.PRG.bak_atinit_20260805。

v2026.08 2026-08-05

系統穩定

重建索引時發生無法復原錯誤(9001) → 已修正

技術說明：清索引與資料庫啟用的時序問題

詳細處理

問題：重建索引時發生無法復原錯誤(9001)

根因：清索引與資料庫啟用的時序問題

處理方法：加清索引防護與啟用等待。

v2026.08 2026-08-04

系統穩定

列印引擎註解全檔亂碼修復→已修正

技術說明：約 420 行 BIG5 破損

詳細處理

接續前次:prn_to_pdf.prg 尚有「合法 BIG5 但含問號破洞」與次常用字區的殘留註解行,本次全部清完。

盤點:改進偵測(原只抓「問號緊鄰 CJK」,漏了「CJK 全毀成純問號」型;又誤報合法含 ~[?n]/?100;H;W 控制碼語法的行)→ 精準規則:問號緊鄰 CJK 才算殘片型,註解且 8 個以上問號且無 CJK 殘存才算全毀型。真實受損約 420 行。

方法:依檔案順序分五段,每段先讀函式本體(禁止憑空猜),再逐行以殘片規律加程式邏輯重寫:

‧ Section1(檔頭到 PrnToPdf 主函式):模組說明、紙張決定優先序、狀態重置

‧ Section2(ParseAndRender 到 NewPdfPage):控制碼分派表、圖片、QR、大括號

‧ Section3(FlushText 到 GetFontPt):字寬縮放公式、造字圖 PUA、GDI 渲染、對齊

‧ Section4(GetFontPt 到 ConvertImageToPng):紙張選項、印表機查詢、日期時間格式、中文數字、色盤

‧ Section5(DrawQRCode 到 RenderUnicodeGlyph):QR 游標、圖片貼上、字型載入、SumatraPDF 送印

順手校正:註解與程式不符處(如 DspMatchPaper 容差、GetCellW 公式)以程式為準重寫。

驗證:全檔 BIG5 解碼 PASS、殘留 0 行;PrnAsk 加 Stk32 REBUILD OK。

踩坑:全毀型無高位元組殘留需另加規則;控制碼語法問號誤報須以「是否緊鄰 CJK」區分;重度毀損行連 ASCII 錨點都沒改用殘存 token 當錨;U+3007 非 BIG5 中文零改用「零」。

修改檔案:prn_to_pdf.prg(備份 .bak_fixcmt_20260804）。

v2026.08 2026-08-04

查詢統計

彙總視窗查無符合資料時當機 → 已修正

技術說明：出口無條件還原索引順序但工作區已關閉

詳細處理

問題:P5141(國內訂單未出貨明細)彙總視窗按 F9 查詢,查無符合資料時崩潰 DBCMD/2001 Workarea not in use: ORDSETFOCUS;追蹤 ORDSETFOCUS→DBSETORDER→TABLE(348)→P5141(120)。

根因:Table() 入口(TABLE.PRG:30/32)存 cLastAlias=Alias()、nLastOrder=IndexOrd();出口 347 只在 cLastAlias 仍開啟時選回,348 卻無條件 dbSetOrder(nLastOrder)。F9Refresh5141(P5141:598-607)按 F9 會先 dbCloseArea 關掉舊 cReptAlias 暫存工作區,再 ReptForm 重建;若查無資料回傳空,無任何工作區被選取即回 Table→出口 348 在空工作區執行 dbSetOrder 而崩潰。

解法:347-348 改為只有 cLastAlias 仍開啟、確實 dbSelectArea 選回後,才 dbSetOrder 還原索引順序;已關閉則整段略過(呼叫端 P5141:122-134 自行善後)。正常情況行為與原本完全相同。

性質:既有 bug(非本日分割線改修所致,客戶跑 08.03 版即有);TABLE.PRG 為全畫面共用,一併保護其他有「F9/重新產生會關閉重開工作區」的畫面。

修改檔案:TABLE.PRG:347-348(備份 .bak_ordfocus_20260804）。REBUILD stk32 OK。

v2026.08 2026-08-04

列印報表

含 QR 的標籤在工作站列印很慢、列印瞬間畫面閃爍嚴重 → 已修正

技術說明：QR 走外部 Java 冷啟動+網路

詳細處理

問題1(工作站印 QR 慢,主機快):QRCode()(PRINT.PRG)每產一個 QR=寫 ini→MagicQR.bat→java -jar MagicQR.JAR(JVM 冷啟 1~3 秒)產 PNG→~[G] 貼圖;工作站 JAR/暫存 PNG 走網路更慢。P0 標籤每張 QRCode+FitTypeQRCode=每張 1~2 次 Java。

修:PrnAsk 引擎本有原生 ~[QR;資料;x;y;尺寸] 向量 QR(hbzebra,經查 hb_zebra_create_qrcode 存在,QrDrawZebra 成功路徑零子程序)。QRCode() 開頭判 PRNMETHOD=1 直接回 ~[QR] 控制碼(毫秒級,零Java/PNG/網路);PRNMETHOD=0(DosPntGo)維持舊路。FitTypeQRCode/CompanyQRCode 經由 QRCode() 自動受益。座標同 ~[G] mil 座標系,尺寸取 Min(寬,高)。

問題2(列印瞬間 Stk32 畫面閃動嚴重,直到 PrnAsk 出現才停)——三層元兇逐層剝:

‧ L1 OpenSpool 每次 RunCMD(start /B DelSpTmp.bat)=cmd 黑窗+SAVE/RESTORE SCREEN 全屏重繪;bat 為 DOS/HyperDOS 遺物(del *.ini *.png+rescan,del *.ini 有誤刪風險)→改程式內只刪自家 QR 暫存 Tmp#####.png/.ini。

‧ L2 PrnLabel「標籤列印中」MessageBox 寫在 FOR 迴圈內=每張重畫一次視窗(log 實證 18 張=18 次完整重畫)→移出迴圈畫一次。

‧ L3(★真主犯)FitTypeQRCode 的 SAVE SCREEN/cls/RESTORE SCREEN 裸奔在正常路徑=每張標籤整螢幕清空再還原一輪(18 張=黑屏閃 18 輪)→三者全部條件化到 lDebug(本來就只為除錯輸出服務),正常列印零畫面操作。使用者實測:不閃了。

診斷心法:①「主機快工作站慢」=網路 IO 特徵,先找外部程序/檔案往返;②「閃爍到某視窗出現才停」=閃在該視窗前的階段,用 Debug log 時間戳 gap 分析定位(MSGBOX×18 重畫節奏 60ms 直接現形);③修了還閃=元兇不只一層,逐層剝(bat→MessageBox→cls);④debug 用畫面操作(SAVE/cls/RESTORE)絕不可裸奔在正常路徑。

踩坑:行尾空格錨(RESTORE SCREEN FROM cBuffer+空格)再現——bytes 錨必先 repr 驗證。待辦:CompanyQRCode 同款 SAVE/RESTORE 裸奔結構(本次未動,無 lDebug 參數需看實作)。

修改檔案:PRINT.PRG(QRCode+OpenSpool+FitTypeQRCode)、LABEL.PRG(PrnLabel);備份 .bak_qrnative/.bak_openspool/.bak_lblmsgbox_20260804。

v2026.07 2026-07-30

列印報表

前方單張橫印轉 90 度→已修正

技術說明：橫印頁向與邊界不對齊

詳細處理

訴求(客戶):點陣印表機大多用 A4 單張走前方進紙夾(前方無滾輪),橫印報表雖少但仍會有,需要橫印時內容真的轉90度(跟噴墨一樣);後方連續紙則維持原本寬版不轉。

踩坑/現象:①噴墨橫印靠驅動 DMORIENT_LANDSCAPE 旋轉,但點陣驅動大多不吃這旗標→設了等於沒設。②原本用 DC_MAXEXTENT(印表機物理最大寬)判要不要旋轉,對「同時具備寬行連續紙能力」的點陣機失準(回報寬版能力,A4 橫印被當塞得下→不轉)。③寬版拖曳紙(9×5.5)橫印與 A4 橫印送到 C 端都是寬>高,分不出誰要轉。

解決方法:不靠驅動,改為自繪旋轉——在每頁 StartPage 後對印表機 DC 下 90 度世界座標轉換(SetWorldTransform + GM_ADVANCED),實體紙開成直式、版面維持橫式;點陣噴墨通吃。用列印對話框新增「進紙方式(後方連續/前方單張)」讓使用者明確宣告,只有「前方單張+橫印+直式紙」才旋轉(寬版 9×5.5 因 nOrigW>nOrigH 永不觸發)。再加「橫印旋轉方向(順時針/逆時針)」群組,C 端 ApplyRotate90 依 s_bRotCW 分流(CW:(x,y)→(HORZRES-y,x);CCW:(x,y)→(y,VERTRES-x))。兩選項存 System.ini(PRN_FEEDMODE/PRN_ROTDIR)記住上次。

技術:SetWorldTransform 世界座標旋轉;GdiOpenPrinter 加第4參 lSelfRot(直式紙不設 landscape)、第5參 lRotCW;GdiPrintPrn 加 lRotate90/lRotCW 傳遞;旗標為假時行為 100% 不變(向後相容,共用引擎零風險)。

修改檔案:PRNASK/build/printdlg.rc(進紙方式+旋轉方向 radio、按鈕下移)、PRNASK/source/fw_prnout.prg(nFeed/nRotDir/radio/lRotate90/FwReadIniFeed/FwSaveIniFeed/FwReadIniRotDir/FwSaveIniRotDir)、HBSTK/compat/prn_to_pdf.prg(GdiPrintPrn 旋轉分支)、HBSTK/c_code/gdi_print_c.c(s_bSelfRotate/s_bRotCW/ApplyRotate90/GDIOPENPRINTER 第4,5參)。BUILD OK,PrnAsk+Stk32 皆重編,客戶測試 OK。

---

v2026.07 2026-07-30

資料安全

技術說明：自動縮放係數把黑體縮小抵銷了字高加成、比例字寬校準造成溢格

詳細處理

‧ 訴求:客戶要「換任何 CJK 字型都免逐一手調字高」。

‧ 自動版:新增 C 函式 GdiMeasureInkH(gdi_print_c.c,GetGlyphOutlineW GGO_METRICS gmBlackBoxY 量真實墨高),CJKPtScale 改量目前字型 vs MingLiU 的「口」墨高比值自動正規化。

‧ 踩坑1(黑體被縮小):黑體 JhengHei「口」墨高 201>MingLiU 181→自動係數 0.90 clamp 到 0.95→黑體被 ×0.95 縮小,抵銷 SYSTEM.INI GDI_FONT_ADJ=5 字高加成(客戶回報「黑體字高沒套用了」)。

‧ 解:改混合式——已手調字型固定係數(MingLiU=1.0/標楷=1.30/黑體=1.08 恢復;黑體辨識做全 JHENGHEI/MSJH/MHEI/正黑/黑體),只有未知字型才自動量測且下限改 1.0 只放大不縮小。

‧ 中英等高:同字型(SAME)時 CJK 走 CJKPtScale 但 ASCII 走 s_nGdiAsciiScale 不同步→英文比中文矮;新增 AsciiSameHScale()(量口/0 墨高比)讓英文字高拉齊中文。

‧ 踩坑2(黑體英文左右重疊):比例字型寬度統一校到「0」時 W/M 寬字母 advance 超過一格→溢格重疊(數字全等寬故無事)。

‧ 解:逐字取 Min(該字撐滿一格, "0"撐滿一格),寬字壓進格不溢、細字/數字不變形;連帶修 GdiCalibFontW 快取 key 漏 cSample 的隱藏 bug(補 +"|"+cSample)。

‧ 修改檔案:HBSTK/c_code/gdi_print_c.c(+GdiMeasureInkH)、HBSTK/compat/prn_to_pdf.prg(CJKPtScale 混合式、AsciiSameHScale、ASCII 逐字 min、快取 key)。重編 PrnAsk+Stk32,實測預覽 OK。

v2026.07 2026-07-27

系統穩定

查詢視窗編輯「別名欄位」存檔時崩潰 → 已修正

技術說明：別名欄位的巨集展開語法錯誤

詳細處理

‧ 問題:客戶 S002 於國內採購頭檔按 ?(63) 開查詢視窗 DbfWin("DomPurM"),編輯欄位按 Enter 寫回時崩潰 BASE/1449 Syntax error op=& @ DBFWINEDIT(655)。

‧ 根因:DBFWIN.PRG:655 `REPLACE &(MEMVAR->acField[..]) WITH x`,當視窗欄位定義(DBFSWIN.DBF cField)是別名欄位(如 Supplier->cName)時,Harbour 前置處理展開成 `_FIELD->Supplier->cName` 非法運算式。Clipper 逐句 runtime 編譯合法,屬語言轉換回歸。

‧ 解決方法:欄位字串含 "->" 改用巨集指定 `&cFieldMacro := xCurrentField`,否則維持原 REPLACE;新增 LOCAL cFieldMacro。

‧ 修改檔案:source/DBFWIN.PRG(384 LOCAL、655 分流)。build OK,未派版(使用者自行上傳 FTP)。

v2026.07 2026-07-25

列印報表

列印時多出一張空白尾頁 → 已修正

技術說明：尾端換頁碼後面已無內容卻仍開新頁

詳細處理

訴求:P413 Alt+F10重印(及一併列印)印出後多一張全空白頁。

根因(log實錘):.TST尾端有PrnTrustBill最後EJECT送的Chr(12) FF;渲染器prn_to_pdf.prg的FF換頁只判斷s_lPageDirty,擋得住空白頁遇FF但擋不住「有內容的頁尾端遇FF、後面卻沒內容」→開空白尾頁。換行溢出那條路本有PeekLineHasContent防護,FF這條漏了。

解法:prn_to_pdf.prg FF換頁條件改 IF s_lPageDirty .AND. PeekLineHasContent(cText,nPos+1)—FF後還有內容才換頁,尾端多餘FF不開空白頁,中間分頁不受影響。共用渲染器故rebuild PrnAsk+update+Stk32。

修改檔案:compat\prn_to_pdf.prg。

v2026.07 2026-07-24

系統穩定

廠商帳款報表按 F10 編輯原始單據時崩潰 → 已修正

技術說明：該類記錄沒有可編輯的原始單

詳細處理

問題(客戶0007吉霖):在廠商帳款報表視窗(F1廠商→SupAccWin→SupXXXWin→RptWin)對一筆記錄按 F10(MainApplyKey:805→EditRptWin=編輯原始單據),崩潰 BASE/1102 Argument error UPPER。

根因:EditRptWin(RPTWIN.PRG:2332) DO CASE 只處理 nOrderType 四種(SELL/SELL_RETURN/BUY/BUY_RETURN),無 OTHERWISE。廠商帳款記錄的 nOrderType 非這四種→cCurPrg 維持 NIL→line 2400 PrgChk(Upper(cCurPrg))=Upper(NIL)崩潰。既有 bug(與近期改動無關)。

解決方法:ENDCASE 後、PrgChk 前加 `IF cCurPrg == NIL ; RETURN lReturn(.F.) ; ENDIF`——非四種可編輯類型的記錄無原始單可編輯,F10 直接優雅返回不動作,不崩潰。不改四種類型原行為。

診斷心法:完整堆疊逐層還原操作路徑(APPSETUP:48 F1進入點→SupAccWin廠商帳款→SupXXXWin→RptWin→MainApplyKey:807 F10鍵→EditRptWin);UPPER(0)=Upper收到NIL/0,回推哪個引數;DO CASE 無 OTHERWISE 是常見 NIL 洩漏源。

修改檔案:RPTWIN.PRG(EditRptWin);BUILD OK 零警告。客戶端需派版。

v2026.07 2026-07-24

系統穩定

報表暫存檔衝突(同機重入或開兩個程式)造成共享違規 → 已修正

技術說明：暫存檔名固定會相撞

詳細處理

延續上一則 P5141:盤點全部 ReptForm,同機雙開/重入撞固定暫存檔的風險一併處理。

涵蓋(21支報表 + 兩類暫存檔):

‧ ReptForm 暫存檔 cReptFile:P5141/P5142/P6151/P6152/P6261/P6262/P627(固定字面名 DomOrdR1等)、P241/P246/P25/P27/P351/P355/P36/P373/P415/P424/P46/P47/REPORT(ProcName="REPTFORM")、P221。

‧ Extract 產出暫存檔 cOutputFile(ProcName 命名,例 P25.dbf):19支;__dbCopy(COPY TO)建檔、多為共用(.F.)開啟。

‧ P221 特殊:DayRept 兩個暫存檔(DayRept1/DayRept2)+ ReptForm。

做法(兩種,依有無字面比對):

‧ 有字面比對(A類 DomOrdR1等、及所有 cReptFile 保持 alias):檔名加 STK_GETPID() 唯一化,alias 用新 helper ReptUse()=USE...ALIAS 保持原值。ReptUse drop-in 替代 NetUse(cReptFile,.T.,0,{})。

‧ 無字面比對(cOutputFile、P221 DayRept):alias+檔名一起加 PID(NetUse 自動衍生相符 alias,開檔行不改)。

效果:同機開多個 stk32.exe、各報表暫存檔各用各的(如 P25_<PID>.dbf、DomOrdR1_<PID>.dbf),不再互撞 DOS Error 32;都能正常跑。

驗證:全數 BUILD OK 零警告;殘留掃描 0(無未加PID的固定暫存檔、NetUse(cReptFile)全換 ReptUse);alias 上限 HB_SYMBOL_NAME_LEN=63,PID尾碼安全。

新增:`source/DBF.PRG` FUNCTION ReptUse(cFile,cAlias)。修改:21支報表 PRG + DBF.PRG。

v2026.07 2026-07-24

畫面顯示

單一視窗用滑鼠拖拉/縮放調整後,重開又跑掉不記住 → 已修正

技術說明：單窗被誤判為「需跳過幾何存檔」

詳細處理

訴求/現象:Alt+O開啟的內銷客戶訂單未出貨明細表(P5141→InitialWin+Table,暫存表DomOrdR1/格式Z),滑鼠可拖拉調大小,但關閉再開位置/大小不記憶;80×25與100×30皆不持久化。

根因:非DPI也非RWMainBox。INITIAL.PRG:293 cargo[MODE]=IF(Empty(nMode),WINDOW_FORM_MODE,nMode),而全表MAINFORM的NMODE只有0/1沒有2→NMODE=0單窗因Empty(0)=.T.全被判成WINDOW_FORM_MODE(2)。2026-07-13 TABLE.PRG:327 SaveTblLayout(oBrowse,cargo[MODE]==WINDOW_FORM_MODE)本意只想跳過WinForm雙窗主檔避免nCenter塌陷,卻誤殺812個NMODE=0單窗→幾何Part1整段跳過→滑鼠DoWinMove改的座標永不寫回(TblWinReframe只改記憶體不寫DBF)。

解法:改用「真實分隔線」區分。SaveTblLayout內把lHoriz/lSplit提前計算,判斷式由 !(lSkipGeom==.T.) 改為 !(lSkipGeom==.T. .AND. lSplit)→只有「呼叫端要跳過且記錄真有分隔線」才跳過。單窗(lSplit=.F.)恢復幾何持久化,WinForm/DAYWIN雙窗(lSplit=.T.)維持保護,NMODE=1不受影響(純加法零迴歸)。

踩坑:①誤以為是DPI(RWMainBox已有MainFormDpiFilter,DomOrdR1 DPI=80/100兩筆齊全非主因);②cargo[MODE]來源是Empty(0)預設而非DBF真值,一般單窗與WinForm雙窗NMODE無法區分,只能靠nCenter是否為真分隔;③DAYWIN/WinForm自有移動迴圈(WinSaveGeomSet)不走此路故倖免。

驗證:拖拉後DomOrdR1(DPI=100/pri01)幾何由1/0/24/79/24變1/0/28/99/28,實測記憶成功。

修改檔案:source\TABLE.PRG(SaveTblLayout:lHoriz/lSplit提前計算+IF條件加 .AND. lSplit);備份TABLE.PRG.bak_savegeom_split_20260724_2115。

v2026.07 2026-07-23

站內通訊

指揮台錯誤詳情視窗打不進去導致整個軟體凍死→已修正

技術說明：隱形 modal 鎖住事件迴圈

詳細處理

‧ 問題:FTP 錯誤回報逐筆檢視後 Commander+清單視窗全死當。前兩彈(截圖背景化/送出佇列/freeze watchdog)都沒中——本次 py-spy + EnumWindows 活體採證:process 從未重啟、freeze_stacks.log 不存在=GUI 心跳沒停過,實際是「vis=0 但 enabled=1 的隱形 modal 對話框」鎖住整個 App(主視窗 enabled=0),事件迴圈活著所以舊 watchdog 抓不到;後被 ESC/焦點切換自解。

‧ 解法:`_hb_tick`(每秒,QTimer 在 modal exec_ 巢狀迴圈中仍會跳)加 `_modal_guard()` 三招:①activeModalWidget 不可見→第 1 秒只觀察(防誤救正在關閉的視窗),第 2~4 秒 show/raise/activateWindow 救回,仍失敗→reject() 強制解鎖;②modal 可見但被壓在自家視窗後(前景視窗屬本 process)→提頂;③activePopupWidget 不可見(popup 抓取殘留)→close。每次介入寫 EXE 同目錄 `modal_guard.log` 留證。

‧ 源頭防護:`_open_detail` 改 exec_ 前先 show+raise+activateWindow。

‧ 驗證:py_compile OK;PyInstaller 重打包 v2026-07-23 11:43 啟動正常;正常操作 guard 零誤發(無 modal_guard.log)。

‧ 備份:stk_commander_qt.py.bak_modalguard_20260723_1200。

‧ 診斷標準流程更新:死當時若 freeze_stacks.log 無新紀錄→非執行緒卡死→改查 modal_guard.log;兩者都空再用 py-spy dump(裝在 Python312-32,dump 子 process 非 bootloader)+EnumWindows 看隱形視窗。

v2026.07 2026-07-23

列印報表

橫印全套修正(預覽+列印)→已修正

技術說明：預覽與列印設定不同步

詳細處理

訴求:WebView2 與 GDI 兩個預覽介面點「橫印」後,預覽不變、送印表機仍直印。

四個接連的坑與修法:

1. WebView2 預覽點橫印畫面不動 → psOK() 原本只做 CSS 縮放(rescalePaper),不重產 PDF;改送 pagesetup 由 FwPageSetup 用對調後的寬高重跑 FwPrnToPdf 重建 PDF+Navigate。

2. 列印仍直印(尺寸被換回) → FwPageSetup 沒設 lLand,重建 HTML 的 CUR_LAND=false,列印對話框 initPrdlg 正規化把橫向尺寸換回直向;改 lLand:=(nWcm>nHcm)。

3. 內容照直向排 → GDI 內容排版走 GetPaperPt 用 s_nCustomW/H(PRN 直向),UI 覆寫只設了實體紙張 s_nUiW/H;GdiPrintPrn 加:UI 覆寫時同步 s_nCustomW/H:=s_nUiW/H。

4. A4 噴墨機印出仍直印 → GDI 直印從未實作橫向,要求 29.7cm 寬紙被 A4 機裁掉;C 端 GdiOpenPrinter 加:查 DeviceCapabilities 實體最大寬度,超過(A4 塞不下寬紙)則改 A4 直向紙 + dmOrientation=DMORIENT_LANDSCAPE 讓驅動旋轉;寬台車點陣機維持自訂寬紙。

GDI 預覽橫向:GdiPreviewPrn 加 nUiWcm/nUiHcm 覆寫參數(記憶體 DC 無實體限制,直接設 s_nCustomW/H);FwGdiPrvPageSetup 把原生對話框選的橫向尺寸傳入。

修改檔案:fw_prnout.prg、prn_to_pdf.prg(共用引擎,UI 覆寫存在才生效,一般列印零影響)、gdi_print_c.c。

踩坑:prn_to_pdf.prg 有既存亂碼註解(779 處,非本次);gdi_print_c.c 是 LF 換行;s_nOrigW/H 只賦值未讀取(無縮放依賴,改 s_nCustomW/H 安全)。

v2026.07 2026-07-23

畫面顯示

表身翻頁(PgUp/PgDn)失控一直捲不停 → 已修正

技術說明：鍵盤緩衝累積得比畫面渲染快

詳細處理

現象:比價單等8000-9000筆,按住PGDN約5秒放開後仍自己翻到最後一筆才停;客戶要求放開即停。

根因:鍵盤緩衝backlog累積(鍵進得比ShowBody渲染快)。兩idiom:Shape A(DO WHILE .T.+InKey()!=K_PGDN inline PageDown)、Shape 1(DO WHILE InKey()=nLastKey+hb_keyPut(nLastKey)再注入+KeyPageUpDown,hb_keyPut每圈再注入→永不停最嚴重)。

4次迭代:①Shape1 hb_keyPut→hb_keyClear=INQUIRY完美②Shape A每頁hb_keyClear=不失控但變慢一頁一頁刷(InKey零等待慢渲染後抓不到還在按)③加InKey(0.05)=快但放開殘留5-6頁④對調順序仍5-6頁→順序非主因。

真因:hb_keyClear只清Harbour緩衝不清Windows訊息佇列;InKey()零等待=完整抽乾佇列(INQUIRY靠此一次清光→即停),InKey(0.05)帶逾時=一次只抽一個、清不掉佇列殘留→漏5-6頁。謎底就在InKey參數差異。

最終解:Shape A=hb_keyClear()+DO WHILE InKey()!=0(徹底抽乾佇列殘留)+IF InKey(0.05)!=K_PGDN(等全新鍵判斷仍按住)→放開即停0殘留。Shape 1=hb_keyPut→hb_keyClear。

檔案:Shape A(DOMCMP/DOMORD/FORCMP/DOMSCH/STOCK)、Shape 1(BUYSELL/DOMARR/DOMPUR/ENQUIRY/FORARR/FORPUR/INQUIRY/QUOT)共13檔;重編Stk32(21:09)。心法見PDF。

---

v2026.07 2026-07-23

進銷存作業

一覽表用滑鼠點選後光棒亂跳、還多送一個 Enter 誤入修改 → 已修正

技術說明：滑鼠「放開」事件處理不當

詳細處理

問題:報價製單表身,按 F12 或點抬頭叫出「鍵盤按鍵一覽表」(PickList),滑鼠點選項目(如 Alt+F3 倉庫視窗)後:①光棒從原列跳到滑鼠所在列;②離開該項目後系統多送一個 ENTER,若表身停在「修改」就誤入修改模式。★關鍵線索(使用者提供):點抬頭進入會多 ENTER、用 F12 進入不會。

兩個獨立根因與修法:

1. 光棒亂跳:PickList 以滑鼠點選項目後 LastKey() 停在 K_LBUTTONDOWN;ShowHotKeys 原用 hb_keyPut 把熱鍵排佇列(還沒執行),控制權先回表身迴圈,QUOT.PRG:698 檢查 LastKey()==K_LBUTTONDOWN(殘留值)把光棒移到 MRow()。修:ShowHotKeys 對有 SetKey 的熱鍵改「就地 Eval 執行」,項目立即跑、其讀鍵更新 LastKey(),回表身時不再誤判(導覽鍵 PgDn/ESC 無 SetKey 仍走佇列)。

2. 多送 ENTER:點抬頭是點在 TopMessage 的 persist 熱區({||ShowHotKeys()});HitTest 執行完 action 後 RETURN NIL,MsReadKey 誤判「沒點到區域」→ 把原始 K_LBUTTONDOWN 傳下去,離開後殘留按下被表身/GET 誤判多送 ENTER。F12 是鍵盤無此點擊故不會。修:HitTest 執行 action 時設 lHitAction 旗標,MsReadKey 據此 LOOP 吃掉點擊,不再把 raw DOWN 傳下去。

踩坑(大量試錯):★吃掉 K_LBUTTONUP 會讓滑鼠按鍵狀態沒「放開」→ 同位置狂噴 ENTER 洪水+項目不執行(在 ShowHotKeys/PickList 消耗 UP 都失敗);UP 在 GETSYS/BottomMenu 其實無 CASE 本來就無害不是元兇;真兇是「觸發用的那個點擊」殘留的 DOWN;診斷靠逐層加 log(GetApplyKey/BottomMenu/QUOT:698/StockWin)沿事件流回溯;mouse_handler.prg 有既存 UTF-8 損壞註解 bytes 比對要避開。

修改檔案:`source/TLIB.PRG`(ShowHotKeys 就地執行)、`compat/mouse_handler.prg`(HitTest lHitAction + MsReadKey 消耗);Stk32 CLEAN BUILD OK。

v2026.07 2026-07-23

系統穩定

網路瞬斷時連環報錯 → 已修正

技術說明：共享磁碟瞬斷造成讀取失敗連鎖

詳細處理

問題:客戶端(0007)07-23 09:19~09:22 W:\S001 共享磁碟 SMB 瞬斷,DBF 讀取連環噴 DBFCDX/1010(DOS 2/59/64),之後欄位變數解析不到再連鎖 BASE/1003(CTYPE/CBRAND/CMAINALIAS/CCHNAME),公司名稱都被污染成造字,一分鐘內十多筆錯誤雪崩。

解決方法:

‧ DefError() 開頭新增網路瞬斷自動重試:DBF 系列 RDD + canRetry + DOS 2/53/59/64/121 時,靜默等 1 秒 RETURN .T. 重試(最多 5 次,逾 30 秒視為新事件重計),重試期間不截圖/不回報;全部失敗才走原錯誤視窗。

‧ 順修既存 bug:s_lInError 重入旗標在 4 個提早 RETURN 路徑(除零/DATAWIDTH/網路開檔/APPEND LOCK)沒清掉,任一觸發後 DefError 永久變 no-op、後續錯誤全被吞。

踩坑:Seconds() 跨午夜歸零,重試間隔判斷要 Abs()。

修改檔案:`source/ERRORSYS.PRG`(備份 .bak_netretry_20260723_1130)

v2026.07 2026-07-22

畫面顯示

新機重灌後打勾符號、熱鍵框變亂碼 → 已修正

技術說明：造字第三層寫死依賴未安裝的字型

詳細處理

‧ 現象:客戶0007 S012(今天重灌)進畫面√勾勾/Alt+H/ESC/截圖圖示全變亂碼粗黑字;S001~S011(老機)正常,同一支exe。

‧ 診斷(遠端agent EXEC+抓debug log全程實測):兩站FontDirect/USRFONT檔MD5全同、AddFontResourceExW成功、無GPO封鎖;差別=S012無「華康楷書W5A」。log證實正常站走「HuaKang FOUND→direct render」、S012走「HuaKang NOT found→UDAFONT引擎」。

‧ 根因:所謂「不依賴華康」是假的——造字三層只有前兩層不依賴,第三層fallback DrawDynUnicodeGlyph(usrfont_render.c:277)寫死「華康楷書W5A」。字不在USRFONT.24M的86glyph→落到第2層CaptureGlyphAlpha(CreateFontW按名找FR_PRIVATE字型,新機/網路路徑有GDI quirk找不到)→再落到第3層寫死華康→無華康被Windows換DFKai→造字PUA空→底層Big5原碼透出=亂碼。老機因裝了華康,第3層剛好撐住。

‧ 修法(讓UDAFONT真正不依賴華康):①usrfont_render.c DrawDynUnicodeGlyph字型華康→USRFONT-STK;②usrfont_api.c USRFONT_LOADUDAFONT加AddFontMemResourceEx從記憶體註冊私有字型(根治FR_PRIVATE按名找不到的GDI quirk,新機/網路路徑可靠解析)。

‧ 實證:USRFONT.TTF內部名=USRFONT-STK涵蓋E000-EE1A共3611glyph;PIL直測√(EC59)/所有KY_熱鍵在USRFONT-STK全實心;standalone GDI測AddFontMemResourceEx+CreateFontW(USRFONT-STK)→face=[USRFONT-STK]非替代、gi有效、實心渲染OK。

‧ 建置:usrfont C在合併gtwvt.lib內→重編usrfont_c.obj+tlib替換模組(注意lib內模組名usrfont_hbmk,-usrfont_hbmk +usrfont_c.obj避免符號重複)+重建Stk32。本機(有華康)無回歸。

‧ 備份:usrfont_render.c/api.c/cache.c .bak_nohuakang_20260722_2338;gtwvt.lib.bak_nohuakang_*。

‧ ★部署:新Stk32.exe要派送到S012(及未來重灌機都免裝華康);待客戶端實測√/熱鍵框恢復。

‧ 後續(可選):HuaKang機仍走direct-render路徑用華康;可統一全改USRFONT-STK消除華康依賴,但會動到11台正常站,暫不做。

紀錄(UpdateList)

> 主程式;最新在上。

v2026.07 2026-07-21

站內通訊

下載錯誤截圖時整個指揮台凍死→已修正

技術說明：主執行緒同步 FTP 下載卡 60s

詳細處理

問題：下載錯誤截圖時整個指揮台凍死

根因：主執行緒同步 FTP 下載卡 60s

處理方法：改背景執行緒下載,pyqtSignal 回主緒更新。

v2026.07 2026-07-21

列印報表

印表機字型設定讀不到 → 已修正

技術說明：設定值含特殊字元被誤判成區段、或檔案被舊控制碼截斷

詳細處理

現象:工作站列印字型/GDI_FONT_ADJ 調了無效;主機S001正常、工作站都怪;同版exe、讀同一檔清乾淨仍失敗。查很久。

真兇:System.ini 的 PNTGO_CMD_PRINT/PREVIEW 值含 [file.prn]/[printer],hb_iniRead 誤判成 [區段] 標頭(test_ini dump 出憑空的 [FILE.PRN...] 假section)→ 排其後的 GDI_FONT_ADJ 掉進假section不在MAIN→hIni["MAIN"]["GDI_FONT_ADJ"]找不到用預設0。S001靠PNTGO_CMD排在GDI鍵後面才正常=純key順序運氣。另一個共犯是0x1A(Ctrl-Z)截斷[Font]。

破案手法:①加 WriteDebugLog(cIni) path log 印實讀檔全路徑→證實讀對檔卻讀0;②test_ini.prg 把檔餵hb_iniRead dump所有section→假section現形。

根治:IniReadSafe(prn_to_pdf.prg)hb_iniRead前逐行淨化=剝0x1A + 只有[開頭的行當section其餘行移除[];取代3處hb_iniRead;PrnAsk+Stk32重編。INI_Editor載入也剝0x1A阻止散播。實測GDI_FONT_ADJ由0變5。

修改檔案:HBSTK/compat/prn_to_pdf.prg(.bak_brkfix/.bak_0x1a/.bak_pathlog)、ini_editor.py。詳細偵錯報告見 PRNASK/doc/PrnAsk字型讀取懸案_System.ini陷阱_20260722.pdf。

---

v2026.07 2026-07-21

站內通訊

技術說明：W: 網路路徑重複逾時累積死當

詳細處理

‧ 客戶症狀(0007 S007/S008):要列印時啟動 PrnAsk 一直繞圈死當;P77 與 PrnAsk 印表機顯示不同步。別站有同樣外網印表機卻正常。

‧ 診斷(遠端 agent EXEC 唯讀查):PrnAsk.exe/Stk32.exe 三台同版本(排除版本);死當站印表機達 18 台。追鏈:PrnMappedList(fw_prnout.prg:256預覽/:3002 GDI列印對話框)對「每台印表機」呼叫 PrnAliasGet→PrnAliasRead→hb_FileExists+hb_MemoRead("W:\prn_alias.ini") 無快取→18台=讀 W: 19次(1 OPTIONS+18每台)。

‧ 根因:W:\prn_alias.ini 路徑寫死(prn_alias.prg:11,三邊共用);S007/S008 的 W: 慢/stale(疑昨日 S001 net session /delete 讓 W: 變 stale)→每次 SMB 逾時 ×19 累積→繞圈死當。別站 W: 快故 19 次瞬間完成正常。不同步同源:PrnAsk 讀 W: 逾時失敗→別名讀不到顯示原名,P77(W:正常)顯示別名→不一致。

‧ 修法:prn_alias.prg PrnAliasRead() 加 process 內 STATIC 快取(s_lCached/s_cCache)。PRNASK 端此檔「只讀不寫」故快取 100% 安全;19 次讀取→1 次,即使 W: 慢也只卡一次(秒級)不死當。

‧ 影響範圍:僅 PRNASK(STK32 不連結 prn_alias.prg,P77 有獨立實作+會寫別名故不加快取);只需 deploy PrnAsk.exe,Stk32 不用重編。備份 prn_alias.prg.bak_cache_20260720_1443。

‧ 環境面待辦:S007/S008 的 W: 為何 stale(重掛 W: 或重開機);根本可考慮別名檔改本機快取/加逾時。

‧ 待驗:deploy 新 PrnAsk 到 S007/S008→列印不再死當、印表機顯示與 P77 一致。

v2026.07 2026-07-20

列印報表

預覽部分中文字被壓半寬→已修正

技術說明：字型寬度表錯誤 126 字被讀成半寬

詳細處理

‧ 現象:預覽中「桃園市/正廠/公司訂/(左前)」的市/正/公/左等字被壓成半寬,鄰字正常。

‧ 診斷:解剖預覽 PDF 內容流→正/廠寫法完全相同(同F1/9.6pt/97Tz)→排除引擎;抽出 CID 字型 /W 陣列→CID 668-694/696-699/814-907/7716 共 126 個被標 500 半寬;ETen-B5-H 對照:公=686/左=824/市=825/正=845 全中,司=801/右=779 不在→與畫面 100% 吻合。

‧ 根因:libharu 2.3.0RC2 HPDF_UseCNTFonts 內建 MingLiU 字型定義的 /W 資料誤植(126 個 Big5 常用字:公左市正五分本未母民生用田白目立交先光...),pdf.js/PDFium 依 /W 把字形壓半。

‧ 解法:prn_to_pdf.prg 新增 FixCidWidths(),HPDF_SaveToFile 後把 /CIDFontType0 物件內的 /W 陣列以「等長空白」覆蓋(byte 數不變→xref 免重算,只掃字型物件至 endobj→不會誤傷壓縮流),檢視器 fallback /DW 1000 全形→126 字一次全治非逐字修。

‧ 安全依據:引擎每字絕對座標定位(每字一組 BT/Td/Tj),寬度表不影響排版,只影響檢視器字形壓縮。

‧ 驗證:新 PrnAsk 批次轉 PDF→/W 已中和(/DW 1000 保留)、trailer/xref 完好、內容流可解壓、Debug log「FixCidWidths neutralized /W x1」。

‧ 修改檔案:HBSTK\compat\prn_to_pdf.prg(+FixCidWidths+存檔後呼叫);重編 PrnAsk+Stk32。備份 prn_to_pdf.prg.bak_cidwidth_20260720_1224。

v2026.07 2026-07-20

資料安全

詢價單/訂單存檔筆數過大時崩潰 → 已修正

技術說明：單身筆數快取欄位溢位

詳細處理

‧ 問題：客戶端（25844T易有限公司）詢價單編輯存檔時崩潰 `DBFCDX/1021 Data width error: NSUBCOUNT`，追蹤 INQUIRY(1600)。

‧ 根因：INQMAIN.DBF 的 NSUBCOUNT 為 N(4,0)（上限 9999），單身筆數 nTotalLine 出現 >=10000（或負值）異常值 → REPLACE 撐爆欄位崩潰。本機 21 筆資料全部健康、無法重現，屬客戶端資料/邏輯異常。

‧ 解法：新增共用防護函式 FitSubCount(cAlias,nVal)（BUYSELL.PRG，接於 CountRecord 之後）：依 NSUBCOUNT 欄位實際寬度（FieldLen）動態算上限，放不下或負值就回傳 0。因 nSubCount 只是單身筆數快取（讀取時若 Empty 會自動 CountRecord 重算），回傳 0 即自我修復回正確值、永不崩潰。

‧ 診斷保全：新增 SubCountLogAppend()，異常時無條件寫入 build/SubCountAnomaly.log（不受 DEBUG 等級限制），記 alias/原始值/呼叫位置，供客戶端捕捉真正異常值。

‧ 修改檔案：BUYSELL.PRG（新增 2 函式）、INQUIRY.PRG（11 個 nSubCount 寫入點 1111/1317/1387/1449/1469/1497/1599/1904/2289/2625/3448 全包 FitSubCount）。

‧ 踩坑：FieldLen 動態推導可同時涵蓋 N(4,0) 與 N(3,0) 模組；hb_MemoWrit 2 參數會覆寫，append 須先 hb_MemoRead 再串接。

‧ 後續：QUOT/ACT/DAY 為 N(3,0)（上限僅 999）更脆弱、DOM/FOR/ENQ 系列同有寫入點，可日後套同一 FitSubCount。

v2026.07 2026-07-20

系統穩定

主檔查詢熱鍵在等待中重入時當機 → 已修正

技術說明：授信等待中被重入、當時工作區為空

詳細處理

‧ 現象:客戶(吉霖0007)報價轉銷貨→授信檢查「超過信用額度」MessageBox 時按 ? 鍵→BASE/1065 Argument error: &;trace 頂端 (b)QuotMainWin→ChkCredit。

‧ 根因:? 鍵(Asc=63)由 OrderWhen SetKey(63) 綁 QuotMainWin(開主檔瀏覽窗)。在授信 MessageBox 等待中被重入觸發,此時 MEMVAR->cMainAlias 為空,QuotMainWin 的 dbSetRelation(...,cMainAlias+"->cId") 關聯字串被 & 巨集編譯成 &("->cId")→非法運算式→BASE/1065。

‧ 解法:在 5 個共用此模式的主檔窗函式(InqMainWin/QuotMainWin/AdjustMainWin/DayMainWin/ActMainWin)開頭加守衛:cMainAlias 為空或工作區未開(Select==0)即 RETURN .T. 不進 dbSetRelation。正常情境行為完全不變,只擋錯誤重入。

‧ 踩坑:客戶build行號與現行source對不齊(較舊/PPO),靠函式名+&+由ChkCredit等待重入三點鎖定;守衛用//註解(可安全縮排)非*號;.OR.短路先擋Empty再Select避免Select("")。

‧ 修改檔案:source/BUYSELL.PRG(5處守衛);備份 .bak_mainwin_guard_20260720_0930。Build OK,Stk32 已啟動。

v2026.07 2026-07-06

遠端桌面

遠端操控遲鈍延遲高→已修正

技術說明：TCP Nagle+編碼管線深

詳細處理

‧ 訴求: 手機與 8C16T 桌機遙控都遲鈍→瓶頸在鏈路延遲不在客戶端算力

‧ ①TCP_NODELAY 全鏈路: 原本零處設定——webscreen(relay_connect 控制連線+Handler.setup 全部 HTTP/WS client)、relay(_set_keepalive 共用點+9530/串流 accept+web proxy)、pusher(串流 socket);滑鼠鍵盤小封包不再被 Nagle+delayed-ACK 每跳疊 40~200ms

‧ ②QSV 編碼 -async_depth 1: ffmpeg h264_qsv 預設 4=編碼管線積 4 張影格(10fps≈400ms);互動遙控設 1

‧ ③mpegts.js 追延遲窗 1.2/0.3→0.8/0.2 + enableWorker(demux 移出主執行緒,弱裝置受益)

‧ ④預設 fps 10→15、管理 UI 增 20 選項;★運行中的 streamcfg.json 蓋過程式預設,要在管理頁把 fps 實際切到 15/20 才生效

‧ 重建: Stk_WebScreen.exe、Relay/dist/relay_server.exe、StkAgent/tools/dist/pusher.exe;session_pusher 不含串流免改

‧ 部署: 跑 stk_uploader(webscreen/relay/agent 三群組)→relay 靠 A/B 槽 watchdog 換版、agent pusher 隨 agent 群組派發;瀏覽器端重新整理頁面即拿到新播放器參數

‧ 驗證: 操控頁 HUD 的 lat/fps 對照(改前常態 0.4~1.2s;目標 <0.4s)

‧ 修改檔案: StkWebScreen/stk_webscreen.py, Relay/relay_server.py, StkAgent/tools/agent_pusher.py

# SOCKET 更新記錄（跨元件層級）

> 本檔記錄涉及 多個 SOCKET 元件（Relay / StkAgent / StkCommander / StkWebScreen）的共用工具與流程。

> 單一元件的細項各自記在該元件的 `doc\UpdateList.md`。

---

v2026.06 2026-06-25

資料更新

重整索引時檔案使用中會當機→已修正

技術說明：獨占開檔被別台占用拋錯

詳細處理

問題：重整索引時檔案使用中會當機

根因：獨占開檔被別台占用拋錯

處理方法：改迴圈等待+提示檔名+使用者退出後自動繼續。

v2026.06 2026-06-25

資料更新

版面檔合併效能不佳→已修正

技術說明：盲掃 840 次網路探測+重複重開

詳細處理

‧ 訴求：使用者問「版面合併一筆一筆比對應該很耗時」。

‧ 釐清誤解：`MergeSetOne` 本來就是 hash 比對（先把客戶現有唯一鍵丟進 hash，新版逐筆做 hash 查詢），單檔是 O(客戶+新版) 不是 O(客戶×新版)；且版面檔很小，比對 CPU 幾乎不花時間。真正瓶頸是網路 I/O 次數。

‧ A. 站台只列舉一次（最大效益）：原 `DoMergeSet` 對 `S/A/B/C/D/E/P × 01-20` = 140 路徑逐一 `hb_DirExists`，× 6 別名 = 840 次網路探測（多數站台不存在）。新增 `StationDirsForMerge()` 用一次 `Directory(cBase+"*.*","D")` 列出實際存在的站台目錄（樣式 `[SABCDEP]0\d\d`）→ 取代盲掃。同 INDEX/PACK 的盲掃網路坑。

‧ B. setnew 每別名只讀一次進記憶體：原本新版檔對每一站都重開重掃。新增 `LoadDbfToMem()` 把新版檔讀成 `aNewFld+aNewRows` 一次，各站只開客戶檔比對 append → 省掉 N 次重開重掃網路版本檔。`MergeSetOne` 簽名改為 `(cCust, aKey, aNewFld, aNewRows, cLog)`。

‧ C. 小優化：唯一鍵/欄位對應 index 預先算（免迴圈內重複 `FieldPos`）；append 全部做完迴圈外一次 `dbCommit`（取代逐筆 flush）；append 欄位對應找不到記 0 略過（原版 `FieldPos=0→FieldGet(0)` 會出錯，順手修掉）。

‧ 效益：原「840 次網路探測 + N×6 次重掃 setnew」→「1 次目錄列舉 + 每站開一次客戶檔」，網路呼叫降一個數量級。

‧ 驗證：BIG5 bytes-only 改寫（中文註解 `.encode('big5')`，不混 \\x）；重編 UpdJson32.exe（引擎已變）；headless harness 重跑端到端全 PASS（S001 +3 / S002 +5、客戶改的欄位保留、master 未被覆蓋、MARKER/readme 解出）；站台列舉版正確找到 S001/S002。

‧ 修改檔案：`source\UpdateByJson.PRG`（DoMergeSet 改寫 + 新增 StationDirsForMerge/LoadDbfToMem + MergeSetOne 改寫），重編 `build\UpdJson32.exe` 並部署 dist。備份 `UpdateByJson.PRG.bak_mergeperf_20260625_235620`。

v2026.06 2026-06-25

資料更新

別名欄位遺漏→已修正

技術說明：欄序不同導致欄位錯位

詳細處理

‧ 訴求：PrgChk.DBF 有 CALIAS 欄（區分同程式不同別名，如 DbfWin 配 Addr/DomSchM/DomOrdM），三處（GUI/引擎/轉換器）都漏了。

‧ GUI：prgchk 分頁加「別名」欄（程式→別名→Order→類別→說明→旗標）。

‧ 引擎 DoPrgChk：補設 `cAlias`；索引鍵修正——有別名用完整鍵 `cLevel+PadR(cPrg,15)+PadR(cAlias,8)`，無別名用前綴鍵 `cLevel+cPrg`。

‧ 轉換器：抽 cAlias。重大 bug：Pattern B 原假設 aTmp 固定欄序 → 各區塊欄序其實不同 → 欄位錯位（出現 alias=1046/order=中文鬼值）。改成解析各區塊 ADD 分支 REPLACE 得 `aTmp[nTmp][N]→欄位` 對應再抽值。

‧ 盤查：源碼 ADD 分支僅 3 處非空 cAlias（Addr/DomSchM/DomOrdM），全數到位；其餘 alias 欄位本為空或屬「只更新不新增」區塊（無 AddRecord）→ 非遺漏。

‧ JSON 重生成：75 milestones / 269 struct / 20 copy / 57 prgchk(含 3 alias) / 9 field / 11 remind。

v2026.06 2026-06-18

遠端桌面

遠端桌面啟用 RDP 接管後鍵盤無反應→已修正

技術說明：overlay 搶焦點

詳細處理

‧ 功能:工具列「🖥 RDP 接管」checkbox + session 下拉(多帳號);三處 START_STREAM 抽 `_stream_params()` 統一帶 rdp/rdpsid/rw/rh;`RDP_SESSIONS` 列 session 由 `_on_update` 以 KMSN:STATION 路由到對應視窗。Agent 零修改(早已支援 rdp/rdpsid/rw/rh)。

‧ 鍵盤踩坑:啟用 RDP 後鍵盤打不進 → 實測 console 也不通、滑鼠兩模式正常 → 非 RDP 問題。overlay 是 `Qt.Tool` 視窗拿不到鍵盤焦點。★誤加 `overlay.activateWindow()` → overlay 變 active → `_sync_overlay`「容器 win.isActiveWindow() 才顯示 overlay」不成立 → overlay 被藏 → 連滑鼠都死(回歸,已還原)。

‧ 解法:滑鼠/鍵盤焦點分離 — 滑鼠走 overlay(hit-test 不需啟用);鍵盤走 view 本身(`setFocusPolicy(StrongFocus)` + `keyPressEvent/keyReleaseEvent` 轉送),點畫面 `self.setFocus()`(聚焦 view、不啟用 overlay)。

‧ 修改檔案:`python/stk_commander_qt.py`;`doc/Commander_RDP接管_20260618.pdf`。rebuild Stk_Commander.exe(14:42,python -m PyInstaller→python/dist/stk_commander.exe)。

v2026.06 2026-06-15

連線穩定

中繼伺服器單點故障造成所有客戶連不上→已修正

技術說明：唯一中繼掛機全崩

詳細處理

‧ 訴求：你公司唯一一台 RELAY_SERVER 掛了，所有客戶連不上。要備援自動頂替（客戶端只有 Agent、在 NAT 後面，無法當公開 relay → 備援必須放在「公開可達處」）。

‧ 架構（使用者定案）：公司第二台機器當備援 + active/standby（非選舉）。

‧ 新檔（都在 Relay\）：`relay_standby.py`/`.exe`(6.4MB,daemon：每20s ping 主 relay，主死連續 ACTIVATE_AFTER 次→啟本機備援 relay、主活連續 DEACTIVATE_AFTER 次→停；遲滯防抖；單例綁 127.0.0.1:9555)、`relay_standby.ini`(PRIMARY_HOST/PORT/LOCAL_DIR/間隔/遲滯)、`install_relay_standby.bat`(備援機掛排程 STK_Relay_Standby onstart + 5分watch，並移除本機正常 STK_Relay_Server/Watchdog 以免 relay 24h 常開破壞 standby)。

‧ 收斂：任何時刻只有一台 relay 服務 → Agent/Commander 不會 split（落在主/備互看不到）。主復活→備援自停→客戶重連回主，零手動。

‧ ★同辦公室 9530 只能 port-forward 一台 → 備援要第二對外埠：路由器轉 `9531→備援:9530`；客戶端 failover 清單支援 `host:port`。

‧ `relay_client.prg` `RelayTryConnect()`：清單項含 `:` 就拆出埠覆寫 nPort（一處改，agent 主機/ALT/ALT2/127.0.0.1 全路徑受惠）。

‧ `stk_commander.py` `relay_connect()`：host/host_alt 帶 `:port` 同樣覆寫。

‧ 設定（待部署）：Agent `RELAY_HOST_ALT2=asiaware.tplinkdns.com:9531`、Commander `RELAY_HOST_ALT=asiaware.tplinkdns.com:9531`（同公開 DDNS + 第二外埠→備援）。relay_standby.ini 的 PRIMARY_HOST 建議填主 relay 區網 IP（同辦公室最可靠）。

‧ 重編：`relay_standby.exe`、`Stk_Agent.exe`(23:40)、`stk_commander.exe`(23:40)。

‧ 限制：① 同辦公室備援只防「主機當機」，停電/斷網兩台一起死（使用者已知）。② 串流(pusher→9531 stream)failover 未涵蓋，只保命令通道(Commander↔Agent)。③ 備援機是公司端設施，手動部署不走 stk_updater；客戶端 ini 的 ALT2 要靠 per-key ini sync 推送。

v2026.06 2026-06-12

遠端桌面

遠端桌面座標點擊左右對不上越右差越大→已修正

技術說明：瀏覽器尺規與虛擬桌面寬不同(多螢幕)

詳細處理

‧ 現象：takeover console 桌面時鼠標位置左右對不上；特性＝「點最左邊差很小，越往右差越大」。

‧ 判讀：左準右越差＝純水平『比例(scale)』錯，非位移(offset)。瀏覽器用網頁烤死的 RW 當尺規送座標(0..RW)，但 console 實際擷取的虛擬桌面寬 CX(多螢幕/超寬，gdigrab -i desktop 抓整個虛擬桌面)≠ RW → 用 1920 尺規點 3840 桌面，越右放大越多。RDP 帳號剛好 CX=RW 所以準。

‧ 修法（自我校正，3 檔，不動 C、不破壞現有 RDP）：pusher inject() 把座標從 RW/RH 尺規換算到實際 SM_CX/CYVIRTUALSCREEN(78/79)：x=round(x*CX/RW)、y=round(y*CY/RH)；RW=0 不換算(舊版相容)，RDP 帳號 CX==RW 換算後不變。

‧ agent_pusher.py：main 讀 a[11]=rw / a[12]=rh（模組級 INJ_RW/INJ_RH），inject() 套用比例。

‧ stk_agent.prg：START_STREAM 的 RDP 分支 pusher 命令在 bitrate 後多帶 rw rh（bytes-only 補丁，BIG5 註解；錨點＝bitrate+StrTran 尾巴唯一）。

‧ stk_webscreen.py：start_stream 多帶 params rw,rh = station_screen(target)（與網頁烤入 RW/RH 同源）。

‧ Build：pusher.exe(01:58)、Stk_Agent.exe(01:59)、Stk_WebScreen.exe(01:59)。備份 stk_agent.prg.bak_rwrh_20260612_0140。

‧ 部署：pusher+Agent→各站(stk_uploader→stk_updater)，WebScreen→橋接機。

v2026.06 2026-06-10

系統維護

代理更新後被結束卻沒重啟導致連不上→已修正

技術說明：install 兩版不同步、silent 用已刪 vbs

詳細處理

問題：代理更新後被結束卻沒重啟導致連不上

根因：install 兩版不同步、silent 用已刪 vbs

處理方法：補齊自啟/保活檔到派送清單。

v2026.06 2026-06-09

連線穩定

中繼跑久 FPS 逐漸下降卡頓→已修正

技術說明：不乾淨斷線的殭屍連線卡 recv 洩漏

詳細處理

‧ Relay 現象:WEB CLIENT FPS 重啟後快、跑一段時間又慢、重啟又好。

‧ 根因(relay_server.py):viewer 偵測斷線只靠 `recv()`,但 socket 沒逾時、沒 TCP keepalive → 不乾淨斷線(網路抖動/NAT/橋接重連無 FIN)時 `recv` 永遠卡住 → 該 viewer 永留 `stream_streams`;`cleanup_thread` 只清控制連線、不清 stream viewer → 殭屍 viewer 越積越多,pusher 每幀 `for v in viewers: feed()` 餵殭屍 + 卡死的 sender thread → GIL/CPU 競爭 → FPS 隨時間下降;重啟全清才好。

‧ 修法:① viewer/pusher socket 開 `SO_KEEPALIVE`+Windows `SIO_KEEPALIVE_VALS`(閒置30s起偵測,~分鐘判死)→ 卡住的 recv 解除→自動移除;② `cleanup_thread` 主動 prune `alive==False` 的 viewer(雙保險,並 log 清掉幾個);③ helper `_set_keepalive()`。

‧ 觸控雙擊(stk_webscreen.py):手機/平板要 double-click 開桌面程式,但觸控原本只送單擊、兩次點觸像素會飄 Windows 不認。加 double-tap 偵測:350ms 內、落點≤10遠端px 的兩次輕點 → 第二下改送 Agent 原生 `dblclick`(同點零延遲,不怕手指飄);第一下維持單擊(選取)。

‧ 部署:relay → S002 換新 exe 重啟;bridge → S002 換新 Stk_WebScreen.exe 重啟。兩者已 build 進來源目錄。

‧ 修改檔案:`Relay\relay_server.py`、`StkWebScreen\stk_webscreen.py`;備份 `.bak_keepalive_/.bak_dbltap_20260609_0110`(待確認後移除)。

v2026.06 2026-06-04

站內通訊

遠端螢幕視窗關閉後自動跳出圖片檢視器→已修正

技術說明：與截圖鈕共用指令誤判

詳細處理

問題：每次執行完 REMOTE(遠端螢幕)關閉視窗後,都會自動跳出 Windows 圖片檢視器顯示一張截圖,很干擾。

根因：遠端螢幕串流與 Screen 按鈕都用 CMD_SCREENSHOT。_on_update 分派時若找不到對應的遠端螢幕視窗(_remote_dlgs)就走 _handle_screenshot(存檔 + os.startfile 開圖)。遠端螢幕關閉後,in-flight 的 SCREENSHOT 回應沒有 dlg 了 → 被當成 Screen 按鈕截圖 → os.startfile 跳圖。

解決方法：加 self._pending_shot set —— 只有 Screen 按鈕主動觸發的截圖才加入 pending(do_screenshot 送前 add 裸 station name);_on_update 改成「elif name in _pending_shot 才 _handle_screenshot(存檔+開圖)」,遠端螢幕殘留的截圖直接忽略(不存檔不開圖)。

修改檔案：stk_commander_qt.py(__init__ _pending_shot、do_screenshot 標記、_on_update 分派)

v2026.05 2026-05-28

站內通訊

同步指令發出後無法看出各站同步結果→已修正

技術說明：清單無同步狀態欄

詳細處理

問題：SyncNow 指令發出後，操作員只能從 Log 區一行行翻才能看出每台 Station 同步結果，重開 Commander 就完全失憶。

解決方法：

‧ Station class 加 `last_sync` (timestamp) + `last_sync_status` (OK/PART/ERR)

‧ `_on_update` 收到 `cmd == CMD_SYNC_NOW` 回包時記錄結果

‧ Dashboard 末尾加 `Sync(W:\S00X=>C:\Stk\S00X)` 欄位，顯示 `mm/DD HH:MM OK/PART/ERR`

‧ 套色：OK 綠 / PART 橘 / ERR 紅

Agent status 對應：

| Agent | Commander | 意義 |

|---|---|---|

| OK | OK (綠) | 全部成功（含 skip） |

| PARTIAL | PART (橘) | 部分失敗（通常 Stk32.exe 被占用） |

| FAIL | ERR (紅) | 整個同步沒啟動（INI 沒設） |

踩坑：

‧ 欄位數量改動牽動兩處：`setHeaderLabels` cols + `QTreeWidgetItem` 初始化 list，要一起改齊

‧ 標題從 `Sync` → `Sync(W:\=>C:\Stk)` → `Sync(W:\S00X=>C:\Stk\S00X)`，欄寬從 90 → 140 → 200

修改檔案：

‧ `python/stk_commander_qt.py`（Station/header/widths/refresh/on_update 5 處）

‧ `HBSTK/build/update_server/pack_and_upload.bat`（同步來源改 `python/dist/stk_commander.exe`）

Build：

‧ `E:\Python312-32\python.exe -m PyInstaller --noconfirm stk_commander.spec`

‧ 產出 `dist/stk_commander.exe`（32-bit PE32，29.7 MB）

報告：[Sync欄位_20260528.pdf](Sync欄位_20260528.pdf)

STK32 進銷存 ｜ 錯誤修正

歷來錯誤修正(共 198 筆)

手機拍照一直顯示「電腦目前連不上」,但電腦有開、影像伺服器也有開 →已查明原因(處理方式見「詳細處理」)

圖形登入畫面常常「不見」,其實是被其他程式或 STK32 主畫面蓋在下面 →已修正(隨下次更新生效)

遠端服務程式(STK Agent)視窗每小時出現紅字「無法辨識 'ie4uinit.exe'」,桌面圖示有時沒有即時更新 →已修正(隨下次更新生效)

匯入原廠資料檔(三菱匯豐、裕隆雷諾)第二次起出現「AUTOSPAR.CDX erase error: 032」,之後再匯入都沒有作用 →已修正(隨下次更新生效)

詢價單按「8.確認」時出現「使用中,請稍後」,按 ESC 後跳出錯誤畫面;項目很多的詢價單確認時,其他電腦改詢價單也一直卡「使用中」 →已修正(隨下次更新生效)

信封、標籤直式列印時,造字(例如「羣」)沒有跟著轉向、橫躺在一排直立的字中間;改用電腦內建的字輸入,換一台電腦列印卻變成空白 →已修正(隨下次更新生效)

匯入原廠資料檔(三菱匯豐、裕隆雷諾等)時程式中斷,畫面先出現「使用中,請稍後」→已修正(隨下次更新生效)

報價單一列金額超過千萬（例如數量或單價打錯），存檔時程式中斷 →已修正（隨下次更新生效）

零件照片「移除圖檔連結」、換照片要等二、三十秒，還出現「還有 999 個零件也使用這張圖」→已修正（隨下次更新生效）

工作站突然無法列印:新增印表機出現「存取被拒」、已刪除的印表機在列印視窗還看得到 →已解決(Windows 端修復,STK32 不需更新)

工作站安裝遠端服務程式時，預設路徑變成主機的網路路徑（\\S001\STK\S003），而不是 W:\S003 →已修正（隨下次更新生效）

營運績效儀表盤的「當年營業額」比實際多出許多：已刪除的單據被重複計算 →已修正（隨下次更新生效）

執行「統計資料重算」後，客戶年度統計（P2621）的總金額和總營業額統計（P2641）對不上：有些銷貨退回被算到錯的年度 →已修正（隨下次更新生效，更新後請再執行一次統計資料重算）

統計資料檔（客戶、廠商、零件年度統計）按「查詢」時跳出錯誤「BASE/1004 No exported method: CARGO」，畫面無法使用 →已修正（隨下次更新生效）

主機已換成新版影像伺服器，工作站卻一直使用舊的 Java 版（IS.jar），手動切換也沒有作用 →已修正（隨下次更新生效）

修改「品名片語」的英文名稱後，國外到貨單依英文名排序的結果完全沒變，重排幾次都一樣 →已修正（隨下次更新生效）

國外到貨單重新開啟時，表身明細可能比實際筆數少顯示 →已修正（隨下次更新生效）

主機更新完成後，桌面 STK32 圖示右下角的「新」字一直不消失（工作站正常） →已修正（隨下次更新生效）

年度統計（銷貨淨額／進貨淨額／銷售毛利）在 100x30 畫面下，每月金額和最下方合計都少了右邊兩位數 →已修正

統計視窗拖曳欄位分隔線調整欄寬時，被調整的卻是左邊隔壁那一欄 →已修正

資料庫工具 DBX32：修改資料表結構（例如新增欄位）按 F2 套用後程式當掉 →已修正

資料庫工具 DBX32：按 Alt+C「複製到」，程式直接關閉 →已修正

資料庫工具 DBX32：開啟檔名含空白或中文的資料檔（例如「XXX - 複製.DBF」），一關檔程式就當掉，之後每次開啟 DBX32 都會報錯 →已修正

重建索引、壓縮資料時，程式偶爾突然整個消失（只跳出「Abnormal program termination」），同樣的資料再做一次又正常 →已修正

報價單存好之後，在彙總視窗（單號欄按 Shift+?）找不到這張單，但明細其實都還在 →已修正（隨下次自動更新生效）

awiCapture 截圖工具已隨更新送到各站台，但工作站開啟 STK32 時沒有跟著啟動 →已修正

少數站台在遠端管理清單中不顯示 IP，更新時被整台略過 →已修正

更新失敗時只顯示「失敗 1 項」，查不出是哪個檔案出問題 →已改善

製單時用 F2 客戶視窗 / F1 廠商視窗快查，找到的那筆停在視窗最後一列，相近的資料都要往下翻才看得到 →已修正

報價單打到一半，已經輸入好的那一筆明細突然消失(被下一筆蓋掉) →已修正

圖片視窗每隔幾分鐘就跳出「網路斷線」提示、圖框一下出現一下消失，但其實網路很穩定 →已修正

按 Alt+M 圖片視窗不出現，只看得到工作列上的圖示 →已修正(並支援雙螢幕)

某一台的報表格式檔損壞時，自動更新每一輪都顯示失敗、版本一直升不上去，而且看不出是哪個檔案 →已改善

主機開機時網路還沒準備好，背景程式就記成「沒有 IP」並且一整天不再重新取得，導致大型檔案派送一直跳過這台 →已修正

開啟既有單據時，明細筆數與表頭記載對不上（索引異常或明細短少） →已加上自動核對

報價轉銷貨時明細沒有全部轉過去，要到出貨或對帳才發現 →已加上完整性檢查

兩張報價單指向同一張銷貨單（轉單後回寫註記寫到別張） →已加上防護

一打開進銷存，登入畫面的密碼欄就「打不進字」，要先用滑鼠點一下才能輸入 →已修正（隨下次自動更新生效）

Windows 11 開啟進銷存時，跳出「Windows 安全性警訊：是否允許圖片視窗存取網路」的詢問 →已修正（隨下次自動更新生效）

詢價單／報價單用 Alt+R 匯入明細後，修改明細時卡在「庫位」欄像當機一樣，過一陣子才跳出「尚未建立，是否建立？」 →已修正（隨下次自動更新生效）

應收票據託收：清單上只剩一張票時，託收單會把同一張印成兩行，張數與總金額都變成兩倍 →已修正（隨下次自動更新生效）

報表列印或預覽時，最後面會多出一張完全空白的紙 →已修正

客戶檔的清單快查，找不到代號排在最後面的客戶（例如 Z 開頭）→已修正

自動更新顯示「更新成功」，但程式其實沒有換成新版 →已修正

自動更新顯示「更新失敗」並停住畫面，但其實已經成功 →已修正

有電腦沒有退出系統時，自動更新會一直卡住不動，也沒有任何結果回報 →已修正

有電腦開著系統時，自動更新照樣往下做而撞到資料檔，失敗訊息又看不出是誰沒退出 →已修正

主機上開著「設定編輯器」時，自動更新每次都失敗 →已修正

查零件圖片（Alt+M）時影像視窗開得出來，但圖片區一片空白 →已修正，並已主動為所有客戶清除隱患

桌面上的 STK 捷徑會自己從 W:\S00X\STK32.EXE 變成 \S001\stk\S00X\STK32.EXE，點了打不開 →已修正，並會自動修回

客戶／廠商基本資料按 Alt+R 執行「帳款自動消帳」時，程式出現錯誤畫面中斷 →已修正

自動更新顯示「更新完成」，但「會計」與「人事薪資」沒有安裝，資料庫欄位也沒有加寬 →已修正

資料庫結構升級之後，索引沒有一併重建（潛在的資料對不上風險）→已修正

年度統計報表的月金額欄位放不下，顯示成一整排星號 →已加寬（需執行統計資料檔重算）

詢價製單「匯入資料檔」後選擇列印未匯入清單，整個畫面凍住、按什麼都沒反應 →已修正

單據表頭「結帳日期」按 ? 帶入日期沒有反應（銷貨／進貨／報價皆受影響） →已修正

連續標籤紙印到第二張就開始往上偏，越印偏越多；調整印表機驅動設定後 →已解決

月對帳單（摘要格式）的「現金」「支票」兩欄變成 0，舊版明明印得出來 →已修正

自動更新出現「更新失敗」：部分檔案送不到某一台電腦

高解析度螢幕：系統畫面在登入時突然縮小一半

零件資料視窗縮小或拖曳分隔線時跳出錯誤畫面

國內到貨時跳出「除數為零」錯誤

列印「廠商報價未匯入清單」時跳出錯誤畫面

進貨單輸入中按下快速鍵後跳出錯誤畫面

對帳單／報價單印在小張紙（一張裁成兩半或三段）時，每張只印出前面一小段，後面的明細整段不見 →已修正

Windows 7 電腦「跨站複製貼上」有時沒反應、老是顯示沒有新內容 →需安裝微軟更新(非程式問題)

換過印表機之後，那台電腦一開就停在黑畫面、跳紅色錯誤框，完全進不了系統（同一家店其他電腦都正常） →已修正

印表機清單出現兩個同名的「二號印表機」，其中一台其實已經不存在，選到就印不出來 →已修正

Windows 7 電腦執行「桌面捷徑修復工具」等於沒按：跑完沒有任何錯誤，捷徑卻還是壞的 →已修正

主機（或網路）斷線時，畫面連續跳出三、四個看不懂的英文錯誤 →已改善為一句看得懂的中文提示

比價單自動帶入建議進貨資料時，只要其中一筆金額超過千萬，整張單就當掉 →已修正

報表查詢畫面按 F9 重新查詢、查不到資料後離開，系統當掉 →已修正

進貨單刪除明細項目要停頓一、兩秒（銷貨單刪除卻很快） →已修正

國內／國外比價製單「表身批增（依交易歷史）」選全部零件時要等 37 秒、畫面像卡住 →已修正

客戶／供應商「貨款結帳」本來就不列印，做完卻還是跳出列印詢問視窗 →已修正

單據內容同時含「品」字、且後方欄位是「Z+數字」（如儲位 Z424）時，列印成 PDF 明細行會跳到下一頁頁首、版面錯亂 →已修正

遠端桌面（WebScreen）無法用滑鼠雙擊，必須先點一下再按 Enter →已修正

多人同時使用遠端桌面時，畫面卡住、沒反應或變得很慢 →已修正

STK32 進銷存｜錯誤修正