https://gitlab.synchro.net/main/sbbs/-/commit/bf431220dd59fefe1c755d9d
Modified Files:
src/sbbs3/ctrl/MainFormUnit.cpp
Log Message:
Use the configured Statistics Interval

for the SBBSCTRL:Statistics windows update timer interval
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ba97cebf8d280eb28d86bbb6
Modified Files:
src/sbbs3/ctrl/MainFormUnit.cpp
Log Message:
Timer interval is in milliseconds, not seconds (whoops)

Also, insure a minimum interval (lower bound) of one second here.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/7e1dec3efa39d492d3c1b064
Modified Files:
src/sbbs3/ctrl/MainFormUnit.cpp src/sbbs3/date_str.c date_str.h slog.c Log Message:
Add minutes_as_hhmm(), enhance minutes_to_str(), and fix seconds_to_str()

- Refactor sectostr() - ancient mess, but worked okay I guess (no size arg)
- If seconds_to_str() was passed a value of 0, it'd return a pointer to the
end of the string (empty), so always leave the last 0 in the returned str
- minutes_to_str() now accepts an 'estimate' argument and can provide
duration estimates (to the fractional-hour), optionally
instead of an exact amount of hours, minutes, and seconds
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/76d270258fa4bcc644e656a9
Modified Files:
src/sbbs3/ctrl/MainFormUnit.cpp
Log Message:
Use minutes_to_str() for the TimeToday statistics (e.g. "59m", or "5.6h")
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f65fd89a106023a5aa7570ce
Modified Files:
src/sbbs3/ctrl/MainFormUnit.cpp
Log Message:
Resolve crashes during graceful server termination(s)

These crashes have been happening seemingly forever, but only noticed (by me) when running in a debugger, otherwise Windows seems to suppress any exception message/popup since the process terminates anyway.

The problem appears to be that we were setting app controls (e.g. start/stop button states) in the startup->set_state callbacks and it was possible through race conditions that the application (or at least the forms) were actually destroyed already at the time those callbacks are called (to a report server state of STOPPED as one of the last things each server thread does).

The solution was to store the value of the reported server states in (global) variables and asynchronously (at "appy time") update the relevant controls based on the server state(s). Since the LogTimer runs more frequently (2Hz) than UpTimer (1Hz) and isn't stopped (early) during process termination,
that was the place best-suited to do these control updates.

In this process, I also made the app controls make more sense (e.g. the
"Start" button is disabled during server initialization) and the "Abort" dialing while waiting for graceful server termination(s) is much improved
(e.g. lists all the servers still running), but now it does not popup for 60 seconds after termination requested (rather than 30 seconds as before) - as
if the user presses "Yes", this initiates an *ungraceful* exit of the program which could result in crashes (though Microsoft seems to suppress the user notification of these).
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net