Problems with mouse customization
In the mouse customization menu, I tried to set some commands for Shift-Click and Ctrl-Click. For exemplae I would like to have "Line" for Shift-Click Right Button and "Move" for Ctrl-Click Right Button. It works very well with Ctrl-Click Right Button, but when I Shift-Click-Right-Button, instead of the line command I got the Snap menu (same as the snap menu when I use the Middle Button). When I tried to associate the move, line or any other command to Ctrl-Click Middle Button or Shift-Click Middle Button, it doesn't work either. Instead, I'm stick with some sort of 3D Rotate.
To solved the problem, I tried to Disable Shortcut Menu, but nothing changed.
So I can configure the Ctrl-Right-Button-Click but I have no effect on the other Mouse Click Configuration. Is there something I can do?
Comments
-
Not to my knowledge.
V13 partly overrides user configuration with hard-coded bindings (which I consider a regression).
I filed a SR, but so far did not get an indication if this is to be corrected in the near future.0 -
Jean,The following system variables can interfere with your customised shortcuts.CTRLMOUSEMBUTTONPANSHORTCUTMENUSThere is a description on what each does at the bottom of the _SETTINGS dialogue. It would appear that any mouse key shortcuts in the BricsCAD default.cui will take precedence over ones defined in a partial cui.Some mice need configuration via the windows control panel to work correctly, such as setting the wheel button action to = middle button.You could try Autohotkey to configure more exotic key + mouse combos not provided for within the CUI, such as Windows + Left Shift + Right Mouse.Not that it seems and issue in this case, but selecting _3DCONTEXT will automatically change some system variables. Turns on the Quad cursor, changes grid and snap settings.@Knut can you confirm which sequences you see as being hard-coded?Regards,
Jason Bourhill
0 -
I don't encounter this problem. Maybe something is wrong with your partial cui?It would appear that any mouse key shortcuts in the BricsCAD default.cui will take precedence over ones defined in a partial cui.0 -
Hello all,
I have been pushing for comprehensive mouse configurability for quite a while now...
so if others want to jump in, here are parts of my SR (without answers from Bricsys, since I don't know if it would be correct to post them).
Comments would be very welcome.
@ Jason: I keep my mouse customization in a partial menu, and did not experience problems with that.
2011-10-06 16:17 UTC
to be a bit more specific about what bugs me with the current solution:
- at the moment, you only have the choice between hardcoded real-time view control (via CTRLMOUSE and MBUTTONPAN) and own functions defined in (which is already underdocumented for a while), but no way to map the realtime functions to mouse buttons as you like. The inability to configure the mouse bindings to match other applications I regularly work with is quite a nuisance for me. In V11, I at least had the possibility to switch between the real time stuff (for 3d work) and my own bindings in the .cui file (for 2d work) via CTRLMOUSE, but the shift-middle-mouse view rotation in V12 is not affected by this variable, and functions only if shift-middle-mouse is not bound to another function in the .cui (that's what I meant with 'mess').
The solution that I would like best is as follows:
- The left button should also be configurable in the .cui (this would beak compatibility with ACAD, but nobody will want to exchange .cui files with ACAD anyway...)
- The object selection functions would need names that can be put in the .cui, e.g SELECT_ENTITY, SELECT_SUBENTITY, CYCLE_SELECT, TOGGLE_SELECT, UNSELECT
- All the rt* commands (plus the window zoom) would need a 'dynamic' version that supports drag and release (first point taken from pointer position when button gets pressed, second when button gets released), e.g. DRTROT, DRTPAN, so that that the functionality now in CTRLMOUSE and MBUTTONPAN gets available via the .cui
- CTRLMOUSE might still be useful to override the settings in the cui with standard values
- MBUTTONPAN would be obsolete
2011-10-07 07:54 UTC
Just some small additions:
If the left mouse button actions would be defined in the third entry, compatibility would not really suffer.
Still, I don't expect this to come through, so here is a more modest proposal:
Real time rotation (shift-middle) should again be controlled by CTRLMOUSE, but real time zoom (shift-control-left) should not - this one should rather be remapped to shift-control-middle and controlled by MBUTTONPAN.
This way, all merely 3d-relevant functionality would be controlled by CTRLMOUSE (so could be turned off for 2d-work), while the 2d-relevant functionality (that is likely always wanted) would be controlled by MBUTTONPAN. Of course, both variables had to override entries in the .cui. Since realtime zoom is already bound to the mousewheel, this mapping would also be more intuitive.
2012-11-30 13:06 UTC
What sense does it make to give the user a GUI to map functions to mouse buttons, and then override these settings with built-in bindings that you cannot deactivate, as it is currently (in v13) the case with SHIFT-RMB=snapmenu and CTRL-MMB=rtlook?
In the absence of a more encompassing solution, I think there are only two quick but reasonably clean ways to go (I know I'm repeating myself):
either 1.)
- have all hard-coded bindings controlled either by MBUTTONPAN or by CTRLMOUSE, and let these take priority over the .cui when activated
- In order not to loose the real-time zoom (currently SHIFT-CTRL-LMB) when disabling the otherwise purely 3d-relevant functionality by turning off CTRLMOUSE, it should be remapped (or mapped additionally) to SHIFT-CTRL-MMB, controlled by MBUTTONPAN
or 2.)
- give all bindings in the .cui priority (as it is currently only the case with SHIFT-MMB), which would make MBUTTONPAN and CTRLMOUSE obsolete - the built-in functions would act as fallback for key combinations not defined in the .cui0 -
Oops, overlooked some less and greater characters, should read like this:
...you only have the choice between hardcoded real-time view control (via CTRLMOUSE and MBUTTONPAN) and own functions defined in <MOUSEBUTTONROOT>...
If the left mouse button actions would be defined in the third <ButtonItem> entry,...0 -
Hi,
thanlks for the answer. I checked with the MBUTTONPAN, CTRLMOUSE and SHORTCUTMENU variables, but they are all the same on my colleague's PCs and they are able to set correctly all their mouse buttons: Ctrl+RMB = "Line", Ctrl+MMB = "Circle", Shift+RMB = "Copy", Shift+MMB = "Move". It works very well.
They are using 13.1.18 version in English
On my computer, I tried Shift+MMB (wich I haven't try before) and it works. So I can set a tool for Ctrl+RMB and Shift+MMB. The Shift+RMB and Ctrl+MMB aren't configurable. Shift+RMB is stick with OSnapMenu and Ctrl+MMB with 3D_Rotation (I don't need it since I'm only working in 2D).
I'm using the 13.1.12 version in French (maybe there is a difference with the two version for the Mouse-Click, a bug corrected or something like that?)
Also, I'm new in Bricscad and I don't use partial CUI for these configuration (I and my colleagues save all the settings in the default cui). I know it's not the way to work it but we will correct the situation before the next update.
0 -
@ Knut:
You can actually change the SHIFT-RMB and CTRL-MMB actions through the _CUSTOMIZE dialog box. Just right-click on a dashed line and choose 'Insert button'. When you are done you have to delete the dashed line that you have clicked. Not very intuitive, but it works. You can also drag-and-drop tools from the panel on the right onto a dashed line. The lower panel doesn't update. But if you close and reopen the _CUSTOMIZE dialog box you will see that the change has taken effect.
My suggestion for the CTRLMOUSE/MBUTTONPAN/etc. 'situation' from your post #5 would be:
Change the CTRLMOUSE variable to a bit-wise integer, allowing for a more refined control than the current on/off implementation.
MBUTTONPAN can override the new CTRLMOUSE (for compatibility reasons).
customize_mouse.png0 -
@Jean-Francois,
from the "Fixed" section in the V13.1.15 release notes:
SR37814 - SHORTCUTS: it was not possible to assign shortcuts to Ctrl+MiddleMouseButton.
So yes, V13.1.18 includes this fix.
Kind regards,
Hans De Backer0 -
Ok,
thanks Hans for the info. I didn't saw its. I'll wait fair a new French version to see if it solved the problem.
Does someone know why it takes so long to have a new French version (many langages are in .16 or higher version)?
Is it the same every year?
0 -
Hi all,
so it looks reasonable behaviour has indeed been restored with 13.1.18 on windows - too bad that 13.1.19 on linux did not benefit from this, but at least this means that I'll probably just have to wait...
@Roy:
Do you mean a bitcode that would allow to choose which modifier/button combination gets overridden with built-in functionality? So perhaps:
0 = no overrides, cui takes precedence on all buttons
1 = mmb cui overridden by built-ins
2 = rmb cui overridden by built-ins
4 = shift mmb cui overridden by built-ins
8 = shift rmb cui overridden by built-ins
16 = ctrl mmb cui overridden by built-ins
32 = ctrl rmb cui overridden by built-ins
64 = shift-ctrl mmb cui overridden by built-ins
128 = shift-ctrl rmb cui overridden by built-ins
I could certainly live with that, but given the fact that v13 is beginning to make use of the alt-modifier as well, I'm not sure it would be a future-proof solution. So my preference would still be to have everything defined in the cui - most flexible, and getting rid of two vars (ctrlmouse and mbuttonpan) would not be a bad thing, after all...0
