Hi,
I use a Logitech K800 and, when in DOpus (11.8), the physical key used to start calc.exe doesn't work.
When I open the Keyboard Map editor in DOpus and press the key in the filter filed, it is wrongly mapped to/noticed as "Alt" instead of just letting it fall through back to the OS.
I tried the key in other apps (SlickEdit, PyCharm) and there, the key is just handled by the OS and calc.exe launced.
Would be great if there's a chance someone looks into this.
Which keyboard drivers are you using?
FWIW this works OK using stock Windows drivers, as well as Microsoft Intellitype drivers.
Logitech's drivers might be doing something weird, but I know they also have several different drivers depending on the type of hardware. Do you know which you're using?
I've built a competely new system just a few weeks ago, installed Windows 8.1 and just plugged in the USB receiver for the keyboard. I haven't installed anything from Logitech (neither just a driver nor Setpoint etc.).
In the device manager the keyboard is listed as HID-Tastatur (German for Keyboard) and the driver from Microsoft, Version 6.3.9600.16384 winblue_rtm.130821-1623)
It works as expected when I'm in any other window of Opus, f.i. preferences, the about dialog etc but not when I'm in a listerview (or any subsections such as the preview, find etc. panel)
Could this be your problem?
My K800 has worked just fine in all recent flavours of Windows.
SetPoint exists to make things like the calculator key work. If you don't install SetPoint, then the PC doesn't know what to do when you hit that key.
It sounds as if you haven't installed Logitech drivers either, although I'm not sure that I understand what you mean by "neither just a driver".
When properly installed, the K800 appears in Windows 7 (many Windows 8 installation is playing up at the moment) as a Logitech HID-compliant Unifying keyboard. Looking at the details of the drivers, it uses a mix of two Microsoft and two Logitech drivers.
I know that there are some people who are allergic to installing SetPoint. That is their choice. But by not doing so they have to live with the consequences.
You could confirm that SetPoint is required simply by installing it, seeing of that key works as expected, and then removing SetPoint in the knowledge that this behaviour has nothing to do with Opus.
Having looked into this more, I think it is a quirk of not having drivers installed on the keyboard. Either it's changed or I was mistaken about it working without drivers here (or there's some extra interaction caused by me having IntelliType drivers on my real machine, and testing without drivers in a virtual machine... but I'm getting the same results in the VM as you are, while everything works fine on the real machine). (Another possibility is it's a quirk specific to the stock drivers in Windows 8, since I've not seen the problem on my Windows 7 machine, but can see it in a the Windows 8 virtual machine.)
So installing the drivers for your keyboard is probably the best option.
This problem does not just affect Opus. If you create a shortcut on your desktop, then right-click it and open Properties, and select the Shortcut key field, pushing the calculator button there will insert Ctrl + Alt + F into the field, even though it has nothing to do with the calculator key (and Ctrl + Alt + F typed manually does not open calculator).
Whatever is going on seems to depend on how the active window responds to keyboard messages, and goes wrong with things that inspect them in certain ways. The proper keyboard drivers do a better job, at least with my Microsoft keyboard & IntelliType drivers (renamed Microsoft Mouse and Keyboard Center these days).
Well, I'm a Opus/GPsoft user and customer since 2003 (ignoring the Amiga) and I never had this issue on neither Vista nor Win 7 (I'm not sure I had a keyboard with calculator keys when still using XP) and, given the key actually works and opens the calc.exe when on the desktop as well as within every other application I tried just to verify it (Visual Studio, PyCharm, SlickEdit, Unity, Netbeans, SublimeText, BeyondCompare, Excel, Outlook, Chrome, chances are, I could test quite some more) I'd at least say, there's quite a chance, that Opus, at some point, does something every other app doesn't do and it seems it shouldn't do it, the way it does.
In addition, in the past I had supported misbehaviour for some special keys to DOpus with a Logitech keyboard which, back then, was looked into by Greg Perry (well at least he was the one I was in touch after writing a support ticket) and it got fixed. But that's quite a few years back 
[quote]This problem does not just affect Opus. If you create a shortcut on your desktop, then right-click it and open Properties, and select the Shortcut key field, pushing the calculator button there will insert Ctrl + Alt + F into the field, even though it has nothing to do with the calculator key (and Ctrl + Alt + F typed manually does not open calculator).
[/quote]
Given no other app even traps this key and it works for everything I'd say chances are much higher, the shortcut hotkey input field also wrongly tries to catch the key and find a name for it, instead of just give it back to the DefWindowProc or whatever it's named these days (it's been a while since I did some native windows programming).
Of course SetPoint might just hook even lowre into the OS and simply catch the key before Opus even has a chance to catch it, but that's hiding the symptoms, not fixing the issue which might cause other problems down the road too.
Is there a chance to get technical support from a developer instead of just trying to find workarounds?
You are getting technical support from a developer. He is called Leo.
But it is hard to see why anyone should bust a gut to fix something in an "incomplete" system. After all, this issue doesn't seem to affect other people who use Opus and the K800.
Have you approached Logitech to see if they can advise on using this keyboard without SetPoint. I think I know the answer they will give – I hang out on their support forum, which rarely sees visits from the company's developers – but a direct approach to their support people might elicit something other than "install SetPoint".
Luckily I found an old USB export of an older version of Opus (9.x) from my previous PC, using this version everything works like a charm - so why does this work then?
Sorry didn't know Leo was a developer (could've looked into the Credits, my fault).
I don't try to get Logitech support for this case, because it's not a Logitech issue - and also, as this forum shows, smaller companies do care much more about their customers. I simply try to avoid unneccessary installations such as SetPoint because this typicall results in a much better working and more stable system. Few years ago I had issues with some other Software in combination with Logitechs Software - sadly I can't remember the details, but it wasn't very obvious and I only solved it because I stumbled upon a posting that hinted me about the issue.
Still thanks a lot Leo, for giving support even on weekends ... if I'll find some time, I may give it a quick look by myself, but it's been easily 10 years since I've only worked on mobile devices so my Windows dev skills are quite rusty these days 
Leo, you can verify that this probably has nothing to do with the issue by testing other special keys. All of them, f.i. the Mediaplayer keys for play/forward/backward etc. result in STRG + ALT + [uppercase character] in that dialog but all of them work perfect when pressed in DirOpus.
I did a small test app and collected just a few infos ... maybe it helps if there's any interest to dig some deeper.
When I press the key in my message handler (WndProc) I get a WM_APPCOMMAND message, the message to handle special keys as defined here msdn.microsoft.com/en-us/library ... 75(v=vs.85.aspx
With this message I get an lParam = 1179648
Encoded in this value is the actual cmd, extracted using
int cmd = GET_APPCOMMAND_LPARAM(lParam);
results in 18 / 0x12 which is defined as APPCOMMAND_LAUNCH_APP2 which very probably is simply calc.exe.
Interestingly ... the virtual keycode VK_MENU is 0x12 and the one I get with a WM_SYSKEYDOWN handler and is the Alt key.
Calc.exe only launches, when I feed back the message and it's parameters into DefWindowProc.
Of course I don't know how Opus implements it's message pump (would be interested to learn about it) but there's probably at least a chance that somehow there's a message like WM_APPCOMMAND that's catched but not forwarded to the DefWindowProc and/or it get's accidently masked/modified in some cases/this case.
I think we've found the cause and the key should work as expected (with or without extra drivers) in the next update.
Glad to see the issue is fixed in the newest release - thx.