Settings and data context

Inspect Config/settings classes and current UI before using these names; this list records important settings/concepts encountered during prior work.

Band / station settings

Important concepts have included:

MYQRGFirstCat;
MYQRGSecondCat;
manual station band information;
current/actual QTF;
known-active bands;
selected/current QRG.

Band-dependent features must use the correct category/station context.

Antenna / path settings

Important concepts have included:

actualQTF;
antennaBeamWidthDeg;
maximum QRB;
AirScout/path-analysis settings.

Missing QRB/QTF must remain unknown, not numeric zero.

UI settings

Persisted UI behaviour has included:

dark mode;
map/path-analysis visibility;
filters/reachability controls;
column visibility;
divider/layout state where implemented.

Do not reset persisted user choices as an incidental effect of a feature change.

Logging / worked persistence

Worked information is persisted and updated through multiple input paths.

Before changing one path, compare semantics across:

DB load on startup;
simple/manual log integration where present;
UCXLog/DXLog;
Win-Test;
other current logging inputs.

The goal is one worked-state interpretation regardless of source.

Chat/message automation

Configuration has included:

beacon/autoanswer enablement;
beacon defaults;
message limits/timers;
category-specific communication.

Do not duplicate timers or create per-feature scheduling that bypasses the shared safety model.

Connection state

Connection-state UI must reflect actual ON4KST connection lifecycle.

Any new state enum/property should have a clear owner and thread boundary.

Persistence rule

Do not change persisted keys/schema/semantics simply to make new code easier.

If a schema/key migration is required:

explain current and new format;
describe backward compatibility;
ask for approval before implementing.

1.9 KiB Raw Blame History