-
Rob Swindell authored
Reported by Max (WESTLINE)... Introduced in commit 75c5c9e5, since we are now calling the set_state() callback periodically, and in sbbsctrl, it sets/resets the pause button checked (depressed) state in response to this callback (should it?), this was resetting the pause button checked/depressed state peridically (at the configured sem file check interval, default 2 seconds). The fix: if the new server state is the same as the previously set server state, don't call the set_state() callback. I considered this as a potential optimization when I first wrote that commit, but didn't see any obvious downside to calling the set_state() callback redundantly. Now that I see a downside, let's implement this saving/checking of the state to avoid redundant "set" calls.
Rob Swindell authoredReported by Max (WESTLINE)... Introduced in commit 75c5c9e5, since we are now calling the set_state() callback periodically, and in sbbsctrl, it sets/resets the pause button checked (depressed) state in response to this callback (should it?), this was resetting the pause button checked/depressed state peridically (at the configured sem file check interval, default 2 seconds). The fix: if the new server state is the same as the previously set server state, don't call the set_state() callback. I considered this as a potential optimization when I first wrote that commit, but didn't see any obvious downside to calling the set_state() callback redundantly. Now that I see a downside, let's implement this saving/checking of the state to avoid redundant "set" calls.