Mouse middle button - unwanted multiply temporaty tracking point
When I assign to the Shift, Ctrl and Shift + Ctrl and the middle mouse button shortcut any command that requires selecting a point on the screen, running a command via a mouse shortcut causes the _TK (multiple temporary tracking points) command to be added before selecting the point. This behavior of the program makes using such commands with the middle mouse button meaningless.
The command assigned to the shortcut is executed, but the indication of the first point is preceded by _TK.
Needless to say, I got used to the layout of mouse shortcuts over the years and I don't understand how you could mess it up.
Version 21.2.05 (x64) revision c77687b2
Comments
-
aaaa
-
aaaa
-
Very unlikely that it could help,
but the last Bricscad version is 21.2.06.I was also not very lucky to try any changes in Customization to any Mouse Buttons
in the past and did not try any further.
I use the default behavior, which is for me :
MMB = Pan View
MMB + SHIFT = 3D Rotate ViewNot sure if that is hard coded or deactivate able in Settings or in Customization.
-
In theory, the CTRLMOUSE variable should govern if hard-coded defaults or the customizations done in the .cui/.mnu files will take precedence, but Bricsys did not fully adhere to their self declared standards - they introduced hard-coded bindings that bypass CTRLMOUSE - apart from the walk-through functionality this also comprises the temporary tracking (_TK) command bound to a short middle mouse click.
I guess the more people complain, the more likely it gets they will consider readjusting this mess... -
Hello all,
There is a temporary setting CTRLMBUTTON which disables that _TK is triggered by pressing the middle mouse button. It was introduced in anticipation of the possibility to fully configure mouse buttons, we didn't add it to the Settings dialog, so you need to type it in the command line to change a value to 0.
-
Thanks, Serban, this comes as a real relief (probably to many, if they just knew about it).
Still, I would repeat a little rant from quite exactly 10 years ago (SR 31464):
Please, throw away this convoluted mess of CTRLMOUSE, MBUTTONPAN, SHORTCUTMENU and MouseButtonRoot (now add: CTRLMBUTTON), where it's completely unclear which should take precedence, and go for a sane and simple solution where ALL mouse related behavior (also for the left button) gets configured in ONE place (a Mouse tab in the customization dialog) and is written to the .cui file.
Howdy, Stranger!