@mouser: You say/ask:
There isn't currently a way to get that info from CHS; can you explain a use case where you would want to be able to tell whether CHS is enabled or disabled from AHK?
_______________________
-mouser
Before you posted that you had put the "reverse toggle" in, I was puzzling over how to do what
@tomos was basically asking for, but using AHK rather than build it in to CHS:
...a hotkey that would copy selected but not save it in the CHS database. Not sure how, or if, that could be implemented. ...
_______________________
-tomos
I saw it as a puzzle rather than a "use case".
When you posted that you had made the "reverse toggle", I saw what you had done as a nifty way of getting around the need to determine the current state, that went about 80% of the way there, in a situation where the current state was not easily known, but it could only be one of two possible complex states.
Your "reverse toggle" thus was actually quite a simple (logical) workaround, because it made use of the fact that the current state could only be one of 2 options, without actually knowing what they were, but it still left the question unanswered in my mind as to how one
might be able to find the current state - e.g., like in this potentially extremely useful bit of AHK code for a toggle to make a selected window topmost, and then reverse that when the user wants, but where the current OnTop state is not known by the user:
_________________________
^>+T:: ; Ctrl+RightShift+T - OnTop - TOGGLE FUNCTION
WinGetTitle,title,A ; this code cribbed from MilesAhead (DonationCoder) TopMost Toggle script.
WinSet,Topmost,Toggle,A ; toggle TopMost state
WinGet, ExStyle, ExStyle, A ; DLLCALL to tell if window AlwaysOnTop
if (ExStyle & 0x8) ; 0x8 is WS_EX_TOPMOST.
tiptext := "Topmost ON"
else
tiptext := "Topmost OFF"
ToolTip,%tiptext%
Sleep, 500
ToolTip
Return
_________________________
The
DLLCALL to tell if window AlwaysOnTop is the thing. It enables an appropriate ToolTip to be output which
tells the user precisely what the OnTop state is now (after toggling), rather than him/her having to recall what the initial state was and figure out (deduce) what it must be by now. This is called "visible feedback". No feedback or invisible/not perceived feedback is asking for trouble.
That's the trouble with toggles - whether in cockpit instrumentation or a computer window display - the ideal ergonomic objective is that the user is (must be) assured with good ergonomic
feedback as to
what the state is after the toggle has been used. So there would be less or no ambiguity/uncertainty about the matter. In a cockpit, it could be a matter of life-or-death. In a computer proggy like CHS, it would help the user to avoid absent-mindedly (that would be me) making the wrong deduction about what the toggle state is/was (or not even realising that anything had changed by using the toggle), and (say) inadvertently saving a load of confidential data to the clip database because they had forgotten or simply did not know/realise that they had changed the toggle or what the blasted toggle state was.
My benchmark is "Will this be something that me and my kids could use/understand, without confusion?", so I thought that, if I were wanting to make a CHS toggle that they could use/understand, then it would be a mandatory requirement for it to provide the appropriate visible feedback in the same/similar way as the OnTop toggle.
The toggle you provided is something that
I might be able to use correctly sometimes (though perhaps not when absent-minded if lost in thought), but probably not my
kids.
Hence my Q to you: "Would it be possible for CHS to broadcast the state that has been toggled?"
I wasn't asking for you to do anything about it, as, for all I know, the state might be able to be subtly deduced from some conditions that I was unaware of. Looks like the answer is a "No", anyway. Pity. Never mind.
Recent Posts
:
