[Script] KeypressOSD - Display key press on screen

[robodesign]

but in v3.80, do they work?

@burque505:

http://marius.sucan.ro/media/files/blog ... -v3-80.ahk

Please test 3.80 and 3.81 with patience and attentively.


Thank you very much.

Best regards, Marius.

[burque505]

Hi Marius,
3.80: The dead keys work sometimes. They will stop working for apparently no reason. I have been able to make them work again by choosing 'Typing mode only' and deselecting 'Insert the dead key symbol in the OSD when typing'. After I do this, the first dead key entry doesn't work (most of the time), but subsequent keystrokes work. If I reselect 'Insert the dead key symbol in the OSD when typing', it will work until the application is closed. When I reopen the application, the dead keys don't work anymore. However, if I deselect 'Insert the dead key symbol in the OSD when typing' once again, it will work. It seems that the dead keys fail randomly, but generally the select/deselect process with the 'Insert the dead key symbol in the OSD when typing' will get it to work, albeit temporarily.
3.81: The behavior is the same.
Note that yesterday I did NOT deselect 'Insert the dead key symbol in the OSD when typing' , which I'm sure is why I couldn't get 3.81 to work with dead keys. It seems that the problem is somehow related to 'Insert the dead key symbol in the OSD when typing' .
Regards,
burque505

[robodesign]

Thank you very much for your report. This is helpful.

I also have a real old PC with Win 7 x64 and I will test this more.

From v3.74 I did not touch the way KeyPress handles dead keys. Only in 3.81 I added a simplistic symbols detection for dead keys on Shift or AltGr. So, the inadequate behavior is "older", not new...

I am currently trying to migrate from AHK_L to AHK_H v1.1 and I'm failing with calling functions from a different thread. I understand it's possible with... threadId.ahkFunction["MyFunc","test"], but I can't get it work .... any ideas? I'd like to find working examples.

Best regards, Marius.

[burque505]

Hi Marius, as I recall I had no problems at all with 3.75, by the way.
I haven't used threads with AHK_H v1.1, but that's the version of AHK I usually use unless I have a script that won't run.
You probably know this already, but if not, try Evilc's great AHK-EXE-Swapper for really fast and convenient switching versions.
Regards,
burque505

[robodesign]

Hello, burque!

Thank you very much for the link.

Yes, I recall that too. A few pages ago you wrote it works well. Buuuut.... I checked with WinMerge [to compare changes] and nothing about dead keys was *touched*..... It's exactly the same way, that is dead keys are handled identically between 3.74 - 3.80. Please test again v3.75.

http://marius.sucan.ro/media/files/blog ... -v3-75.ahk

The main AHK file was updated to v3.82. It's only bug fixes related to typing, the caret and OSD; better optimized calculations... now it's faster, with a more fluid behaviour on old PCs.

Best regards, Marius.

[burque505]

Hi Marius,
Just tested 3.75 again. For quite a while it works great when I uncheck 'Monitor keyboard layout'. I'm pretty sure that's the setup I had the other day, also. When I check 'Monitor keyboard layout' again (still 3.75), still work. I must not have done that before. Then,when I minimize Notepad and reopen it, the dead keys quit working again. But if I uncheck 'Monitor keyboard layout' everything works again.
Regards,
burque505

[robodesign]

Hello, burque!

Thanks again, a lot.... for your patience and feedback.

Based on your feedback, I made some changes to how dead keys are handled. Please test the latest version [via update]. The latest version is 3.82.5.

If the dead keys still don't work always, please activate "Do not bind dead keys" from "Typing mode" window and see if they always work.

I have the dead keys working on every and each system I tested, regardless of the settings...

Thanks a lot.

Best regards, Marius.

[burque505]

Hi Marius, for me the dead keys work in Spanish if I activate 'Do not bind dead keys' from 'Typing mode.' They do not work if that option is not activated. Win7, 64-bit, AMD screen drivers (I doubt that makes a difference).
Regards,
burque505

[robodesign]

Okay.... Thank you very much! The only things I changed in recent versions are related to the responsiveness of the OSD. I made it faster.... Anyways, I am glad the dead keys work with that option activated...

