PTZControl2 currently accepts the original GUI \-noguard startup argument and the compatible registry option as compatibility inputs, but it does not implement the old MFC guard-thread behavior.\n\nOriginal PTZControl behavior:\n- Starts a guard thread by default.\n- The guard thread is intended to detect USB/app blocking conditions and may terminate the application.\n- \-noguard or registry Options/NoGuard disables that guard thread.\n\nPTZControl2 current behavior:\n- No MFC guard thread exists.\n- Camera actions are handled through the new backend and should report errors to the UI instead of crashing/blocking the app.\n- \-noguard is accepted for command-line compatibility, but has no additional runtime effect beyond status/option handling.\n\nOpen questions:\n- Can camera/backend calls still block long enough to require watchdog behavior?\n- Should PTZControl2 implement targeted action timeouts/cancellation instead of a process-ending guard thread?\n- Should the \-noguard option remain documented as compatibility-only unless tests reveal a real blocking scenario?\n\nAcceptance criteria:\n- Decide whether PTZControl2 needs an equivalent safety mechanism.\n- If needed, define a modern approach such as per-action timeout/retry/cancellation rather than direct process termination.\n- Update Help/About/docs accordingly.
PTZControl2 currently accepts the original GUI \-noguard startup argument and the compatible registry option as compatibility inputs, but it does not implement the old MFC guard-thread behavior.\n\nOriginal PTZControl behavior:\n- Starts a guard thread by default.\n- The guard thread is intended to detect USB/app blocking conditions and may terminate the application.\n- \-noguard or registry Options/NoGuard disables that guard thread.\n\nPTZControl2 current behavior:\n- No MFC guard thread exists.\n- Camera actions are handled through the new backend and should report errors to the UI instead of crashing/blocking the app.\n- \-noguard is accepted for command-line compatibility, but has no additional runtime effect beyond status/option handling.\n\nOpen questions:\n- Can camera/backend calls still block long enough to require watchdog behavior?\n- Should PTZControl2 implement targeted action timeouts/cancellation instead of a process-ending guard thread?\n- Should the \-noguard option remain documented as compatibility-only unless tests reveal a real blocking scenario?\n\nAcceptance criteria:\n- Decide whether PTZControl2 needs an equivalent safety mechanism.\n- If needed, define a modern approach such as per-action timeout/retry/cancellation rather than direct process termination.\n- Update Help/About/docs accordingly.