|
|
Post by Stefan on Oct 24, 2023 9:06:44 GMT -5
George,
I may be remembering this incorrectly, or it may be a 'new effect'?
Running v3.0.23267 or later (but I don't know about earlier)
My profiles are locked to prevent unintended changes. It seems that, with a locked profile, replies to any profile query command are more verbose than they used to be, for example:
AUTOCAPS ? now returns message AUTOCAPS is set to ON in this session, Un-saved, Profile is LOCKED If the profile is unlocked, the reply accurate and more concise: AUTOCAPS is set to ON, saved in the Profile
It is the 'Un-saved' part that is unnerving.
The setting isn't 'unsaved'. It was set and correctly saved BEFORE the profile was locked. No attempt was made since loading the file to change the AUTOCAPS setting. The concept of 'un-saved' only applies if, since loading the file, the user issued an 'override' to the value stored in the profile.
Is this a side-effect of the various profile overrides which were recently introduced? |
|
|
|
Post by George on Oct 24, 2023 9:51:45 GMT -5
Stefan: Probably because, like most of those commands, the last part of the mesage is added by a common routine depending on the LOCK status. Feel free to suggest two alternate endings that work after "is set to XXX". And still convey the needed info.
George
|
|
|
|
Post by Stefan on Oct 24, 2023 10:41:55 GMT -5
George,
In response to a query request (e.g. AUTOCAPS ?), it seems to me that the 'Un-saved, Profile is LOCKED' bit is irrelevant UNLESS (1) the user has overidden/changed the value held in the profile since the time the file was loaded AND (2) the profile is locked so that change was not 'saved'.
Both (1) AND (2) must apply, in order for the 'Un-saved' bit to make sense/be true. I leave you to decide whether to add the 'profile is locked' part to the message as well.
When a 'query' command is used, I'd expect something like EITHER AUTOCAPS is set to ON, saved in the Profile OR AUTOCAPS is set to ON, in this session, profile is LOCKED
The latter implies that the current 'value' is temporary.
When a user issues a command to override/change a profile setting, they are informed of the LOCKED status and temporary nature of the change by a similar such message, which, in case of a locked profile, includes the 'Un-saved' part. That makes perfect sense in the context of a requested change.
|
|
|
|
Post by Robert on Oct 24, 2023 10:43:42 GMT -5
If I might suggest, change "Un-saved" to "NOT SAVED". I believe that is the idea you are trying to get across.
R
|
|
|
|
Post by Stefan on Oct 24, 2023 10:48:54 GMT -5
R. Thank you - much more succinct than my attempt. Though I do note that the message issued when an override/change is attempted uses the 'in this session' wording.
|
|
|
|
Post by George on Oct 24, 2023 11:34:03 GMT -5
What you guys want would have to restructure the following chain of how these messages get issued. It used to be unique code in each Cmd processor. It would need a lot of code back in each command processor. Most of that has been replaced by calls to generalized support code.
For example:
Profile Cmd 1 Profile Command 2 Profile Command Three Profile Command 4 <-- Primary commands
| | | |
V V V V
___________________________________________________________________________________
| | | |
GetSimpleNum GetRangeNum GetOnOff Unique Cmd Code <-- Parse Cmd, handles toggles,
| | | | and returns a string:
V V V V xxx SET TO yyy
___________________________________________________________________________________ or an Error Msg
|
V
DoProfMsg <-- Decide where Msg goes
|
___________________________________________________________________________________
| Pass Msg to Macro Simply Issue Msg (if error)
V
AddLockPrefix <-- Adds 1 of 3 endings
|
+--- in this session, Un-saved, Profile is EFT LOCKED
|
+--- in this session, Un-saved, Profile is LOCKED
|
+--- saved in the Profile
|
Issue the Message
The problem is, the poor guy at the bottom that adds our problematic string, has no idea whether the initial command was a simple query like AUTOCAPS ? or a real attempt to change it. All it knows is LOCKED or UNLOCKED. So keep that in mind. Altering the text is no problem.
Altering it based on something upstream is not trivial.
George
|
|
|
|
Post by Robert on Oct 24, 2023 12:30:21 GMT -5
George, does the thing Stefan asked for require tailoring the message based on something "upstream" as you describe it? If "NOT SAVED" is more clear than "Un-saved", is there anything more to it than that?
You have weaved a web here, and I am sure I don't understand it all.
R
|
|
|
|
Post by Stefan on Oct 24, 2023 12:37:10 GMT -5
George
Follow the path of least resistance. Don't break your back for what is little more than a cosmetic request. It just isn't worth spending a lot of effort. I agree with Robert - "not saved" is better than "Un-saved"
|
|
|
|
Post by George on Oct 24, 2023 16:03:02 GMT -5
Clarification: The choice of those three appended message formats is ONLY based on the LOCK status. Any knowledge of whether the initial command was a simple ? query, or an attempt to change the value, is not accessible.
So is 'Un-Saved' to be changed to 'Not-Saved' ?
George
|
|
|
|
Post by Stefan on Oct 25, 2023 3:04:37 GMT -5
I've no wish to re-open this, but looking at your flow diagram again with less tired eyes this morning, I wonder.... (and I do mean wonder!)
...if the 2nd row (the one that builds the "xxx SET TO yyy" part of the message) does 'known' if the command was a query or a change-setting request.
If so, it could communicate that down the line within the message - example instead of "xxx SET TO yyy", use "xxx ?SET TO yyy" if it's a query request.
The later part that checks if profile is locked can use the presence or absence of the '?' to determine whether to include 'Un-saved' in the message or not.
Whatever the outcome of that test (locked or not), the '?' is removed from the message before it is handed off to the presentation logic.
|
|
|
|
Post by George on Oct 25, 2023 8:23:16 GMT -5
Stefan: That might work, easier to just prefix the whole message. e.g. ?xxx SET TO yyy"
George
[UPDATE]
OK, that seems to work, check it in the next Beta (version >= 23298)
[/UPDATE
|
|
|
|
Post by Stefan on Oct 26, 2023 5:25:18 GMT -5
Yes - looks ok.
A teeny, tiny, nit-picky, thing...
The message "XXX Set to YYY Profile is LOCKED" could use a comma after the YYY part.
|
|
|
|
Post by George on Oct 26, 2023 11:04:31 GMT -5
Stefan: NP, done.
George
|
|