I finished migrating to AHK_H v1.1... I am happy with this progress .

Download AHK file. Do not use the Update now option.
http://marius.sucan.ro/media/files/blog ... d-ahkH.ahk

Two new files should be downloaded automatically:
keypress-mouse-functions.ahk
keypress-beeperz-functions.ahk

[If drugwash and burque confirm the release is functional. I will return to the old link. Thank you.]

by Marius Sucan (robodesign.ro)

v3.85 (2017-12-21)
- Autohotkey_H v1.1 migration complete.
- 3 threads are running:
- the main one of the OSD,
- 2nd: mouse features [if activated]
- 3rd is for the beepers.
These features were noticeably stalling the main thread when activated. This is why I migrated to AHK_H. Now, everything is running smoother, even on slower PCs.

- [new] option in tray menu "Silent mode" - deactivates all sounds
- [new] option to have a distinctive beep for toggle keys: caps, num and scroll lock
- removed option "beep keys even if hidden"

Best regards, Marius.

[Drugwash]

On my computer AHK_H scripts have the ah1u extension (for Unicode version). Since there's clearly an incompatibility between all these AHK versions the idea of separate extensions is not only welcome but needed. I once built a script for registering different AHK extensions but nobody gave a rat's arse. Whatever. This is getting out of hand. If you want speed then go to C or maybe ASM.

[robodesign]

Please keep me in mind, I learned to code with this project. This is my "hello world" project. I am content with its speed, now with multi-threading. Yet, it can still be even better..

Did you test it? Does it work? Thanks.

Best regards, Marius.

[Drugwash]

I learned to code in the '90s, by disassembling Z80 games and looking up the mnemonics printed on paper. Unimportant.
What I meant to say was that maybe steering this project out of AHK_L should happen in a new topic so that things wouldn't get mixed more than they already are overall. Maybe someone else would want to pick this version up and take it further while still keeping it with AHK_L.

As for speed, multithreading and so on, really old/slow computers need a very responsive script/application and no version of AHK may cut it, that's why I mentioned C and ASM. I have some of my own scripts that choke on the 9x machine while similar applications in C/C++ perform decently.


I did test the script last night but very briefly, I was tired. It did work. Maybe I'll try again later, now there's Lily sleeping in my lap and I'm typing through OSK as I can't reach the keyboard.

[robodesign]

It would be best to implement such application [like KeyPress] in C/C++. I am well aware of this. It would run muuuuch faster.... anyways....

@burque: any impressions about the new edition/version of the script with AHK_H ?

Best regards, Marius.

[burque505]

Hi Marius, as long as I click on either 'Monitor keyboard layout' or 'Detect keyboard layout' it works most of the time. However, the error displayed below crops up frequently:

2378error.png (59.91 KiB) Viewed 2927 times

I can't pin down what's triggering it, unfortunately.

Regards,
burque505

[Drugwash]

Maybe it's the coordinates set in the Appearance panel. I'm trying to figure it out by setting a tooltip to show the values of x y w h before that line. So far all's fine.
Do you have it toggle the position on hover or is it at a fixed position? If so, which coordinates do you have set for position A and position B?
Better yet, attach your ini file here, it's easier to try and track down the issue.
Can you pinpoint at least vaguely when this may happen? Is it on hover, is it when starting/finishing/in the middle of typing? Which layout does this happen with? Which version of AHK_H are you using (I have 1.1.26.0, so far no crash)?

[EDIT] Upgraded to AHK_H 1.1.26.1 and tested, no crash so far.

[burque505]

keypress-osd.ini

(3.68 KiB) Downloaded 47 times

Hi Dragoș, it seems to happen most often when 1) I change from one window to another or 2) make a change in settings. I am noticing inconsistent behavior from the settings dialog. Just now it failed to show the 'Detect keyboard' option. Then it returned.
It occurs to me, looking at the above, that the height and width coordinates are not integers. Perhaps that's due to the fact that I have scaling set to 125%, I don't know. But perhaps non-integers are not a valid option. My .ini file's attached.
Regards,
burque505

