https://gitlab.synchro.net/main/sbbs/-/commit/a2cd1d341bc92ee3556a8694
Modified Files:
src/sbbs3/ctrl/MainFormUnit.cpp
Log Message:
Wrap all ClientForm->ListView->Items accesses in try/catch

... this appears to resolve the "invalid index" exceptions that could get thrown and pop-up error dialogs in SBBSCTRL-Win32 ... finally.

It's a mystery how the ListMutex isn't successfully protecting the ListView (the ListView->Items->Count becomes out of sync?), but if the array index
into the ListView->Item array is invalid, it must be. Pretty weird.

Also, if WaitForSIngleObject() fails (to acquire the ListView mutex), popup
an error dialog box. I have not observed any mutex acquisition failures.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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/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