Hi Leo,
I build-ed many buttons and my own layout for Opus. But since I upgraded to version 11.8 from 11.7 I had problem with one Button. I use inside of the Button the Modifier @Keydown. 6 scenario are possible depending if I click the Button while holding different key combination : Scenario 1) @keydown:SHIFT
Scenario 2) @keydown:CTRL
Scenario 3) @keydown:CTRLSHIFT
Scenario 4) @keydown:ALTSHIFT
Scenario 5) @keydown:CTRLALT
Scenario 6) @keydown:CTRLALTSHIFT
Depending on the sequence of key, some codes will be execute without problems. But here an unexpected behavior since upgrading to version 11.8
Scenario 4 and 5 above do not work anymore if I use the keys from the left side of the keyboard. They work only if I use the keys from the right side of the keyboard. I tried with 3 different keyboards thinking that my first keyboard might be defect. But got the same result with the 2 other keyboard. It is very annoying having to hold CTRL+ ALT or ALT+SHIFT from the right side of the keyboard. This was not the case with version 11.7. Also, even if I use the right side, sometime the combination of @keydown:ALTSHIFT work only one out of 3 attempts. It seem something got mixed up.
P.S. (It would be nice that with the @keydown modifier, prefix like (LEFT+ALT or CTRL or Shift or RIGHT+ALT or CTRL or Shift) could be used so there would be more combination like in script.)
Hi Leo,
Because of the complexity of giving you full details of the defect Buttons, I did instead a test that you could reproduce on one of your computer with details of what is happening. What I did was to create a dummy useless Button to replicate the problem, using a Lister with OPUS 11.8 default layout. Now here the code with each result per line of test, using one time, the key from the left and one time the key from the right of the keyboard (Ex: left ALT+mouse click then RIGHT ALT+mouse click. The Button simply use the (@keydown) modifier with all possible combination. If the sequence of KEY pressed + one mouse click on the button are exact, a @confirm message is displayed with the supposed key(s) pressed.
// SCENARIO 1
@keydown:SHIFT
@confirm:SHIFT + (MOUSE CLICK)
//
// Test Result: LEFT keyboard SHIFT Key will trigger the @confirm message of scenario 1 (CORRECT)
// Test Result: RIGHT keyboard SHIFT Key will trigger the @confirm message of scenario 1 (CORRECT)
//
// SCENARIO 2
@keydown:CTRL
@confirm:CTRL + (MOUSE CLICK)
//
// Test Result: LEFT keyboard CONTROL Key will trigger the @confirm message of scenario 2 (CORRECT)
// Test Result: RIGHT keyboard CONTROL Key will trigger the @confirm message of scenario 8 BELOW (NONE)
//
// SCENARIO 3
@keydown:ALT
@confirm:ALT + (MOUSE CLICK)
//
// Test Result: LEFT keyboard ALT Key will trigger the @confirm message of scenario 8 BELOW (NONE)
// Test Result: RIGHT keyboard ALT Key will trigger the @confirm message of scenario 2 above (CTRL ONLY)
//
// SCENARIO 4
@keydown:CTRLSHIFT
@confirm:CTRL+SHIFT + (MOUSE CLICK)
//
// Test Result: LEFT keyboard CONTROL+SHIFT Key will trigger the @confirm message of scenario 4 (CORRECT)
// Test Result: RIGHT keyboard CONTROL+shift Key will trigger the @confirm message of scenario 1 above (SHIFT only)
//
// SCENARIO 5
@keydown:SHIFTALT
@confirm:ALT+SHIFT + (MOUSE CLICK)
//
// Test Result: LEFT keyboard ALT+SHIFT Key will trigger the @confirm message of scenario 1 above (SHIFT only)
// Test Result: RIGHT keyboard ALT+SHIFT Key will trigger the @confirm message of scenario 4 above (CTRLSHIFT)
//
// SCENARIO 6
@keydown:CTRLALT
@confirm:CTRL+ALT + (MOUSE CLICK)
//
// Test Result: LEFT keyboard CTRL+ALT Key will trigger the @confirm message of scenario 2 above (CTRL only)
// Test Result: RIGHT keyboard CTRL+ALT Key will trigger the @confirm message of scenario 6 (CORRECT)
//
// SCENARIO 7
@keydown:CTRLALTSHIFT
@confirm:CTRL+ALT+SHIFT + (MOUSE CLICK)
//
// Test Result: LEFT keyboard CTRL+ALT+SHIFT Key will trigger the @confirm message of scenario 4 above (CTRLSHIFT)
// Test Result: RIGHT keyboard CTRL+ALT+SHIFT Key will trigger the @confirm message of scenario 7 (CORRECT)
//
// SCENARIO 8
@keydown:NONE
@confirm: MOUSE CLICK ONLY (CORRECT)
As you can see, the use of the ALT key seem to be the problem. Before version 11.8, I always used the (CTRL or SHIFT or ALT or any combination from the left side of the keyboards without any problems. The @KEYDOWN modifier was working fine.) Now with version 11.8 I get those result above as showed in this dummy Button. Hope you test it with this simple code above on a dummy Button. I tested this dummy Button using 3 different keyboard and always got the same result as above. If you can't reproduce it as above than, something wrong somewhere else.
Modern Windows keyboards/keymaps do not have a right Alt key.
They have an Alt Gr key on the right, which is equivalent to pushing Ctrl + Alt at once.
I think this explains what you are seeing.
Also, I cannot reproduce your scenario 2 or scenario 4 problems. Is that a mistake in your button comments? All the cases which only involve Shift or Ctrl work the same whether I use the right or left keys.
Hi Leo,
Thanks for taking time to look at it.
Now as regard
I know about ALT GR. I did not bother to mention it in my comment since I knew you will come to that comment yourself. But as you can see in scenario 3 (ALT GR alone (right keymaps) + Click mouse, I get the @confirm message for pushing CTRL only and not CTRL+ALT.
Also as regard
There is no mistake in my comments. Triple check again this morning and got again the same result (Test Result for scenario 2 and 4 above)
But what is really important in the test I did was more about using only the CTRL or SHIFT or ALT or any combination from the left side of the keyboard since, naturally, I always used those key on my left. Let's forget about the test result using the right side as I never used those keys on that side. So if you look at the test result, using only left side control key, for scenario 3 (ALT alone) scenario 5 (SHIFT+ALT) scenario 6 (CTRL+ALT), I do not get the expected result using @KEYDOWN modifier. Could you reproduced those 3 specific scenario with same result as mine?
And as I said before, the LEFT ALT key seem the problem on all my 3 keyboard tested.
On my machine at work I had similar issues iirc, that's why I ran all combinations of your test button now. This is on my home computer currently though, to my surprise all was working fine. I thought modifier issues could be related to the fact, that I have set DO to enter customize mode by pressing ALT and left mouse, so ALT has that special meaning and is interfering with other modifiers.
Will test at work again, maybe I was wrong, but I strongly remember avoiding special keydowns, because they behaved wrong.
Hi TBone,
First of all, Happy Holiday season in advance.
Well I thought about it too as regard ALT in preference for customer mode. I deselect it and still got same result. What puzzle me is that I never had this situation until I up-graded from 11.7 to 11.8 despite that I can't see any change in 11.8 that could cause that problem. There is always the possibility of something wrong with window. I am going to try re-load OPUS 11.7 after uninstalling OPUS 11.8 and see if it all work fine. Then, I will know it is certainly not a window issue.
(Obviously with Preferences / Toolbars / Options / Alt-Click to edit Toolbar buttons turned off, otherwise the scenario involving Alt by itself will edit the button instead.)
Hi Leo,
This is the most strange thing that happened to me.
I have uninstall DO 11.8 and re-install DO 11.7. To my stupefaction, it got worst. Not just with this Dummy Button in this thread but with many other Button. I could only thing about something wrong with window 7 setting. So, I re-install an incremental image of my Hard drive made by Acronis TI enterprise and dated about 2 weeks ago. In this image I had DO 11.7 installed. Once the image loaded, I updated DO 11.7 to 11.8 and everything was working fine. All 8 scenario were working perfectly. No more problem. I am puzzled because between this incremental image made 2 weeks ago and today, the only things that changed was to upgrade DO 11.7 to 11.8 but also some update were made by windows automatically. So, I wonder if an update from windows might have been the cause for DO 11.8 to behave strangely or not. I turned off for now Windows Update and will manually update Window one update at the time (for the last 2 weeks) and see if anything wrong happen with DO. But for now I could say that the situation is fixed. Any idea or suggestion from your side? I will keep you post on that in case I find a faulty update which might affect other peoples (or not depending of their PC's configuration).
Depending where the keyboard is made, I guess.[/quote]
Correct; I was wrong earlier. Some (maybe most) US keyboards do have a second Alt key. Most other layouts (including "US International" and most native layouts for other locales) have just one Alt key, and Alt Gr on the right.
The UK keyboards and Wikipedia page on Alt Gr, plus the symptoms* described, confused me a bit there.
(*If the right Alt key is acting like Ctrl+Alt, then it's mapped as an Alt Gr key, as far as Windows is concerned, regardless of what is printed on the key cap.)
Depending where the keyboard is made, I guess.[/quote]
Where the keyboard is sold more likely. They are nearly all made in China for different markets.
Depending where the keyboard is made, I guess.[/quote]
Where the keyboard is sold more likely. They are nearly all made in China for different markets.[/quote]
Yes. It occurred to me after posting that I had slightly misspoken.
Hi Leo,
This is an update to that thread started by me. I finally found what caused the problem in the first place on one specific computer as mentioned above. I have a French version of Microsoft OFFICE with an English menu package installed. (This allow me to switch ALL Menu from OFFICE to English or French). My Office and language package are x64 version. On this computer I have 2 layout keyboard installed (one in French and One in English). I can switch from layout using Windows Keyboards setting in Control Panel. I had set-up CTRL+SHIFT to switch between US_FRENCH Language and Left ALT + Shift to switch the keyboard layout from US to French (back and forth). But what really caused the problem was an update from Microsoft. My English language menu package for my French OFFICE was upgraded by a service pack 2 but it was an x32 version, not a x64 version. Something got messed-up. Don't ask me to explain why I got those result as mentioned at the beginning of this thread. But after re-installing Office and the right patches while still keeping CTRL+SHIFT and LEFT ALT+SHIFT for switching keyboard layout and language, everything work fine with OPUS whit ALT,CTRL and any combination using those 2 key.
