Repository navigation
Do away with the need to use indexing on user response functions #177
Description
This may be more involved than it sounds.
Refer to ui_gui_qt.py
def _topic_UI_req_choices(self, msg, q, choices, target, attempts=5):
"""
This can be replaced anywhere in the project that needs to implement the user driver
Temporarily a simple input function.
The result needs to be put in the queue with the first part of the tuple as 'Exception' or 'Result' and the
second part is the exception object or response object
This needs to be compatible with forced exit. Look to user action for how it handles a forced exit
...
The requirement for the item to be put in the queue as a Tuple with Exception or Result as the first element is the thing that drives the necessity to do things in test scripts like this relay_open = user_yes_no("Confirm the relay is open. (DMM not buzzing)")[1]
The same is done in the cmd_line.py, where _user_choices has the same docsctring. Understanding why this was thought (or is) necessary and/or whether it actually requires this format would be good. I'd like to dig in because I'm interested but can't right now.
Metadata
Metadata
Assignees
Labels
No labels
Activity
jcollins1983 commentedon Aug 11, 2024
_user_req_choicesinui.pyis the mechanism used byuser_yes_noanduser_retry_abort_fail._user_req_choiceslooks after the messaging between the actual UI with the topic ofUI_req_choices.In
cmd_line.pythe listener is_user_choicesand inui_gui_qt.pythe listener is_topic_UI_req_choices.Both have identical logic, where a loop iterates until the user selects a valid choice. In the gui the user has no option other than to select a valid choice, so the message put on the queue will always be
("Result", ret_val).In the command line, it is possible to enter an invalid choice, however when the number of retries is exceeded (default for
user_yes_nois 1) the returned value is only the string"Exception".For some reason the UserInputError exception object is not ending up in the queue.
And, when called by
user_retry_abort_failwhen the number of attempts are exceeded a different error is encountered.I'll come back to this soon.
clint-lawrence commentedon Aug 11, 2024
It's kind of horrendous that this has remained unfixed for so long. And that it was ever like this in the first place
jcollins1983 commentedon Aug 12, 2024
The cause of the weirdness around the
"Exception"logic is a couple of missing brackets. It seems thatQueue.put()will accept more than one argument but will only put the first one on the queue.The offending line
This is why I was only seeing
"Exception"as the response, and why a different exception occurs in theuser_retry_abort_failcall.In exceptional circumstances the response being returned was a single value, which can't be unpacked.
In any case, the
"Exception"logic isn't used by the sequencer (regardless of whether it puts a tuple on the queue or not).statusis ignored and the exception is not checked for. If in the command line an invalid entry is madeattemptstimes this is implicitly interpreted as a"FAIL", if a test failed or"ERROR", if an error occurred like Keyboard interrupt etc., sinceUserInputError(...) == "RETRY|ERROR"->False,We would get the same behaviour with just putting something like
"BAD_VALUE"or anything that isn't a valid choice on the queue, assuming we want to continue to support the command line, because this really is a non-event in the GUI.This change would require every script to be updated to move away from the common
_, resp = user_yes_no(),resp = user_yes_no()[1]patterns.I have a local branch ready to push we're keen.
daniel-montanari commentedon Aug 14, 2024
So entering 0 into user_input_float actually fails due to the gui converting the result to boolean.
Also happens in the cli due to the same conversion.
clint-lawrence commentedon Aug 14, 2024
Could you create an issue for that?
daniel-montanari commentedon Aug 14, 2024
Raised in #213
jcollins1983 commentedon Jul 14, 2026
This has been fixed with #214 which has now been merged.