[us-commits] [ehb54/ultrascan3] cc2321: Add a sas gui_script command, and stop a scripted ...

[emre brookes]

  Branch: refs/heads/ehb54-issue-1053
  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>



To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications