You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ETB Von/An fields render visibly differently from the "Funkrufname" (call sign) field in Kräfte, Funktionen, and Atemschutz — reported as "the callsign autocomplete boxes on ETB look different than in other places."
Root cause
Not a styling bug — the app has two genuinely different control types in use for call-sign-ish fields, and they've never been reconciled:
AutoCompleteBox (free-text entry with suggestions, no dropdown arrow) — used for fields whose docstring reasoning is "must stay enterable, not a closed set":
ForcesView.axaml — Brigade (BrigadeBox)
RolesView.axaml — Name (PersonNameBox)
OperatorPromptView.axaml — the operator's own call sign (CallSignBox)
ComboBox (closed picker, visible dropdown chevron) — used for the "Funkrufname" field specifically:
RolesView.axaml:26
ForcesView.axaml:38
ScbaView.axaml:60
So 4 of 7 call-sign-ish fields across the app already use the free-text AutoCompleteBox pattern; the "Funkrufname" ComboBox in Roles/Forces/Scba is the outlier, not ETB.
Bonus bug found while investigating:RolesView.axaml:26 and ForcesView.axaml:38's Funkrufname ComboBox have no PlaceholderText set at all, so they render as a blank box with only an arrow — no label telling the user what it's for. ScbaView.axaml:60 does set PlaceholderText="Funkrufname" correctly.
Open decision (needs product input before implementing)
Which direction should "unify" go?
AutoCompleteBox everywhere — convert Roles/Forces/Scba's Funkrufname ComboBox to the same free-text-with-suggestions pattern as everywhere else. Matches the majority existing pattern and its stated reasoning (a unit/person's call sign might not be in Stammdaten yet either). Also fixes the missing-placeholder bug as a side effect. This is a real behavior change: users could type an arbitrary call sign for Kräfte/Funktionen/Atemschutz, not just pick from Stammdaten.
ComboBox everywhere — convert ETB's Von/An to a closed picker instead. This was deliberately rejected for ETB in ETB #73 (Von/An must accept non-Rufname senders like "ELW 1" or a person's name), so this direction would need re-litigating that decision.
Suggested next step
Once the direction is decided, extract a single reusable component (e.g. a small UserControl or a shared ControlTemplate/style) for "pick or type a call sign," used consistently by all five current call-sign fields (Roles, Forces, Scba, ETB Von, ETB An) plus the operator's own call-sign field, so future call-sign fields can't drift again the way this one did.
Problem
The ETB Von/An fields render visibly differently from the "Funkrufname" (call sign) field in Kräfte, Funktionen, and Atemschutz — reported as "the callsign autocomplete boxes on ETB look different than in other places."
Root cause
Not a styling bug — the app has two genuinely different control types in use for call-sign-ish fields, and they've never been reconciled:
AutoCompleteBox(free-text entry with suggestions, no dropdown arrow) — used for fields whose docstring reasoning is "must stay enterable, not a closed set":ForcesView.axaml— Brigade (BrigadeBox)RolesView.axaml— Name (PersonNameBox)OperatorPromptView.axaml— the operator's own call sign (CallSignBox)EtbView.axaml— Von/An (added in ETB #73)ComboBox(closed picker, visible dropdown chevron) — used for the "Funkrufname" field specifically:RolesView.axaml:26ForcesView.axaml:38ScbaView.axaml:60So 4 of 7 call-sign-ish fields across the app already use the free-text
AutoCompleteBoxpattern; the "Funkrufname"ComboBoxin Roles/Forces/Scba is the outlier, not ETB.Bonus bug found while investigating:
RolesView.axaml:26andForcesView.axaml:38's FunkrufnameComboBoxhave noPlaceholderTextset at all, so they render as a blank box with only an arrow — no label telling the user what it's for.ScbaView.axaml:60does setPlaceholderText="Funkrufname"correctly.Open decision (needs product input before implementing)
Which direction should "unify" go?
ComboBoxto the same free-text-with-suggestions pattern as everywhere else. Matches the majority existing pattern and its stated reasoning (a unit/person's call sign might not be in Stammdaten yet either). Also fixes the missing-placeholder bug as a side effect. This is a real behavior change: users could type an arbitrary call sign for Kräfte/Funktionen/Atemschutz, not just pick from Stammdaten.Suggested next step
Once the direction is decided, extract a single reusable component (e.g. a small
UserControlor a sharedControlTemplate/style) for "pick or type a call sign," used consistently by all five current call-sign fields (Roles, Forces, Scba, ETB Von, ETB An) plus the operator's own call-sign field, so future call-sign fields can't drift again the way this one did.