[robodesign]

Hello, guys!

Thank you very much for the report. I know what caused that bug. The width and height are calculated dynamically, so I added now a round() for these. I hope the bug is fixed.

Version now is 3.85.4. This release fixes other bugs as well. Please redownload the file.

http://marius.sucan.ro/media/files/blog ... d-ahkH.ahk

Please let me know if the bug persists or not. And test the dead keys, I made some changes for them, hopefully for the better.

P.S. I use screen scaling too, but did not experience this bug.

Best regards, Marius.

[Drugwash]

Marius, please revise the script, I noticed there's at least one function (from Sean, I guess) where handles and pointers are cast to UInt instead of Ptr and this may lead to unforseeable behavior on x64. This may be one reason for an inconsistent behavior.
I added Ceil() instead of Round() for those coordinates, just to be on the safe side. Better one pixel more than one less.

burque505, thanks for the ini and additional details, I'll try to test myself further sometime today, if possible.

[robodesign]

Please, drugwash, can you change to PTR those vars that need to be as such? I have no idea ^^ ....

[edit] I changed some vars to PTR in that function.... check it again please.

Thank you very much.

Best regards, Marius.

[Drugwash]

Checked v3.85.6.
Line 685, 2736: hkl := DllCall("GetKeyboardLayout", "uint", thread, "ptr") Return value should be UInt not Ptr because it's a DWORD.
Line 268: global InputLocaleID := % DllCall("GetKeyboardLayout", Int,DllCall("GetWindowThreadProcessId", int,WinActive("A"), Int,0)) Both types in GetWindowThreadProcessId() should be Ptr. I'm not sure if the function can return a negative value or not so you may leave the type as Int in GetKeyboardLayout().
Line 2760: perWindowKbLayout := % DllCall("GetKeyboardLayout", Int,DllCall("GetWindowThreadProcessId", int,WinActive("A"), Int,0)) Same as above.
Line 2921: ThisInputLocaleID := % DllCall("GetKeyboardLayout", Int,DllCall("GetWindowThreadProcessId", int,WinActive("A"), Int,0)) Same as above.
Line 3010: NewInputLocaleID := % DllCall("GetKeyboardLayout", Int,DllCall("GetWindowThreadProcessId", int,WinActive("A"), Int,0)) Same as above.
Line 4361:

Code: Select all

EnumFonts() {
    hDC := DllCall("GetDC", "UInt", DllCall("GetDesktopWindow"))
    Callback := RegisterCallback("EnumFontsCallback", "F")
    DllCall("EnumFontFamilies", "UInt", hDC, "UInt", 0, "Ptr", Callback, "UInt", lParam := 0)
    DllCall("ReleaseDC", "UInt", hDC)
}

GetDC() requires a Ptr for input and outputs a Ptr, so it's hDC := DllCall("GetDC", "Ptr", hDesk := DllCall("GetDesktopWindow"), "Ptr") (see below what's with hDesk).
ReleaseDC() takes a Ptr for hWnd and another for hDC so it's DllCall("ReleaseDC", "Ptr", hDesk, "Ptr", hDC).
EnumFontFamilies() requires Ptr for DC handle, Ptr for lpszFamily, Ptr for Callback and not sure whether lParam is pointer-sized in x64 or not, better leave it as UInt, so it'd be DllCall("EnumFontFamilies", "Ptr", hDC, "Ptr", 0, "Ptr", Callback, "UInt", lParam := 0).
Line 2837: hDC := DllCall("GetDC", "Uint", 0) See GetDC() above.
Line 2397: DllCall("ReleaseDC", "Uint", 0, "ptr", hDC) See ReleaseDC() above.
Line 2419: DllCall("GetClientRect", uint, MyGuiHWND := WinExist(), uint, &rect ) GetClientRect() takes a Ptr for hWnd and another Ptr for lpRect, so it's DllCall("GetClientRect", "Ptr", MyGuiHWND := WinExist(), "Ptr", &rect ).

That appears to be all. Please note I haven't checked any structures for correct alignment, that's a more tedious job and I'm extremely tired at this point.
Good luck!