[PR #1125] [MERGED] Removes 'key translation' when getting key text #1315

Closed
opened 2026-02-26 09:34:23 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/NickeManarin/ScreenToGif/pull/1125
Author: @jfbueno
Created: 6/22/2022
Status: Merged
Merged: 7/10/2022
Merged by: @NickeManarin

Base: devHead: bugfix/1122


📝 Commits (1)

  • a48e29c Removing 'key translation' when getting key text

📊 Changes

1 file changed (+3 additions, -30 deletions)

View changed files

📝 ScreenToGif.Native/Helpers/Other.cs (+3 -30)

📄 Description

This PR removes the "key translation" that is done when obtaining the key text.

I guess this translation was needed because -1 was considered an invalid result from the ToUnicode API (in the GetCharFromKey method). However, this result represents dead keys - which looks like the root of the problem here - and should be considered valid. It says that a dead key was pressed and the spacing version of that dead key was written to the output buffer, ie it'll write ~ even with just one click (in an ABNT2 Portuguese keyboard).

Here's the section of the documentation that explains the possible results.

This fixes #1122

The problem in this issue is specific to one specific case in this translation tho. The OEM 7 key is a quote in the US standard keyboard layout, but it's translated to a comma.

File: Other.cs

switch (key)
{ 
    case Key.Oem7:
        key = Key.OemComma;
        break;
}

I thought it would be better to fix it to make it work in all keyboard layouts.

I didn't write any unit tests because I couldn't think of any way of doing that without changing the OS keyboard layout.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/NickeManarin/ScreenToGif/pull/1125 **Author:** [@jfbueno](https://github.com/jfbueno) **Created:** 6/22/2022 **Status:** ✅ Merged **Merged:** 7/10/2022 **Merged by:** [@NickeManarin](https://github.com/NickeManarin) **Base:** `dev` ← **Head:** `bugfix/1122` --- ### 📝 Commits (1) - [`a48e29c`](https://github.com/NickeManarin/ScreenToGif/commit/a48e29c7fa398388d7122ce3a103996b72168750) Removing 'key translation' when getting key text ### 📊 Changes **1 file changed** (+3 additions, -30 deletions) <details> <summary>View changed files</summary> 📝 `ScreenToGif.Native/Helpers/Other.cs` (+3 -30) </details> ### 📄 Description This PR removes the "key translation" that is done when obtaining the key text. I guess this translation was needed because `-1` was considered an invalid result from the `ToUnicode` API (in the `GetCharFromKey` method). However, this result represents dead keys - which looks like the root of the problem here - and should be considered valid. It says that a dead key was pressed and the spacing version of that dead key was written to the output buffer, ie it'll write `~` even with just one click (in an ABNT2 Portuguese keyboard). [Here's the section of the documentation that explains the possible results](https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-tounicode#return-value). This fixes #1122 The problem in this issue is specific to one specific case in this translation tho. The OEM 7 key is a quote in the US standard keyboard layout, but it's translated to a comma. _File: Other.cs_ ```csharp switch (key) { case Key.Oem7: key = Key.OemComma; break; } ``` I thought it would be better to fix it to make it work in all keyboard layouts. I didn't write any unit tests because I couldn't think of any way of doing that without changing the OS keyboard layout. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-02-26 09:34:23 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ScreenToGif#1315
No description provided.