Our read-only FR5 dashboard keeps a believable mode on screen when the replacement SDK reports failure. The wrapper takes one field from the new response container and never checks whether that field is valid. I need to change the interpretation without making old saved captures unreadable.
FR5 mode display borrowing a value from a failed reply
MiaChan1079 · 2025年12月9日 00:36 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
17 条回复
回复 MiaChan1079
Separate the interpretation for each supported response contract. Preserve the raw captures with their source version. A parser for the new container should establish request success and field validity before returning a usable mode, rather than relying on a value that happens to look familiar.
7分回复 LinBell0618
The captures already include the SDK version. The live wrapper does not use it to choose a parser; it guesses from the shape. A failed reply can satisfy that guess.
15分回复 MiaChan1079
Then keep unsupported combinations visibly unsupported. Guessing is exactly what gave the failed response a respectable-looking mode in the first place
25分回复 MiaChan1079
What will the operator see while there is no valid mode? A blank space made our tutor think the page was still loading, not that the read had failed.
2分Could it show the last good value, clearly marked old?
14分We want that for diagnosis, Robin. But it must not occupy the current-mode field. The present design puts the last valid value and its time underneath an unavailable message.
20分回复 MiaChan1079
I like the separate place. Does the unavailable wording say the read failed, rather than implying the controller itself has definitely stopped responding?
17分The display can distinguish a reported request failure, a timeout and a reply it cannot interpret, where the available evidence supports those distinctions. It should not manufacture a machine state from any of them.
16分回复 LinBell0618
Lin, yes, but don't put the whole parser diagnosis in the main status label. People need the immediate meaning first, with the reason available underneath
21分Would read unavailable be enough there, with the reason below?
12分That wording is a reasonable candidate for a walkthrough. The diagnostic detail can remain separate; I was describing the information to retain, not prescribing a long label.
25分回复 LinBell0618
The two explicit parsers now pass our saved success and reported-failure examples. The live configuration names its supported SDK version. We still need malformed containers and timeout cases before I would call the wrapper ready.
7分回复 MiaChan1079
Include an old value that looks perfectly ordinary in the walkthrough. A ridiculous value won't tell you whether someone mistakes a stale reading for the current one.
6分Sofia, that is now in the example. We retained an ordinary last-good mode from before the failed read. The tutor has not tried the revised screen yet.
13分回复 MiaChan1079
Can the tutor tell a saved capture from the live view too? You mentioned keeping both readable, and that is another place a valid old mode can look current
14分The saved view is labelled with its capture time and connection identity. I have added switching between that and the live view to the walkthrough. The current failure is not being hidden by a successful old capture.
13分回复 MiaChan1079
Let us know which wording the tutor actually understood first.
24分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .