I have had problems to assign the shortcuts given below to any of my commands ...
SHIFT + Num0..9
SHIFT + ALT + Num0..9
CTRL + SHIFT + Num0..9
CTRL + SHIFT + ALT + Num0..9
Hmm, it looks like any combination with Shift isn't a valid combination, regarding the Shift part, which seems to be ignored.
Yes, but all the NumKeys having other modifiers are already assigned here. Thus I need to go with the SHIFT based but I can't.
Not sure, if you're using Opus 11, but in that case you could make shortcuts like Ctrl-Num1,1 or Ctrl-Num2,2 & so on, giving you plenty of
new combinations.
I don't think this has anything to do with Opus; it is a Windows / keyboard thing.
If you hold shift and push one of the numpad numbers, Windows responds as if you pushed the same key (without shift) with NumLock turned off.
e.g.
Shift + NumPad 8 = Up Arrow
Shift + NumPad 9 = Page Up
You'll see the same when assigning hotkeys. Push Shift + NumPad 8 and you get "Up Arrow" in the hotkey field.
This is the same throughout Windows and not something Opus is doing.
With our switch over to DOpus 11.4 I took the time to reorganize my shortcut layout. Thus I tried to re-assign all my alias based folders to use the keypad 0..9 (CTRL modifier for storing the current path and CTRL + SHIFT for restoring). Dynamically setting and loading folders by alias commands is a fantastic feature. 
Actually we use the keypad combos with all modifiers in our RCP based Eclipse applications. I had a short look to the key handlers and in fact the keyCode changes for NumKey1 when holding SHIFT modifier but the keyLocation points always to the numpad. Thus we were able to provide all combinations of modifiers to use as shortcuts with the numkeys in our applications, because the NumKeys are still clearly identifiable.
I wrote an event handler to dump the incoming events (output given below). I would really appreciate if you additionally check the keyLocation to allow SHIFT based shortcuts as well.
KEYPRESS DETECTED: End
KeyEvent{keyCode=16777224 keyLocation=0 stateMask=0}
KEYPRESS DETECTED: Shift + End
KeyEvent{keyCode=16777224 keyLocation=0 stateMask=131072}
KEYPRESS DETECTED: Shift + Alt + End
KeyEvent{keyCode=16777224 keyLocation=0 stateMask=196608}
KEYPRESS DETECTED: Shift + Alt + Ctrl + End
KeyEvent{keyCode=16777224 keyLocation=0 stateMask=458752}
KEYPRESS DETECTED: Num1
KeyEvent{keyCode=16777265 keyLocation=2 stateMask=0}
KEYPRESS DETECTED: Shift + Num1
KeyEvent{keyCode=16777224 keyLocation=2 stateMask=0}
KEYPRESS DETECTED: Shift + Alt + Num1
KeyEvent{keyCode=16777224 keyLocation=2 stateMask=65536}
KEYPRESS DETECTED: Shift + Alt + Ctrl + Num1
KeyEvent{keyCode=16777224 keyLocation=2 stateMask=327680}Can you already say how likely it is, that you translate these "wrong" events coming from Windows to let the user make use of SHIFT + NumKey combos within DOpus?
Don't think I want to be annoying, I just need to decide how to proceed.
I have spent up to three days in fully revising my DOpus configuration with the expectation in mind that I can move all my favorite folder hotkeys to CTRL+SHIFT+NumKey. Now I am stucked in the end of the process because of this strange Windows event provision. I just need to decide whether I need to rethink my whole configuration or if I just have to wait for any of the next upcoming beta versions (obviously the latter would make me much more happy).
PS: We have a little transformer in the beginning of our event queue that simply substitutes incoming events based on a given event translation map. All these "wrong" SHIFT + NumKey events are added to the map, thus finally our event handling code doesn't need to be aware of these "wrong" events. Instead the "wrong" events are simply corrected (replaced) before they are handled.
Changing this would break the standard behaviour other people may expect, so we are unlikely to change it.
I was going to suggest that macro software could intercept your keystrokes and pass them on to whatever you wanted, but the software I use, Macro Express, also deprives you of these Masonic handshakes, probably for the reasons that Leo has outlined, Windows.
Sorry that I have not yet fully understood.
If you just "correct" these SHIFT+KeyNum events if they are actually bound to a command, the default behaviour wouldn't break? Or am I wrong?
Isn't it comparable to the handling of f.e. the cursor keys?
By default when pressing the cursor keys you will get the standard behaviour but on the other hand you are still able to re-bind the cursor keys to any command you like (overriding the standard behaviour). In other words if the user doesn't re-assign the KeyNums everything performs as expected and the standard behaviour wouldn't break.
From my point of view it is just a question of how to uniquely identify the SHIFT-KeyNum combos (in case they are actually used as command shortcuts).
PS: Since I've spent so many effort (with all your assistance) to re-configure our DOpus configuration you would make me really happy if you find an easy way to differ the SHIFT+KeyNums from the other navigation keys.
+1 for to get CTRL+SHIFT working for the numkeys.
I already tried to assign various image transformation commands to the CTRL+SHIFT+Num1-9 because it's lightning fast to have rotating and scaling in any direction to your right hand.
I have to manage a lot of pictures on a daily manner and all these command are prepared to be assigned to the numpad. 
Image ROTATE=90 REPLACE HERE PRESERVEDATE
Image ROTATE=180 REPLACE HERE PRESERVEDATE
Image ROTATE=-90 REPLACE HERE PRESERVEDATE
[...]
Image WIDTH=800 HEIGHT=600 PRESERVEASPECTRATIO NOENLARGE QUALITY=90 NOLOSSLESS ADDSUFFIX=" [scaled]" HERE
Image WIDTH=1024 HEIGHT=768 PRESERVEASPECTRATIO NOENLARGE QUALITY=90 NOLOSSLESS ADDSUFFIX=" [scaled]" HERE
Image WIDTH=1600 HEIGHT=1200 PRESERVEASPECTRATIO NOENLARGE QUALITY=90 NOLOSSLESS ADDSUFFIX=" [scaled]" HERE
[...]So you want DO to break Windows?
Is that a good idea?
What exactly would be broken?
Usually, the developers decide what kind of action will be performed when the user presses a certain key. DOpus follows the standard behaviour for the control keys (e.g. the cursor keys are used to move the focus). But on the other hand DOpus still allows the user to re-define nearly all possible shortcuts. If a user prefer to launch programs by the cursor keys, then this is strange but not prohibited and certainly not dangerous.
This discussion starts with the assumption that the events (that are sent by Windows) for Shift+NumKeys are apparently identical with the events for the navigation keys. But this is obviously wrong (as AKA-Mythos has shown), since the Shift+NumKeys events can be easily differ from the navigation keys because the key-location refers to the numpad. Accordingly there is no reason that prevents the DOpus team (apart from effort and priority) from making these shortcuts available also.
Since the numkeys will only behave different than standard if the user explicitly re-define them, I don't see any problem at all.
Quite the contrary, DOpus makes heavy use of many shortcuts. Thus it would be an enormous gain to get another 40 (!) possible key combinations when Jon and Leo decide to handle the key-location for the numpad events as well by having a look to the key-location event field.
Personally I hope that it is just a small extension and we will see this soon.
Leo, at first you said that is unlikely to change the current handling based on the assumption that the Shift+Numkey events can not be differ from the navigation keys. But now it seems to be possible that these Shift+Numkey combos can be uniquely identified, thus the prerequisites has changed a little.
Can you please come back to this topic?
As you might know we have spent a lot of hours to find a new configuration respecting all the requirements and wishes of our team and now I'm hesitating to throw major parts of that away and to start from the late beginning.
PS: I would not ask if it would not be very important to us. The update process is almost complete here, so I'll let you alone for another year soon! 
I guess that you agree that having 40 extra shortcut options would be nice.
Just for anybody who is curious how we need to use the NumKeys. Assigning the following commands to all NumKeys-0..9 will bring you a convenient mechanism to quickly store and restore of folder bookmarks as well as of lister formats.
Bookmarking of folders:
Ctrl+Num1
Favorites ADD=alias NAME=AliasNum1
Ctrl+Shift+Num1
Go /AliasNum1Bookmarking of listers:
Ctrl+Alt+Num1
Go TABGROUPSAVE "!both,GroupNum1"
Ctrl+Shift+Alt+Num1
Go TABGROUPLOAD "GroupNum1" TABCLOSEALL=yesSince any member of our team has different folders needed for quick access, providing such a dynamic bookmark mechanism (for on-the-fly maintaining listers and folders) using the numpad would be the most flexible solution.
We probably won't be doing this, as I've already said.
Lots of other keyboard combinations exist.
Ok, then I start thinking about some remapping now. Probably I will drop the on-the-fly tabgroup management. I guess except me it isn't used that much in our team.