It was always displayed (sent to stderr) when running scfg, echocfg, uedit,
etc. in auto-curses mode, so suppress that noise.

Some USB modems (reportedly, USRobotics USB modem) don't strip the parity bit
of data received from modem connections operating in < 8 bit modes
(e.g. 7-E-1), as is normally don't with a modem connected to a UART, so we'll
do that stripping (forcing to 0) here, as recommended by Deuce.

Nelgin, if you're doing some manually stripping of the 7th bit bytes received
from 7-E-1 connected modems and then sent to your server/BBS over TCP, you
shouldn't need to do that now.

I dislike this particular code a little less now:
- no more redundant string compares
- less deeply nested if() and for() blocks
- remove added areas from the add list, rather than zeroing out the tag
- a little more common code between areas.bbs and areas.ini handling

No functional change (I hope).

To quickly free and remove all list entries (without realloc).

Easier to match up than numbers.

Split generating help into separate function
- Regenerated when the connection type changes
Split generation the opt list into separate function
- Regenerated after handling any selection

If someone wants to know the differences between 1.2rc1 and 1.2rc3,
the can check git.

We just need to strip the high bit on RX because the mode leaves
it on received bytes.

to unblock the pipes

"AreaFix" is a proper product name. Though it's been defunct and unsupported
for decades, we still should not confuse sysops and historians: the general
term for what AreaFix did/does is Area Management, aka Conference Management.

The sbbsecho.ini key names are unchanged and the destination netmail address
for AreaManager requests can still be "AreaFix" (though "SBBSecho" is still
supported as well).

and vice versa - so area manager requests were broken since I introduced the
areas.ini support. Oops.

I noticed through code review that these kinds of messages would be rejected
as "No commands to process.". We just needed to increment the 'cmd' counter
when parsing these options to be sure we don't think that no commands were
in fact request. -R (rescan) is not by itself a command since it requires
listed area-tags to have any effect.

... like how we do for areas.bbs files.

For use cases were we don't want to silenty ignore duplicate (secondary)
section definitions.

This is just in case the modem actually stays in 8N1 mode when
7E1 or 7O1 is set.  This is what the USR 5637 appears to do.

There's a small performance penalty for anything in 7-bit mode with
this, but it shouldn't be enough to actually impact anything.

Possibly setting CTS/RTS after raising DTR drops DTR which causes
DCD to be lost.

DDMsgReader bug fix: When viewing a poll that the user has posted and showing who voted on the poll, ensure it only counts poll responses (not reply messages). Reported by nelgin

See merge request !474

Eric Oulashin authored 3 months ago and Rob Swindell committed 3 months ago

DDMsgReader bug fix: When viewing a poll that the user has posted and showing who voted on the poll, ensure it only counts poll responses (not reply messages). Reported by nelgin

I'm not clear if/why these would cause the issue reporetd by
Fernando but they're definitely bugs in the areas.ini areafix
code. No impact to the areas.bbs areafix handling.

... in area manager code modified in previous commit.

Even when "lean and mean".  Rename enum.

Also, straighten out the confusing option adjuster thing when editing
an entry.

The help text still needs an overhaul, but now I have to re-test this
whole mess.

Surely nobody uses anything else...

It's possible the client requested binary transmit in only one of the two
directions and if so, restore just the direction that was previously *not*
in binary transmit mode to NVT mode.

This allows us to save unitialized telnet_*_option values (i.e. 0x00) and pass
those values back to request_telnet_opt() with no side effect.

Show current list path, not default in File Locations
Support copy/paste in BBS list

Makes the Night Owl BBS login screen look more accurate.

Before this change, we'd always request a return to Telnet NVT (turn off
binary-TX in both directions) after any file transfer. So although a Telnet
session might be negotiated into binary mode shortly after connection
(e.g., using "telnet -8"), it would be reverted back to NVT mode after any
file transfer.

The request to turn off remote binary-TX after executing external programs
didn't actually accomplish anything since we track the Telnet option states
internally and don't send redundant requests (e.g. the change into a mode
we're already in). External programs aren't expected to send Telnet requests
anyway, so I think this was some holdover from early days of stp/sexyz
development.

Where's the compiler warnings guys?

As suggested/requested by Fernando Toledo in issue #826, you can:
1. run 'jsexec make_areas_ini.js' to export your areas.bbs file to areas.ini
   (your old areas.bbs is left in place, in tact, unmodified)
2. change your Area File in echocfg->Paths and Filenames->Area File to
   somepath/somefile.ini (e.g. "../data/areas.ini") and SBBSecho will use
   the .ini file format instead of the old AREAS.BBS format (NIH)

You can always go back to your areas.bbs file by just reverting the Area File
setting back to some other non-ini filename (e.g. "../data/areas.bbs").

Incremented version number to v3.23

Of course documentation and echocfg changes will need to follow, but this is
enough to start testing (looking at your Fernando! :-).

I tried to minimize the diff as much as possible and resisted updating
(modernizing, fixing) the very old AREAS.BBS parsing and areafix code.
The new .ini code is largely modeled after the old areas.bbs code, but oh,
xpdev/ini_file makes things so much nicer and easier.

There are no known fixes for any pre-existing area file/fix issues (including
issue #826), but it's always possible I've introduced a new issue.