UPDATE 2:

By following the programme workflow with more attention, I think I found the
source of the conflict. It is the function
MuseScore::enableInputToolBar(...) (file mscore/musescore.cpp, line 4149 and
following).

This function is called in two points to unconditionally enable/disable all
the (actions behind the) buttons of the input tool bar, regardless of their
state definitions. The reason for this calls escapes me, as the individual
actions are already enabled/disabled by MuseScore::changeState(...)
according to their respective state definitions.

In fact, a test with the whole code of MuseScore::enableInputToolBar(...)
commented out solved the shortcut conflict and showed the input tool bar
buttons correctly enabled/disabled.

Question:
Is there a reason for keeping this function?

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Help-with-shorcuts-tp7577975p7577980.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Reply via email to