"SyncTERM is not responding" modal dialog - Ubuntu Linux
I have not seen this popup using 1.8 - appears fixed
Key-repeat of arrow keys in Wayland mode sends digits to server
Copying text in X11 mode isn't working
I missed the "minimize" control the most. A title bar to grab and drag to move the window would be nice
The problem might also happen in Wayland (not sure), but I don't like the lack of window controls in Wayland mode, so I normally run it in X11.
The problem might happen in Wayland, but I don't like the lack of window controls in Wayland mode, so I run it in X11.
yeah, that or (more likely) the one without the focus window on it.
"SyncTERM is not responding" modal dialog - Ubuntu Linux
Don't require C++ compiler to build w/make on Linux
Support higher/non-standard baud rates for serial (and 3-wire) connections
Receive translation for LF->CRLF for serial and "3-wire" connections
Appears fixed in latest nightly build.
Use standard key combinations for copy/cut/paste of items and text
It sounds like you turned off CP437 support in your BBS user account.
Still happens with current v1.8b.
Looks fixed to me in nightly build. Now get list of drive letters at top of tree! :-)
I just reproduced it (still happens) with the nightly built 3/20/206 12;16AM.
Looks fixed to me in nightly build.
Closing with the Window manager ('X') while connected creates a zombie process
Here's the video screen cap if you need it.
When scrolling, status bar doubles for a fraction of a second
One can walk back past the root directory on Windows
One can walk back past the root directory on Windows
Was not immediately reproducible after closing and re-running SyncTERM. :-(
Some keys stop working after ctrl-clicking a URL
Example SyncTERM 1.7 Windows installer prompting for install location:
This is supposed to be the current behavior of the Windows installer, unless the program has already been installed, in which case it'll reuse the previously installed-to directory. InnoSetup says this about the DisableDirPath "auto" setting (the default): "at startup Setup will look in the registry to see if the same application is already installed, and if so, it will not show the Select Destination Location wizard page."
Error during compile
Extra character displayed after RIP screens
Changing Download Directory while connected has no immediate effect
Changing Download Directory while connected has immediate effect
Batch (multi-file) upload support
Screen Mode can be changed even when RIP is enabled
Okay. I thought the issue was previously fixed (?) and this was a regression.
Blackbars and odd sizes in X11 output mode connecting to C6 4 BBSes
Blackbars and odd sizes in X11 output mode
Sending Ctrl-H (ASCII 8) instead of Ctrl-T (ASCII 20) for backspace key in C6 4 and C128 modes
"of the same type" (not time)
Scroll (left and right) through Directory Entries in "Edit" window
Error getting default Web List on Windows
Sending login info while in Windows console or ANSI video mode sends extra data
Answer accepted
Yeah, that could be it (timing), but why the difference in behavior between SyncTERM video modes?
Yes, I think it's still a good idea. Shift click/drag seems a lot more convenient than the Alt-O toggle (though that's useful too, so I wouldn't remove that).
If you don't like the shift-select idea, sure close the request. :-)
+1 for this
Alt-x key just sends 'x' when in Windwos ANSI mode
Sending login info while in Windows console or ANSI video mode sends extra data
Alt-x key just sends 'x' when in Windwos ANSI mode
Red status bar in Windows console and ANSI modes
It causes an issue for anything that checks the SS_ABORT flag (exposed in JS as console.aborted) - it basically doesn't work. So you can't abort operations with Ctrl-C any more.
I'm not sure how well raw mode is supported in older versions of Synchronet. SSH mode would be another workaround, but again, older versions of Synchronet might be an issue.
It's going to be a long/fun FAQ if there's no available work-around for this.
I haven't encountered this issue before. I was able to reproduce it with "telnet -8", but never seen it with another BBS terminal. :-(
Re-consider BINARY_TX Telnet mode or make it optional
bar is the lightbar offset from the top of the visible list of options (0 being the first visible option). If there are 18 lines (for options) in the list window, the bar should always be between 0 and the list height (the scrollable region of the window) - 1 (e.g. 17 in this example). cur is the currently selected "option" index (0 being the first option), cur should always between 0 and the option_count - 1.
bar is the lightbar offset from the top of the visible list of options (0 being the first visible option). If there are 18 lines (for options) in the list window, the bar should always be between 0 and the list height (the scrollable region of the window) - 1. cur is the currently selected "option" index (0 being the first option), cur should always between 0 and the option_count - 1.
But that code isn't modifying bar.
Are you close to a solution or I should be working on it too?
If you arrow down while in this state, the cells below the list window are "hightlighted".
Deleting next to last Directory entry corrupts the list
Can't send non-ASCII characters via clipboard-paste or Alt-numpad combos
Okay, maybe it never was supported. I'll close the issue.
Right, but characters 169, 174, 219, 221, 222 are a valid CP437 characters. How do you send them? I was also surprised that the the existence of any of these characters in the clipboard buffer caused the entire clipboard buffer to not be pasteable into SyncTERM.
Alt-0171 and Alt-0187 work, but not Alt-0174 or Alt-0169. It seems like only those characters that have a CP437 equivalent char are being accepted. Maybe it's always worked this way?
Alt-0220 and Alt-0223 seem to work consistently (as well as when pasted from clipboard), but not Alt-0219, Alt-0221, or Alt-0222- for example.
Every once in a while, I can get a character from a Alt-numpad sequence, but just one and repeating the sequence doesn't work again. It seems intermittent.
Can't send non-ASCII characters via clipboard-paste or Alt-numpad combos
Clipboard-copy functionality is (for text) is my main use case for scroll-back
Window size shrinks after C64 connect/attempt is complete
Confirmed fixed in rc4
After disconnecting and viewing scrollback (Alt-B), can't copy text from screen/buffer to clipboard
SyncTERM make static noise before beep upon receiving multiple ^G chars
SyncTERM make static noise rather than success beeps upon receiving ^G chars
Don't think this can be changed/fixed?
I had the same issue with the 1.2rc3 binary and had to disable the Windows Security "Check apps and files" option again to be able to run from explorer. Command-line invocation worked either way.
Confirmed, I can produce the static noise by simple sending a bunch of BEL characters from the server. e.g. ;eval console.beep(100) This happens in Windows console, GDI, and SDL modes. Weird.
Yeah, not a huge issue, but I know alt-right-arrow (and use it frequently). Might be annoying for users that don't.
Video capture to go along with that packet capture
Try that capture again
pcap from the mouse movement noise (2 occurrences), in Telnet mode.
Still happens in rc3.
Window size shrinks after C64 connect/attempt is complete
The downloaded file protection in Windows displays a graphical dialog box where you have to click "more info, allow" something like that. It's not that.
That's unfortunate, I liked/used that time-saving feature. The way I original implemented it, there was no delay. You modified (to improve it in some way I assume), which resulted in the new delay. A think a popup message (invisble on systems with no delay) would have been the ideal solution if the delay could not be otherwise avoided.
Nothing appears in any log (Windows Events, Defender Protection History) or notification area. I tried moving/renaming the syncterm.ini file, but that made no difference. On 2 other (Windows 10) systems I tried, syncterm.exe was runnable from explorer. The problematic computer is running Windows 11, perhaps that's a factor.
New delay when when creating a new directory entry
SyncTERM sends noise to speakers after running newest Minesweeeper "graphics"
SyncTERM won't start from Windows File Explorer
Make the File Locations window wider
Internet-shared syncterm.lst file (password manager)
I'd recommend upgrading to Synchronet v3.20a where the telnet gateway (telgate) module now incorporates a full Telnet (client) proxy. Telnet option requests from the remote server (e.g. Spitfire via netserial) should be ACKed as expected in SBBS v3.20's telgate module.
I'd recommend upgrading to Synchronet v3.20a where the telnet gatway (telgate) module now incorporates a full Telnet (client) proxy. Telnet option requests from the remote server (e.g. Spitfire via netserial) should be ACKed as expected in SBBS v3.20's telgate module.
It's reproducible and after attempting a failed connection, it appears to happen every time.
Lock-up after adding new bbs entry
And the crash (e.g. after failure to connect via SSH): SyncTERM.exe!pthread_mutex_lock(_RTL_CRITICAL_SECTION * mutex) Line 185 C SyncTERM.exe!sftpc_finish(sftp_client_state * state) Line 149 C SyncTERM.exe!ssh_close() Line 1010 C SyncTERM.exe!conn_close() Line 459 C SyncTERM.exe!conn_socket_connect(bbslist * bbs) Line 638 C SyncTERM.exe!ssh_connect(bbslist * bbs) Line 738 C mutex = 0x01366c44 {DebugInfo=0x0139f358 {Type=0x0000 CreatorBackTraceIndex=0x0100 CriticalSection=0x00000000 <null> ...} ...}</null>...
Locks up after failing to SSH-authentication with SYSPASS
BTW, running msvc build of current git, I see this infinite loop when disconnecting via SSH under these conditions: SyncTERM.exe!sftpc_finish(sftp_client_state * state) Line 167 C SyncTERM.exe!ssh_close() Line 1010 C SyncTERM.exe!conn_close() Line 459 C SyncTERM.exe!doterm(bbslist * bbs) Line 4164 C This is the loop: while (state->running) { pthread_mutex_unlock(&state->mtx); SLEEP(1); pthread_mutex_lock(&state->mtx); }