[us-commits] [ehb54/ultrascan3] cc2321: Add a sas gui_script command, and stop a scripted ...
emre brookes
noreply at github.com
Mon Sep 14 14:15:54 MDT 2026
Branch: refs/heads/ehb54-issue-1050
Home: https://github.com/ehb54/ultrascan3
Commit: cc232183dd51b9543bde775d399382acc9e1f6f7
https://github.com/ehb54/ultrascan3/commit/cc232183dd51b9543bde775d399382acc9e1f6f7
Author: ehb54 <brookes at uthscsa.edu>
Date: 2026-09-06 (Sun, 06 Sep 2026)
Changed paths:
M us_somo/develop/include/us_hydrodyn_saxs.h
M us_somo/develop/src/us_hydrodyn_saxs.cpp
M us_somo/develop/src/us_hydrodyn_saxs_pr.cpp
M us_somo/develop/src/us_hydrodyn_script.cpp
Log Message:
-----------
Add a sas gui_script command, and stop a scripted P(r) load hanging
Nothing in gui_script could drive the SAS window. saxs_options exists, but it
operates on the main window's computation options, so no script could open the
SAS Functions window or load a curve into it. That also left the P(r) error
repair added for ehb54/ultrascan-tickets#1049 reachable only by hand: under
gui_script or batch, check_pr_error() cannot prompt, so it always fell back to
dropping every error value.
Adds a "sas" command block, following the existing "dad" pattern:
sas open
sas pr_errors remove | minimum | <positive value>
sas load_pr <file> [<file> ...]
sas pr_errors sets what check_pr_error() applies when it cannot ask. The default
stays "remove", so scripts written before the repair existed are unaffected.
Named sas rather than saxs: the window titles itself "SAS Functions", the script
layer's own error strings already call it the SAS window, it handles SANS as well
as SAXS, and saxs would read as a sibling of the unrelated saxs_options.
load_pr() is a private slot and US_Hydrodyn is not a friend of US_Hydrodyn_Saxs,
so this goes through small public script_load_pr() / script_set_pr_errors() entry
points, the same shape as US_Hydrodyn_Dad::script_load(). load_pr() is silent when
a file will not open, so the readability checks live in the wrapper where the
script can be told what went wrong.
Two supporting fixes this turned up:
- editor_msg() only reaches the GUI text window, so a scripted run applied the
policy and reported nothing. check_pr_error() now routes its messages through a
reporter that also writes to QTextStream( stdout ) when there is nobody at the
keyboard.
- get_mw() answers an unknown molecular weight by opening a modal dialog inside a
"while ( mw <= 0.0 )" loop. Under gui_script nobody can close it, so any scripted
P(r) load hung forever in QDialog::exec(). It now reports and returns "none"
instead; plot_one_pr() already treats -1 as none and turns normalisation off.
This is pre-existing and would have hit any sas command that plots.
Verified headless against the built binary: a clean 143 point file loads with no
report; the same file with the first line's SD zeroed reports "1 of 143 points
have a zero or negative error value, at r = 0", which is only reachable if that
first line's error is now stored; a file with one missing column and one zero SD
reports both r values and then honours remove, minimum and an explicit value; and
an invalid pr_errors argument fails the script with rc 255.
Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>
Commit: e6a6899d829db4488a30b01d3e540251b6aa8141
https://github.com/ehb54/ultrascan3/commit/e6a6899d829db4488a30b01d3e540251b6aa8141
Author: emre brookes <ehb54 at users.noreply.github.com>
Date: 2026-09-14 (Mon, 14 Sep 2026)
Changed paths:
M us_somo/develop/include/us_hydrodyn_saxs.h
M us_somo/develop/src/us_hydrodyn_saxs.cpp
M us_somo/develop/src/us_hydrodyn_saxs_pr.cpp
M us_somo/develop/src/us_hydrodyn_script.cpp
Log Message:
-----------
Merge pull request #553 from ehb54/ehb54-issue-1053
Add a sas gui_script command to drive the SAS window and script the P(r) error policy
Compare: https://github.com/ehb54/ultrascan3/compare/1b77e0299620...e6a6899d829d
To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications
More information about the us-commits
mailing list