View Single Post
Old 12-23-2019, 05:55 PM   #83
Mister L
Groupie
Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.Mister L is the 'tall, dark, handsome stranger' all the fortune-tellers are referring to.
 
Posts: 179
Karma: 91148
Join Date: Jun 2010
Device: Sony 350
Quote:
Originally Posted by KevinH View Post
MisterL

would you try using the right Ctrl key instead of the left Ctrl Key when you try to set that shortcut and let me know if it makes a difference?

I found a Qt note that says the Windows keyboard mapper code for some keyboardmaps will interpret a left Ctrl followed by a right Alt (or Menu) key as you using the AltGr key instead.

I was hoping to avoid that by you trying to set the shortcut only with the right Ctrl key andnot the left one to see if that impacts things.
I just tried it, both left and right CTRL keys give me the same (wrong) result, BUT, I tested with ALT GR and it registered CTRL + ALT + *, so apparently in some situations it does recognise the key, maybe?


Quote:
Originally Posted by KevinH View Post
Found it. It was related to the fast tab closing fix. The current code works if you make the tab you are about to close, the current tab first. It assumes the closing of a tab always forces a new tab to become current.

This is of course is not what happens in this case at all.

So we need to change the logic to handle the case where the tab being closed is the current tab, and the case where the tab being closed is not the current tab meaning no tab switch is needed and therefore no break and make of signal connections.

I have a fix that seems to work in this case but it may break the fast close of tabs. I really need to sleep on this change and run more tests in the morning to see if it causes the old bug to return.

If not I will commit it.

Thank you to everyone who helped report the bug, figured out how to recreate it consistently, reported the platforms it failed on, etc. Without your help I don't think we would have been able to find the bug so quickly!
Amazing. Glad you were able to find it so quickly, sorry I was not able to provide any logs (still don't know why that is not working for me :/ but I guess it doesn't matter now).
Mister L is offline   Reply With Quote