When using Manual Measure, and clicking on a color in a Preset List, I find the automatic displaying of that patch to be counterproductive, especially when trying to manage heat issues with HDR. I take a set of measurements, and then spend time clicking around on the various colors and graphs, examining data, before deciding what change to make next. During that analysis, I don't want clicking on colors to cause them to be displayed; I just want Black, or the Stabilisation patch, to be displayed. I only want a real patch to be displayed when a measurement is actively being taken. Having to toggle the patch generator off and on to avoid the automatic display is cumbersome. A preference setting to disable the automatic display would be very useful.

It would be nice, if a vote would be possible for a WIBINI. I am sure this one would be very popular.
A specific patch should be configured for this intent: you need to balance between keeping your display warm and not ruining it.

Keyboard Shortcuts [ & ] added to Enable/Disable TPG.
Work in Hardware and Manual Measure menus.

Steve

A permanent setting to just disable automatic display would be much better.

Sorry, I have no idea what you mean.
If the TPG is set to off, it is off until you turn it on again...

Steve

The shortcuts are a programmer's "solution" to the problem, not a UI/workflow designer's solution. It still requires constantly disabling and re-enabling the TPG, which is both a distraction from the real task and an opportunity for error, particularly in not remembering to re-enable. A permanent setting that only causes a patch to be displayed when a measurement is actively being taken, eliminates the extra keystrokes, the distraction, and the opportunity for error.

Ah - no!
The added additional delay introduced would cause issues for users that just want to disable momentarily for undefined durations.
What you are now asking for is very different, and is not something we intend to add at this time.

The solution we have added is most definitely not a 'programmers' solution.

Steve

The request was for a preference setting, not a unilateral change for all users. What I described is exactly what I asked for in the first place.

As it happens, the majority of your initial request defined the operational need.
The final suggestion for a preference was far too specific for the workflow adopted by the majority of users.

The solution we have answeres the actual initial request you made.

Steve

argonaut
Please keep your posting informative, and polite.

Such comments as your last post, now deleted, help no-one.

We do not develop features for individual users - we assess what the majority will benefit from, from a range of feedback we receive - not from a single user's request.

Others users had made requests that overlapped with your request. The development result is as you see.

Steve