#910 / #1145 added validation for one specific case: the DBGENG_TTD adapter with no launch.trace_path set. That check lives in AdapterSettingsDialog::apply() and is deliberately narrow — it only covers the setting whose absence is guaranteed to fail the launch, so the dialog does not get in the way of anything an adapter would otherwise accept.
The same class of problem exists elsewhere. Settings that are required, or that point at a path which does not exist, are generally accepted by the dialog and only surface later as an adapter-specific error, if at all. Some candidates:
common.inputFile — pointing at a file that no longer exists- Working directory settings that name a nonexistent directory
- Remote host / port for the connect and debug-server flows: empty host, port 0, unparseable input
- Windows kernel and dump file adapters, where the target path is equally non-optional
- Executable path for the local adapters
Worth deciding on the mechanism before adding cases one at a time. Options:
- Keep extending
validateSettings() in AdapterSettingsDialog with per-adapter special cases. Simple, but the UI ends up knowing adapter-specific rules, and it does nothing for headless use.
- Give
DebugAdapterType (or the adapter) a validation entry point that returns the problems for the current settings, and have the dialog surface whatever it reports. Keeps the rules next to the adapter that owns them and can be reused by the launch path and headless callers.
Option 2 seems better long term. The #1145 change also duplicates the check in DbgEngTTDAdapter::ExecuteWithArgsInternal so scripted and dialog-skipped (#1133) launches are covered; a shared entry point would remove that duplication.
Separately, SettingsView could grow support for marking a setting as required, so the failure is visible in the settings UI itself rather than only in a message box on Accept.
#910 / #1145 added validation for one specific case: the
DBGENG_TTDadapter with nolaunch.trace_pathset. That check lives inAdapterSettingsDialog::apply()and is deliberately narrow — it only covers the setting whose absence is guaranteed to fail the launch, so the dialog does not get in the way of anything an adapter would otherwise accept.The same class of problem exists elsewhere. Settings that are required, or that point at a path which does not exist, are generally accepted by the dialog and only surface later as an adapter-specific error, if at all. Some candidates:
common.inputFile— pointing at a file that no longer existsWorth deciding on the mechanism before adding cases one at a time. Options:
validateSettings()inAdapterSettingsDialogwith per-adapter special cases. Simple, but the UI ends up knowing adapter-specific rules, and it does nothing for headless use.DebugAdapterType(or the adapter) a validation entry point that returns the problems for the current settings, and have the dialog surface whatever it reports. Keeps the rules next to the adapter that owns them and can be reused by the launch path and headless callers.Option 2 seems better long term. The
#1145change also duplicates the check inDbgEngTTDAdapter::ExecuteWithArgsInternalso scripted and dialog-skipped (#1133) launches are covered; a shared entry point would remove that duplication.Separately,
SettingsViewcould grow support for marking a setting as required, so the failure is visible in the settings UI itself rather than only in a message box on Accept.