digitalmars.D.learn - GtkD slows down visual D keyboard
When debugging under visual D, the keyboard response is slowed down to the extreme. This is a Gtk issue I believe. It only has to do with the keyboard. For example, if I hit F10 to step, it takes the ide about 10 seconds to "respond" and move to the next line... yet the mouse can access stuff instantaneous. I believe Gtk or GtkD is slowing down the keyboard input somehow and for some reason making debugging apps a nightmare since it literally takes about 100 times longer to debug than it should. searching google reveals: https://github.com/Microsoft/vcpkg/issues/4529 https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html "You somehow break keyboard shortcuts during debugging in VS if the application you're debugging is registering a callback with "SetWindowsHookEx" from user32.dll with hook ID "WH_KEYBOARD_LL". Don't call it in debug builds or add "if (!Debugger.IsAttached)" in front of the call to "SetWindowsHookEx" if the debugger is attached before the function is called. This brings debugging with keyboard back to the same speed as with the UI buttons for our application." This seems to be an issue with Gtk. I'm not sure if GtkD can do anything about it. Maybe somehow reroute the keyboard handler(first remove it from the hook then call it manually or reduce the number of calls to it).
Apr 26 2019
On 26-04-2019 10:31, Amex wrote:When debugging under visual D, the keyboard response is slowed down to the extreme. This is a Gtk issue I believe. It only has to do with the keyboard. For example, if I hit F10 to step, it takes the ide about 10 seconds to "respond" and move to the next line... yet the mouse can access stuff instantaneous. I believe Gtk or GtkD is slowing down the keyboard input somehow and for some reason making debugging apps a nightmare since it literally takes about 100 times longer to debug than it should. searching google reveals: https://github.com/Microsoft/vcpkg/issues/4529 https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-key oard-very-slow.html "You somehow break keyboard shortcuts during debugging in VS if the application you're debugging is registering a callback with "SetWindowsHookEx" from user32.dll with hook ID "WH_KEYBOARD_LL". Don't call it in debug builds or add "if (!Debugger.IsAttached)" in front of the call to "SetWindowsHookEx" if the debugger is attached before the function is called. This brings debugging with keyboard back to the same speed as with the UI buttons for our application." This seems to be an issue with Gtk. I'm not sure if GtkD can do anything about it. Maybe somehow reroute the keyboard handler(first remove it from the hook then call it manually or reduce the number of calls to it).I can confirm that gtk call "SetWindowsHookEx" with the "WH_KEYBOARD_LL" ID upon initialization. As far as i can tell it doesn't provide a way to skip this. -- Mike Wey
Apr 26 2019
Amex <Amex gmail.com> On Friday, 26 April 2019 at 14:50:17 UTC, Mike Wey wrote:On 26-04-2019 10:31, Amex wrote:Could you unhook it and manually call it or simply disable it when the app is being debugged? essentially just wrap it with a new hook that selectively calls it. NewHook() { if (notdebugbreak) OldHook } Keyboard input doesn't need to happen to the app while in one is in the debugger so the hook doesn't need to be called. This requires two things: 1. To be able to get the hook of the function and remove it. (this might be hard) 2. Know when in debug mode. This should be somewhat easy since I'm sure Visual Studio sets some flag when broke in to a program. Alternatively one could add a function that forces disabling where one could call it in code that they are debugging(which hopefully doesn't require keyboard input). I rarely am debugging keyboard stuff so I'd just call it at the start of the program and benefit from it... and if I have to do keyboard stuff I'll enable it and suffer... but at least I'll have some control over the problem.When debugging under visual D, the keyboard response is slowed down to the extreme. This is a Gtk issue I believe. It only has to do with the keyboard. For example, if I hit F10 to step, it takes the ide about 10 seconds to "respond" and move to the next line... yet the mouse can access stuff instantaneous. I believe Gtk or GtkD is slowing down the keyboard input somehow and for some reason making debugging apps a nightmare since it literally takes about 100 times longer to debug than it should. searching google reveals: https://github.com/Microsoft/vcpkg/issues/4529 https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html "You somehow break keyboard shortcuts during debugging in VS if the application you're debugging is registering a callback with "SetWindowsHookEx" from user32.dll with hook ID "WH_KEYBOARD_LL". Don't call it in debug builds or add "if (!Debugger.IsAttached)" in front of the call to "SetWindowsHookEx" if the debugger is attached before the function is called. This brings debugging with keyboard back to the same speed as with the UI buttons for our application." This seems to be an issue with Gtk. I'm not sure if GtkD can do anything about it. Maybe somehow reroute the keyboard handler(first remove it from the hook then call it manually or reduce the number of calls to it).I can confirm that gtk call "SetWindowsHookEx" with the "WH_KEYBOARD_LL" ID upon initialization. As far as i can tell it doesn't provide a way to skip this.
Apr 26 2019
On Friday, 26 April 2019 at 14:50:17 UTC, Mike Wey wrote:On 26-04-2019 10:31, Amex wrote:Any news about this? Do you think it can be fixed in some way?When debugging under visual D, the keyboard response is slowed down to the extreme. This is a Gtk issue I believe. It only has to do with the keyboard. For example, if I hit F10 to step, it takes the ide about 10 seconds to "respond" and move to the next line... yet the mouse can access stuff instantaneous. I believe Gtk or GtkD is slowing down the keyboard input somehow and for some reason making debugging apps a nightmare since it literally takes about 100 times longer to debug than it should. searching google reveals: https://github.com/Microsoft/vcpkg/issues/4529 https://developercommunity.visualstudio.com/content/problem/42018/debugging-with-keyboard-very-slow.html "You somehow break keyboard shortcuts during debugging in VS if the application you're debugging is registering a callback with "SetWindowsHookEx" from user32.dll with hook ID "WH_KEYBOARD_LL". Don't call it in debug builds or add "if (!Debugger.IsAttached)" in front of the call to "SetWindowsHookEx" if the debugger is attached before the function is called. This brings debugging with keyboard back to the same speed as with the UI buttons for our application." This seems to be an issue with Gtk. I'm not sure if GtkD can do anything about it. Maybe somehow reroute the keyboard handler(first remove it from the hook then call it manually or reduce the number of calls to it).I can confirm that gtk call "SetWindowsHookEx" with the "WH_KEYBOARD_LL" ID upon initialization. As far as i can tell it doesn't provide a way to skip this.
May 01 2019
A hack: On Tue, 14 May 2019 19:44:01 +0200, Mike Wey wrote:On 14-05-2019 05:10, Alex X wrote:// The following code bypasses GTK windows hooking that causes problems with visual studio debugging(slow keyboard, it is a hack and may not work in general) debug { import core.sys.windows.windows, core.stdc.string; alias HHOOK function(int, HOOKPROC, HINSTANCE, DWORD) SetWindowsHookExAProc; alias HHOOK function(int, HOOKPROC, HINSTANCE, DWORD) SetWindowsHookExWProc; static extern (Windows) HHOOK KBHook(int, HOOKPROC, HINSTANCE, DWORD) { asm { naked; ret; } } DWORD old; auto err = GetLastError(); auto hModule = LoadLibrary("User32.dll"); auto proc = cast(SetWindowsHookExAProc)GetProcAddress(hModule, "SetWindowsHookExA"); err = GetLastError(); VirtualProtect(proc, 40, PAGE_EXECUTE_READWRITE, &old); err = GetLastError(); memcpy(proc, &KBHook, 7); // Cleanup //FreeLibrary(hModule); } The code above is based on the idea from https://github.com/microsoft/Detours I didn't feel like investing the time to integrate it in to my code. The code I've included is a hack that simply bypasses all hooking routines and hence the screwed up keyboard hook. It only works for x64 since ret works to return properly(x86 messages with the stack and requires a bit more code).Any news on this? https://forum.dlang.org/thread/bznpylcjostbrrwzhmst forum.dlang.org It's severely cramping my style ;/Unfortunately no.
May 15 2019