تحديث: يحدث نفس الشيء مع جميع الأرقام عند دمجها مع Alt Gr .

كما تعلم ، من المحتمل أن يكون هذا علي. ربما لا نحصل على vkey بشكل صحيح لمجموعات AltGR في مكان ما في TermControl.cpp ، عندما نحصل على حدث KeyDown.

لا علاقة لـ Kinda ، ولكن ما هو البرنامج الذي استخدمته للحصول على تسجيل باستخدام المفاتيح التي ضغطت عليها في

watermelonpizza لقد استخدمت Carnac لعرض ضغطات المفاتيح و ScreenToGif لالتقاط النافذة.

يا كارناك ، شكرًا رائعًا! سأضيف ذلك إلى قائمة الأشياء الجيدة الخاصة بي :)

أعتقد أن هذه نسخة مكررة من # 487.

عفوًا ، يبدو أن اليد اليسرى لا تعرف ما تفعله اليد اليمنى ، ولقد قمت للتو بإنشاء رابط مكرر دائري.

يمكن تأكيد هذه المشكلة على إصدار Windows 10.0.18362.30 مع تخطيط لوحة المفاتيح المجرية. يختلف السلوك بناءً على وحدة التحكم التي أستخدمها:

• cmd: يقوم فقط بكتابة الحرف ولكن بأحرف كبيرة
• بوويرشيل: لا يفعل شيئًا على الإطلاق
• git bash: لا يكتب أي شيء ، لكنه يصدر صوت تنبيه افتراضي

@ zadjii-msft لقد وجدت تعليقك (؟) على AltGr في terminalInput.cpp .
على لوحة المفاتيح الألمانية ، تكون حالة مفتاح التحكم هي LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED بدلاً من LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED على ما يبدو.
علاوة على ذلك ، فإن المفتاح الظاهري المضغوط هو على سبيل المثال "Q" بدلاً من تحويل بعض رموز يونيكود بالفعل.

وهكذا استبدلت ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
مع...

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

...ويعمل! الى الان. 😅 ستفوض المعالجة إلى WM_CHAR / _CharacterHandler والتي تعتبر وفقًا لـ Google أكثر قوة للتعامل مع AltGr. (؟) (أنا لست على دراية ببرمجة Windows حتى الآن.)
ما رأيك بهذا؟ هل يجب علي تقديم PR؟

lhecker رائع! الآن هذا قابل للاستخدام بالفعل 🎉

lhecker نعم ، يرجى تقديم PR. على لوحات المفاتيح الألمانية ، لا يمكنني إدخال الأنبوب في الوقت الحالي مما يجعل من الصعب استخدام الجهاز الطرفي.

أشعر أن تغييري غير صحيح بالرغم من ذلك. يجب أن يكون هناك سبب لعدم معالجة جميع الأحرف بواسطة WM_CHAR أليس كذلك؟
بسبب ذلك ، أود انتظار ملاحظات @ zadjii-msft أو @ DHowett-MSFT أولاً. أعتقد؟ 😅

السبب الحقيقي في Terminal.cpp

DWORD modifiers = 0
                      | (ctrlPressed? LEFT_CTRL_PRESSED : 0)
                      | (altPressed? LEFT_ALT_PRESSED : 0)
                      | (shiftPressed? SHIFT_PRESSED : 0);

يمكنك أن ترى أن RIGHT_ALT_PRESSED لم يتم اكتشافه بشكل صحيح هنا ، مما يتسبب في إرجاع keyEvent.IsAltGrPressed في TerminalInput :: HandleKey.

راجع للشغل ، يتم الحصول على حالة المعدلات بواسطة _GetPressedModifierKeys () في TermControl :: _ KeyDownHandler (). بدلاً من القيمة المنطقية ، يمكنك تمرير حالة المُعدِّلات مباشرةً إلى SendKeyEvent ، وتحديد ما إذا كان يتم الضغط على مفتاح التبديل الأيمن / الأيسر ، واليمين / اليسار ، واليمين / اليسار لاحقًا.

وهناك بالفعل تعريف على النحو التالي في VirtualKey ، والتي يمكن استخدامها في TermControl :: _ GetPressedModifierKeys ()

        LeftShift = 160,
        RightShift = 161,
        LeftControl = 162,
        RightControl = 163,
        LeftMenu = 164,
        RightMenu = 165,

آه التقاط لطيف @ sagood!
للأسف ، لن يكون إصلاح هذه المشكلة كافيًا بقدر ما أستطيع أن أرى ...
يفترض TerminalInput::HandleKey ما يبدو أنه عند الضغط على AltGr ، فإن نظام التشغيل قد قام بالفعل "بترجمة UnicodeChar مسبقًا إلى القيمة البديلة المناسبة" ، وهذا ليس هو الحال على سبيل المثال AltGr + Q (= @) على لوحة مفاتيح ألمانية.
بمعنى أن المنطق الحالي حول IsAltGrPressed() معيب بالفعل نوعًا ما.

lhecker لقد حاولت استخدام RIGHT_ALT_PRESSED بدلاً من ذلك لتهيئة معدِّلات DWORD. لقد اختبرت AltGr + '+' (= ~) ، سيظهر بشكل صحيح في وحدة التحكم.
AltGr + <(= |) يعمل أيضًا.

ولكن لا يبدو أن AltGr + Q يعمل بالفعل. عجيب.
AltGr + E (= €) لا يعمل أيضًا.

من خلال إعداد c # UWP جديد ، لاحظت أن تسلسل المفاتيح أثناء استخدام AltGr هو كما يلي ،

Menu
Control
Q

(خذ AltGr + Q كمثال)

يظهر المزيد من التصحيح أنه إذا قمت بإجبار البرنامج على تشغيل فرع الشرط الأول من TerminalInput :: HandleKey من terminalInput.cpp كما هو موضح أدناه ،

if (!fKeyHandled)
            {               
                if ((keyEvent.GetVirtualKeyCode() < '0' || keyEvent.GetVirtualKeyCode() > 'Z') &&
                    keyEvent.GetVirtualKeyCode() != VK_CANCEL)
                {
                     // !!!force the AltGr+'Q/E' case to run here, not the one below
                    fKeyHandled = _TranslateDefaultMapping(keyEvent, GetKeyMapping(keyEvent), GetKeyMappingLength(keyEvent));  
                }
                else
                {
                    ...
                }
            }

سيعمل AltGr + Q.

ماذا عن AltGr + ß لـ \ على لوحة المفاتيح الألمانية ، هذا الشخص لديه نفس المشكلة

تتأثر جميع مجموعات لوحة مفاتيح AltGr بنفس المشكلة.

أي تقدم في هذا؟ وكنت قادرا على تكرار السلوك، لكنني لست متأكدا، كيف يجب التعامل مع القضية AltGr في الواقع. في حال كان ذلك مفيدًا ، إليك بعض الأشياء التي نظرت إليها:

• لقد تحققت من أنه على لوحة مفاتيح ألمانية ، تمت ترجمة AltGr بالفعل إلى Left_CTRL && LEFT_ALT ، تم اختباره لـ CMD و PS و WSL
• يبدو أن الخطأ مرتبط باختبارات عدم النجاح. فشلت الاختبارات التالية بالنسبة لي عند التبديل إلى لوحة مفاتيح ألمانية ولكن مررت على لوحة المفاتيح الإنجليزية:
  
  
  
  • InputEngingeTest:C0
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3 يصل إلى set10 ويتضمنها
  
  

lhecker بدافع الفضول ، طبقت فكرتك الأولى لاستبدال isAltGrPressed() بـ isAltPressed() && isCtrlPressed() ، وتحققت من أنها:

• يعمل مع CMD بما في ذلك @ و € ، ولكن ليس في PS أو WSL
• في الواقع لا يصلح الاختبارات غير الناجحة
• ولكن بدلاً من ذلك يكسر MouseInputTest::SgrModeTests#metadataSet20 للوحة المفاتيح الإنجليزية.

على الرغم من أنني لم أذهب بعيدًا في تضييق نطاق المشكلة بشكل أكبر ، فقد اعتقدت أن المعلومات قد تكون مفيدة.

هذا مثير جداMattKuhr. تعمل @ و € في الواقع مع كل من PowerShell و WSL. 🤔
(فقط لأكون متأكدًا بنسبة 100٪ - هذا هو الاختلاف الخاص

إنه بالفعل ، لقد قمت بتحديثه إلى المعلم الحالي واختبرته مرة أخرى. تعمل الآن الأحرف الخاصة ، باستثناء € في PS.

لست متأكدًا من سبب السلوك الذي لاحظته سابقًا ، فقد تم استخدام نفس التغييرات بالضبط في الكود. بدأت أفكر في أنني ربما أفسدت شيئًا ما بالنشر أثناء الاختبار ، على الرغم من أنني اختبرت عدة مرات ، أو أن بعض تحديثات Windows التي تم تثبيتها في الوقت نفسه كان لها تأثير.

هذه لقطة شاشة مع ضبط لوحة المفاتيح الألمانية عند الاختبار على الماستر الحالي:

لقد اختبرت ذلك على كل من Debug و Release (x64) ، Win 10.0.18362.116. حاولت أيضًا تغيير لغة النظام ، ولم يكن لها أي تأثير. يبدو غريباً بعض الشيء ، أنه في هذه الحالة المحددة فقط لا تتم ترجمة € بشكل صحيح ..

لنفترض ، هل يبدأ العمل في PowerShell إذا كنت أول من Remove-Module PSReadline ؟ (لا تقلق: ستؤثر فقط على جلستك الحالية). إذا كان الأمر كذلك ، فلدينا بعض الأفكار!

@ DHowett-MSFT لقد اختبرته مع بناء السحب الرئيسي أمس بدون أي تغييرات على تخطيط لوحة المفاتيح الألمانية في 18362.113 (إعداد اللغة الإنجليزية)

Alt Gr + q => Q ، المتوقع @
Alt Gr + < => < ، المتوقع |
Alt Gr + + => + ، المتوقع ~
Alt Gr + ß => ß ، المتوقع \
Alt Gr + 2 => 2 ، المتوقع ²
Alt Gr + 3 => 3 ، المتوقع ³
Alt Gr + e => E ، المتوقع €

للأحرف العادية ، يعمل Alt Gr مثل shift. يتم ترك أي حرف آخر على القيمة بدون معدل.

@ DHowett-MSFT إنه في الواقع 😃

تستمر المفاتيح الأخرى في العمل. أيضًا ، كان من الممكن كتابة الثلاثة الصغيرة في السابق بالشكل العادي 3 ، والآن تظهر بشكل صحيح ، كما ترون في لقطة الشاشة أدناه.

مرحبا،

فقط هنا لإخبارنا أن هذا يؤثر أيضًا على تخطيط QWERTY الفنلندي ، مما يجعل جميع تركيبات AltGr مثل @ ، | ، {} ، [] ، ~ ، \ إلخ غير قابلة للاستخدام.

يبدو أن كل هؤلاء يعملون بشكل جيد مع التصحيح من lhecker في WSL و cmd وowershell. شكرا لمدقق !

مرحبًا ، إنه يعمل أيضًا مع تخطيط لوحة مفاتيح Azerty الفرنسية. شكرا لمدقق

وجود مشكلة في تركيبات Alt Gr مثل "Alt Gr + <" (شرطة مائلة للخلف ، ولكن ينتج عنها "<") على لوحة مفاتيح ألمانية سويسرية.

لقد قمت بتحديث عنوان هذه المشكلة لجعل الأمر أكثر وضوحًا للمارة فيما يتتبعه.

@ zadjii-msft لقد وجدت تعليقك (؟) AltGr المرتبط في terminalInput.cpp.
وهكذا استبدلت ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
مع...
إذا (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
عودة كاذبة؛
}
...ويعمل! الى الان. 😅

يمنحني هذا التغيير أيضًا AltGr قابل للاستخدام على لوحة المفاتيح الفرنسية. تم الاختبار حتى الآن باستخدام CMD و Windows PowerShell 5.1 و PowerShell Core 6.2.1 (كلاهما مع PSReadline 2.0.0beta4 غير الرسمي الذي يحتاجه المرء للعمل في VScode)

يمنحني هذا التغيير أيضًا AltGr قابل للاستخدام على لوحة المفاتيح الفرنسية. تم الاختبار حتى الآن باستخدام CMD و Windows PowerShell 5.1 و PowerShell Core 6.2.1 (كلاهما مع PSReadline 2.0.0beta4 غير الرسمي الذي يحتاجه المرء للعمل في VScode)

لقد تحققت من إصدار PSReadline الخاص بي وقمت بالترقية من 2.0.0 إلى 2.0.0-beta4 وهذا ما فعلته الحيلة ، والآن يعمل كل من € و بشكل صحيح في PS ، كلاهما 5.1 و 6.2.1. 😄

على الرغم من أنني عثرت على خطأ آخر يبدو أيضًا أنه مرتبط بـ PSReadline ، ولكن ليس بـ AltGr أو تخطيط لوحة المفاتيح مباشرة. كما ترى أدناه ، في Terminal CTRL 2 تتم ترجمته إلى " و CTRL 7 (على تخطيط GER ، في الولايات المتحدة ، يكون CTRL / ) إلى ^_

بالنسبة للحالة الأولى ، تؤدي إزالة PSReadline إلى الحيلة ، أما الحالة الثانية فلا تؤدي إلى ذلك. جربت الرقم الآخر ومفاتيح char الخاصة ، لكن هاتين الحالتين كانتا الوحيدتين اللتين تمكنت من العثور عليهما حتى الآن. السلوك مماثل في 5.1 و 6.2.1. PSReadline هو 2.0.0beta4.

هل يجب أن نفتح قضية منفصلة لهذا؟

أرى أيضًا مشكلات ذات صلة على لوحة مفاتيح برتغالية (البرتغال).
متوقع: يجب أن يحصل Alt Gr + 2/3/4/7/8/9/0 على @ £ § {[]} ، يجب أن يحصل Alt Gr + e على €

محطة Windows:
-PS Core: يؤدي Alt Gr + digit إلى تشغيل وظيفة PSReadline Digit ، باستثناء 7 مخرجات ^ _
-PS Core: Alt Gr + € لا يفعل شيئًا
-Windows Powershell: نفس PS Core
-CMD: Alt Gr + digit يخرج الرقم ، باستثناء 7 مخرجات ^ _
- CMD: مخرجات Alt Gr + e E.

وحدة تحكم مدمجة:
PS Core: Alt Gr + 2/3/4/7/8/9/0 الإخراج @ £ § {[]} ، Alt Gr + E لا يفعل شيئًا
Windows PowerShell: مثل PS Core
CMD - جميع الأعمال

نظام التشغيل Windows 10 1903 18362.116
PS Core 6.2
Windows Terminal 0.1.1431.0
PSReadline 2.0.0

الحل البديل الحقيقي عندما لا تعمل مجموعات مفاتيح "Alt Gr" هو استخدام Alt + NumPad Code .

لكن هذا لا يعمل أيضًا!

657 "Alt + Numpad لا يعمل"

أود أن أنصح أن أي شخص يخاطب هذا الشخص يخاطب هذا الشخص الوثيق الصلة أيضًا.

يمكنني التحقق من ذلك أيضًا بالنسبة للوحة المفاتيح الأيسلندية. نستخدم AltGr لكتابة ما يلي:
@ | € {[]} \ µ ~ `^

مجرد ملاحظة جانبية: تظهر هذه المشكلة في جميع تقنيات سطر أوامر Microsoft تقريبًا. لقد ظهرت بالفعل في OpenSSH ، ظهرت مشكلة مماثلة في PSReadline ، وهنا مرة أخرى ، حيث لا تعمل أي من تركيبات AltGr.

في كل مرة أجرب فيها شيئًا ما في سطر الأوامر ، تظهر مشكلات الإدخال دائمًا. ما زلت لا أستطيع استخدام PowerShell في الجلسات البعيدة ، لأن Home-End لا يعمل ، وما زالوا لا يعملون من خلال SSH.

بطريقة ما ، هذا المثلث الطرفي- SSH-PSReadline ملعون.

أنا هنا أستخدم تخطيط لوحة مفاتيح PT-BR.

للحصول على / استخدم Alt Gr + Q

عند استخدامه في Terminal ، فإنه يعمل مثل أمر التراجع. انها مجرد إعادة كتابة آخر أمر / حرف / كلمة

تضمين التغريدة

حيث لا تعمل أي من تركيبات AltGr.

تقصد أن تقول أن أيا من تركيبات AltGr تعمل؟

لنفترض ، هل يبدأ العمل في PowerShell إذا كنت أول من Remove-Module PSReadline ؟ (لا تقلق: ستؤثر فقط على جلستك الحالية). إذا كان الأمر كذلك ، فلدينا بعض الأفكار!

لا يعمل معي (تخطيط AZERTY الفرنسي)

إذن ..... أي أفكار جديدة؟ لأن الإصلاح ...

سي ++
إذا (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
عودة كاذبة؛
}
...

لم يعمل لي <. <

تعديل:

أليس من الأذكى اكتشاف لغة لوحة المفاتيح الرئيسية ، التي تم تعريفها على الجهاز ، ثم إجراء rebind- stuffmicrosoft ؟

Hedrauta غريب أن تغيير الرمز لا يعمل من أجلك. ما هو تخطيط لوحة المفاتيح الذي تستخدمه؟ ماذا يفعل لك Ctrl+Alt+xxx في CMD العادي لقيم xxx التي يتم استخدامها مع AltGr؟ بقدر ما أتذكر ، يجب أن يكون Ctrl+Alt دائمًا ما يعادل AltGr ...

لذلك ، لجمع بعض بيانات الاختبار: بالنسبة لي ، يبدو أن التصحيح بواسطة lhecker يعمل بشكل جيد. هذا على تخطيط لوحة مفاتيح ألمانية:

المحطة | Alt Gr + ß؟ \ | Strg + Alt + ß؟ \
- | - | -
إرث cmd.exe | \ | \
إرث pwsh.exe | \ | \
Windows Terminal ، master ، cmd.exe | ß | ß
Windows Terminal ، master ، pwsh.exe | _ (لا شيء) _ | _(لا شيئ)_
Windows Terminal، master + تصحيح بواسطة @ checker ، cmd.exe | \ | \
Windows Terminal، master + تصحيح بواسطة @ checker ، pwsh.exe | \ | \

نفس النتيجة كما في https://github.com/microsoft/terminal/issues/521#issuecomment -501148984
مع التصحيح بواسطةlhecker

ولكن في pwsh لا تزال علامة € - لا تعمل على التخطيط الألماني.

كمد:
C:\Users\jkann>2² 3³ 7{ 8[ 9] 0} ß\ +~ <| Q@ E€
pwsh:
PS C:\Users\jkann> 2² 33 7{ 8[ 9] 0} ß\ +~ <| Q@ E

Hedrauta غريب أن تغيير الرمز لا يعمل من أجلك. ما هو تخطيط لوحة المفاتيح الذي تستخدمه؟ ماذا يفعل لك Ctrl+Alt+xxx في CMD العادي لقيم xxx التي يتم استخدامها مع AltGr؟ بقدر ما أتذكر ، يجب أن يكون Ctrl+Alt دائمًا ما يعادل AltGr ...

لم يساعدني أيضًا ...
حتى أنني حاولت أن أجعل الحل الخاص بي بناءً على هذا الرمز ولكن لم يحالفني الحظ حتى الآن ...

أنا أستخدم تخطيط لوحة مفاتيح PT-BR ، جرب المجموعة التالية:

CMD و Powershell و WSL.exe
AltGr + Q = /

عند استخدام Windows Terminal
WSL: AltGr + Q = يعمل مثل أمر التراجع ، فهو يعيد كتابة آخر أحرف مكتوبة.
Powershell ، CMD: ينتج AltGr + Q = هذا الحرف الغريب مثل ^_

تعديل:
للمساعدة في تصور:

يجب أن يكون الإدخال الصحيح
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7 ما الذي تحصل عليه باستخدام CtrlAlt بدلاً من AltGr؟

@ renatop7 ما الذي تحصل عليه باستخدام CtrlAlt بدلاً من AltGr؟

نفس النتيجة

وخارج المحطة الطرفية أي في CMD القياسي أو Windows Powershell أو Powershell Core؟ هل يتصرف CtrlAlt دائمًا مثل AltGr؟

وخارج المحطة الطرفية أي في CMD القياسي أو Windows Powershell أو Powershell Core؟ هل يتصرف CtrlAlt دائمًا مثل AltGr؟

نعم ، خارج المبنى يعمل بشكل مثالي.
باستخدام AltGr أو Ctrl + Alt أحصل على النتيجة المتوقعة.

تم جلبه منذ 15 دقيقة: لا يعمل على الإطلاق
حسنًا ، هل تعمل Microsoft حتى على حل متعلق بهذه المشكلة؟

Hedrauta غريب أن تغيير الرمز لا يعمل من أجلك. ما هو تخطيط لوحة المفاتيح الذي تستخدمه؟ ماذا يفعل لك Ctrl+Alt+xxx في CMD العادي لقيم xxx التي يتم استخدامها مع AltGr؟ بقدر ما أتذكر ، يجب أن يكون Ctrl+Alt دائمًا ما يعادل AltGr ...

Uhm ، معيار ألماني واحد ؟. هنا شاشة من كيف تبدو: https://i.imgur.com/mvgHkxi.png
سأحاول كتابة المفتاح من خلال اختبار ماكرو ....

يشبه ، البديل الأيسر الخاص بي هو Shift ، وليس Alt ...
نتيجة المحاولة
Ctrl + Q ^ Q
CTRL + Alt + QQ
فقط س ف
Alt + QQ

سنحاول gif ، تحديث التعليق بعد ذلك
تحرير: أثناء محاولتي تصويره ، أدركت أن مفتاح Alt الخاص بي تم التعرف عليه بشكل خاطئ .... أي شخص يعرف أين يتم تحديد المفاتيح الافتراضية؟ سوف ننظر في الأمر أيضًا ؛) لكنني لست من ذوي الخبرة في ++ C أو .... أي تشفير ؛)

فقط بالنسبة لي بصفتي cpp noob ، راجعت عدة ملفات ، ووجدت ملف
C: \ Program Files (x86) \ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
إذن .... للتخطيطات الألمانية ، VK_Menu غير موجود ، أليس كذلك؟ نحن فقط نملك VK_LMENU ، أليس كذلك؟
سأحاول إجراء بعض التغييرات وإجراء بعض الاختبارات ... سيتم التعديل في النتائج لاحقًا
تحرير 1: يستغرق البناء وقتًا طويلاً ، مثل إعادة بناء أنظمتي بأكملها
تحرير 2: بعد إنشاء كل شيء ، لا يعمل ... لكنني أدركت أن VK_RMENU هو AltGr ، بينما VK_LMENU هو المفتاح الذي نريد أن نراه مضغوطًا للحصول على @ أو \
لكن يبدو أن VK_MENU يعمل أيضًا ، ولكن قد يتم تعيينه بشكل خاطئ
هذا نوع من إرباكي ، سوف أتحقق من هذا بعد عملية إحضار نظيفة وإعادة البناء وقيلولة

بالنسبة إلى تخطيط لوحة المفاتيح الألمانية ، فالأمر أسوأ ، لأن Alt Gr + Q الذي يجب أن ينتج @ ، يحذف إدخال السطر الحالي.
هذا لا يحدث مع wsl ، ولا أرى أنه مهيأ لـ WT - فكيف يحدث هذا؟

لا تزال مشكلة:
لوحة المفاتيح: البلجيكية (نقطة) AZERTY ، تعمل في الغلاف العادي
وينفر: 18362.175
الإصدار الطرفي: 0.2.1715.0

_ أود أن أطلب من الجميع عدم التعليق على أنهم يتعاملون أيضًا مع هذه المشكلة ._

يجب أن يكون واضحًا للجميع الآن أن هذه المشكلة تؤثر على قدر كبير من تركيبة المفاتيح ويمكن أن تؤدي إلى قدر كبير بنفس القدر من الآثار الجانبية غير المتوقعة ، لعدد متساوٍ من اللغات وإصدار Windows ولوحات المفاتيح وما إلى ذلك.
أكثر من نصف التعليقات من نمط #metoo ، وهذا لا يساعد في إصلاح هذه المشكلة على الإطلاق و
فقط يجعل التعليقات المفيدة أقل وضوحًا .
ما هو مفقود بالفعل وسيكون مفيدًا للغاية هو أن يقوم مطور Windows المطلع بمعالجة هذه المشكلة وإرسال PR.

في غضون ذلك ، قد يشعر كل شخص قادر على تجميع هذا المشروع بحرية استبدال هذا الجزء من الكود: https://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392 -L396

مع هذا الإصلاح التجريبي الخاص بي:

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

يجب أن يعمل هذا على إصلاح معظم مجموعات المفاتيح لمعظم لغات لوحة المفاتيح ، بما في ذلك أحرف مثل @{}[] على لوحة مفاتيح ألمانية (أو ما شابه).

ملاحظة: أنا لست تابعًا لشركة Microsoft بأي شكل من الأشكال ، وأنا أكتب هذا لأنني شخصياً أعتبر أن تعليقات "#metoo" هذه مزعجة / غير منتجة. 🙂
PPS: أنا متأكد من أن البعض يتساءل عن سبب عدم تقديم العلاقات العامة بنفسي. لكي أقتبس من نفسي : "أشعر أن التغيير الذي أجريته غير صحيح. يجب أن يكون هناك سبب لعدم معالجة جميع الأحرف بواسطة WM_CHAR أليس كذلك؟" المعنى لا أعرف في الواقع ما هي الجوانب السلبية للإصلاح أعلاه وكيفية القيام بذلك بشكل صحيح.

PPS: أنا متأكد من أن البعض يتساءل عن سبب عدم تقديم العلاقات العامة بنفسي. لكي أقتبس من نفسي: "أشعر أن التغيير الذي أجريته غير صحيح. يجب أن يكون هناك سبب لعدم معالجة WM_CHAR جميع الأحرف بشكل صحيح؟" المعنى لا أعرف في الواقع ما هي الجوانب السلبية للإصلاح أعلاه وكيفية القيام بذلك بشكل صحيح.

تتمثل إحدى طرق المعرفة في إرسال بيان عام وتصحيحه من قبل الفريق. إنها مبالغة بعض الشيء ، لكنني أعتقد أنها ستجعل الأمور تتحرك بشكل أسرع.

NatoBoram 14 # 1436

لاحظ أنه عند استخدام أمثلة التطبيقات مثل VtPipeTerm ، يعمل مفتاح alt-gr هناك.

HBelusca VtPipeTerm لا يعتمد على محطة UWP الطرفية الجديدة وبالتالي لن تواجه هذه المشكلة.
يمكنك قراءة # 1436 للحصول على تفسير واحد محتمل للمشكلة الأساسية.

lhecker لا يعتمد على Cascadia ، لكنه يستخدم نفس تطبيق pseudoconsole الأساسي ... لذلك من المفيد للغاية معرفة أنه لا ينطبق على جميع مستهلكي pseudoconsole!

شكرا HBelusca

عملت المفاتيح الخاصة لسنوات في الأجهزة الطرفية وتطبيقات Windows. لماذا لدينا هذه المشكلة الآن في 2019؟ هل أعدت تطبيق نظام الإدخال بالكامل لبرنامج Terminal؟ آمل أنه كان من الضروري القيام بذلك وإعادة إدخال الأخطاء التي تم إصلاحها منذ سنوات: s. كانت هذه المشكلة نموذجية في نظام التشغيل Linux بسبب صفحات الرموز وتعيينات لوحة المفاتيح اللغوية والمفاتيح الخاصة بالنوافذ ، ولكن هذا الخطأ الحرج موجود في إصدار المعاينة للتطبيق ، والذي يتوفر في المتجر ويتم نشره في كل مكان

ifilgud إنه إصدار معاينة متاح في المتجر لأسباب تتعلق بالمعاينة . تم فرز هذه المشكلة وهناك أيضًا عرض عام مقدم لها ، لذلك لا داعي للتعليق على هذه المشكلة لمجرد تقديم شكوى.

patriksvensson أعلم أنني كنت أشتكي بشكل أساسي وهذا ليس "مهذبًا" ، لكنني أطلب أيضًا سببًا تقنيًا لشرح سبب خطأ كهذا. كنت أتوقع وجود بعض الأخطاء الطفيفة التي يجب إصلاحها في إصدار شبه مكتمل (معاينة) ، ولكن لا يوجد خطأ لم يكن يجب أن يكون موجودًا في تطور محطة طرفية ، ما لم تكن مكتوبة من البداية وتم اختبارها باللغة الإنجليزية فقط (أعتقد أن هذا هو السبب لا تكتشف هذا في الإصدار ألفا الأول). فتحت المحطة وحاولت كتابة "cd \" كأمر ثان (كان الأول "dir") ، ولكنه لم ينجح. بصفتي مطور برامج ، أثر هذا علي كثيرًا.

lhecker حتى الآن ، جيد جدًا ، بعد تطبيق الإصلاح التجريبي. شكرا جزيلا!!

شكرًا جزيلاً لجميع الأشخاص الذين أشاروا إلى هذا وأصلحوه بالفعل. 🌷

ما مدى تكرار تحديث تطبيق MS Store؟
إذن متى نتوقع إصلاح الأشياء في تطبيق المتاجر؟

أحب العمل مع الجهاز ولكن باستخدام لوحة المفاتيح الألمانية ، لا يمكنك حتى كتابة { } بدون altgr. 😅

حصلت على نفس المشكلة لتخطيط لوحة المفاتيح النرويجية Bokmål (nb-NO) أيضًا. لا يمكن إنشاء [] أو {} أو $. PowerShell مكسور بشكل أساسي بدون هؤلاء.
استخدام الإصدار 0.2.1715.0 من UWP / Microsoft Store على نظام التشغيل Windows 10 1903 18362.175.

تخطيط hu_HU عبر AltGr: \ | & @ $ ; # <> {} [] أعني عدد المرات التي أقوم فيها بفتح الأقواس ، أو الأقواس المربعة أو الزاوية ، أو الخط المائل العكسي ، أو الأنبوب ، أو علامة الدولار ، أو علامة التجزئة ، "عند" ، "و" ، فاصلة منقوطة ... أوه انتظر كل سطر ؟؟ :)

_ أود أن أطلب من الجميع عدم التعليق على أنهم يتعاملون أيضًا مع هذه المشكلة ._

يجب أن يكون واضحًا للجميع الآن أن هذه المشكلة تؤثر على قدر كبير من تركيبة المفاتيح ويمكن أن تؤدي إلى قدر كبير بنفس القدر من الآثار الجانبية غير المتوقعة ، لعدد متساوٍ من اللغات وإصدار Windows ولوحات المفاتيح وما إلى ذلك.
أكثر من نصف التعليقات من نمط #metoo ، وهذا لا يساعد في إصلاح هذه المشكلة على الإطلاق و
_ فقط يجعل التعليقات المفيدة أقل وضوحًا_.

تحديث: يحدث نفس الشيء مع جميع الأرقام عند دمجها مع Alt Gr .

كيف فعلت هذا gif سجل؟

@ كارل - نحن ننظر إلى أسفل في الموضوع.

@ DHowett-MSFT قد يكون فكرة جيدة لقفل هذا الموضوع برسالة في الأسفل

في حين أن الجهاز غير قابل للاستخدام للغاية بالنسبة لـ Powershell أثناء استمرار هذه المشكلة
أرغب في طرح حل بديل لنظام التشغيل Windows 10 1903 لأولئك الذين لا يمكنهم الامتناع حتى يتم إصلاحه ..

الحل:
استخدم مفتاح Windows +.
انتقل إلى علامة تبويب الأحرف الخاصة حدد شخصيتك
قم بالتبديل إلى Terminal وقم بإدخال الحرف

تركها غير مقفلة يمنح الأشخاص مساحة للإبلاغ عن كل مفتاح فردي لا يعمل حتى يتوقفوا عن حفظ قضايا فردية حول كل مفتاح فردي لا يعمل. انا ممزق. انا مشتت.

قد يكون هناك المزيد من الحالات حيث لا تعمل الأحرف الخاصة بالشكل المتوقع. إذا كنت أرغب في إنشاء حرف @ على لوحة مفاتيح دانمركية ، فهناك 3 طرق للقيام بذلك: Alt Gr + 2 أو Left Ctrl + Left Alt + 2 أو Left Alt + Numpad 64
يعطي الخياران الأولان نتيجة OP المبلغ عنها.
الخيار الأخير يفعل في بوويرشيل:
Onpres اليسار Alt + Numpad 64 digit-argument: 64
Alt الأيسر عند الإصدار: 64 @ حرفًا
في كمد
Onpres اليسار Alt + Numpad 64: 64
البديل الأيسر عند الإصدار: @ ينتج عنه 64@
في WSL
Onpres اليسار Alt + Numpad 64: (arg: 64)
Alt الأيسر عند الإصدار: 64 @ حرفًا

نقطة جيدةsaadanerdetbare!

يبدو أن مشكلة Alt + Numpad تنبع من حقيقة أن الوحدة الطرفية الجديدة (Cascadia) ترسل رموز الهروب المناسبة إلى الغلاف عند إدخال هذه الرموز. ولكن في نفس الوقت ، يتعامل جزء آخر من التطبيق مع هذه الحالة ، وترجمة رمز Alt + Numpad إلى حرف مناسب وإدخاله في الغلاف. يؤدي هذا إلى التأثير الجانبي المضحك لتكرار حرف @ 64 مرة (نظرًا لإرسال وحدات البايت التالية إلى الغلاف: \x1b6\x1b4@ ).

يمكنك تجربة ذلك عن طريق إضافة الكود الإضافي التالي بين هذين السطرين :

if (!inEventsToWrite.empty() && static_cast<KeyEvent*>(&*inEventsToWrite.front())->GetCharData() == '\x1b')
{
    return;
}

سيؤدي هذا إلى منع Cascadia من إرسال رموز الهروب هذه إلى الغلاف. بعد ذلك ستظهر شخصياتك (مثل @) بشكل طبيعي.
بدلاً من ذلك ، يمكنك إزالة كتلة التعليمات البرمجية هذه لنفس التأثير.

~ saadanerdetbare سيكون رائعًا جدًا إذا كان بإمكانك إنشاء مشكلة منفصلة توضح بالتفصيل مشكلتك ، نظرًا لأن هذا خطأ لا علاقة له بوظيفة AltGr. 🙂 ~
👉 # 1401
كان ينبغي أن يبحث عن قضايا أخرى أولاً. 🤦‍♂️

ملاحظة: لا بد لي من القول إن رؤية استعداد متزايد من المجتمع لتصحيح هذه الأشياء بأنفسهم بدلاً من الاعتماد على أشخاص غير معروفين سيجعلني شخصياً فخوراً للغاية. 🙈🙂

saadanerdetbare تأجل عن تقديم عدد جديد ، هذا واحد # 1401: ابتسم:

ما زلت أواجه هذا في تطبيق المعاينة ، لدي لوحة مفاتيح بلجيكية ، لا يمكنني كتابة @

solispauwels ، سيتعين عليك الانتظار حتى الإصدار التالي (أو قم ببناء الفرع الرئيسي الحالي بنفسك في الوقت الحالي).

مرحبًا ، لقد اختبرت للتو هذا الالتزام على لوحة مفاتيح ألمانية وكل شيء يعمل بصرف النظر عن altgr-E الذي يجب أن يطبع رمز €. لأكون صريحًا ، لا أحتاج حقًا إلى هذا في محطة طرفية في كثير من الأحيان ولكنني اعتقدت أنني قد أذكرها على أي حال. البعض الآخر مثل altgr-m للعمل بالرغم من ذلك.

تحديث: أعتقد أنه يمكنك تجاهل ذلك ، رمز € لا يعمل في بوويرشيل قياسي إما لذلك لا يبدو أنه خطأ الجهاز ، كان يجب عليك التحقق من ذلك مسبقًا.

يبدو أن كل شيء يعمل هنا على لوحة مفاتيح فرنسية: AltGr+é"'(-è_çà)=$e ينتج عن ~#{[|`\^@]}¤€ المتوقع

أنا أستخدم لوحة مفاتيح فرنسية أيضًا (لكنني في بلجيكا) ، وأواجه مشكلة مع AltGr +الشخصيات. | # {} @ على سبيل المثال لا تعمل. أنا أستخدم أحدث إصدار من متجر windows 0.2.1715.0 على Windows 10 v1903.

meuter سيتعين عليك الانتظار حتى الإصدار التالي (أو إنشاء الفرع الرئيسي الحالي بنفسك في الوقت الحالي).

لم يتم تضمين الإصلاح من # 1436 بعد في إصدار المعاينة المتاح في متجر Microsoft

antoineco @ sba923 شكرًا ، هذا ما كنت

شكرًا للجميع على العمل الجاد على هذا الأمر وملء البريد الوارد بالتقارير. شكرًا على وجه التحديد لـ lhecker لإرسال إصلاح! لقد أرسلناه للتو إلى المتجر مع إصدار الخدمة v0.2.1831.0. قد يستغرق المتجر بعض الوقت لمعالجته.

لقد أرسلناه للتو إلى المتجر

لذا ، من واقع خبرتي في نشر التطبيقات على متجر Windows ، يجب أن يستغرق الأمر من 3 أيام إلى 3 أسابيع

لقد أرسلناه للتو إلى المتجر

لذا ، من واقع خبرتي في نشر التطبيقات على متجر Windows ، يجب أن يستغرق الأمر من 3 أيام إلى 3 أسابيع

أقل من 6 ساعات على ما يبدو. 😋

على أي حال ، يبدو كل شيء على لوحة المفاتيح السويدية على ما يرام الآن. 👍

يعمل مع لوحة المفاتيح الألمانية الآن 👍

يعمل مع لوحة مفاتيح فرنسية بإصدار 0.2.1831.0! شكر

يعمل مع لوحة مفاتيح فرنسية بإصدار 0.2.1831.0! شكر

تم تأكيد!

عمل عظيم!

@ DHowett-MSFT يبدو أن الإصدار v0.2.1831.0 يتضمن هذا الإصلاح ولكن ليس إصلاحات الأخطاء الأخرى مثل خطوط powerline أو نسخ / لصق keybings ، هل هذا طبيعي؟

أؤكد أن Alt-Gr يعمل ، لكن استخدام Ctrl-Alt بدلاً من ذلك للوصول إلى مفاتيح لوحة المفاتيح نفسها لا يعمل بشكل موثوق (إن وجد).

في الإصدار 0.2.1831.0 ، تعمل مجموعات AltGr الآن مع لوحة المفاتيح الفنلندية.

solispauwels ، الإصلاحات الوحيدة في الإصدار 0.2.1831.0 هي تلك المذكورة في ملاحظات الإصدار.

يرجى العلم أن الكثير من نظام التشغيل 1803 أو الأحدث قد يواجه خطأ في إصدار متجر Windows 11905.1001.4.0
سيقوم المتجر "بتكديس" التطبيقات ليتم تنزيلها (راجع الصورة) ولكن لن يقوم بتنزيل التطبيقات ، حتى مع تمكين التنزيل التلقائي والشبكة ليست اتصالاً محدودًا.

يتعين على المستخدمين المتأثرين الضغط على "التحقق من وجود تحديثات" في Microsoft Store للحصول في النهاية على تطبيق متجر ثابت وبدء جميع تنزيلات التطبيقات المعلقة.

أؤكد أن هذه المشكلة سيتم إصلاحها في الإصدار الجديد من Terminal. شكرا جزيلا.

يمكنني أن أؤكد كذلك أن هذا تم إصلاحه الآن. قد ترغب في إزالة المشكلة.

إنه يعمل باستثناء مفتاح اليورو ، وهو AltGr + e ، على الأقل في لوحة المفاتيح الإسبانية. تعمل باقي المجموعات بشكل صحيح

من ifilgud

إنه يعمل باستثناء مفتاح اليورو ، وهو AltGr + e ، على الأقل في لوحة المفاتيح الإسبانية. تعمل باقي المجموعات بشكل صحيح

تم الاختبار على Windows 10 1903 (18362.175) باستخدام أحدث إصدار بتاريخ 2019-07-08 باستخدام لوحة مفاتيح AZERTY "البلجيكية (الفترة)".

نتيجة الفحص:

• جميع التركيبات المتوفرة لدي على لوحة المفاتيح ، بما في
• فقط في "ويندوز بوويرشيل" لا رمز اليورو (€) لا تعمل
  
  
  
  • ومع ذلك ، فإنه لا يعمل في وحدة التحكم PowerShell Classic التي تم إطلاقها مباشرة من Windows Start أيضًا
  
  

Imo هذه مشكلة جديدة تتعلق بـ Windows PowerShell ، وليست خاصة بـ Windows Terminal الذي يستضيف وحدة التحكم هذه.

أؤكد مراقبة DeChrist . من ناحية أخرى ، لا يعمل الضغط على Ctrl-Alt + (مفتاح) كما هو متوقع (إذا أراد المرء استخدام هذه المجموعة بدلاً من AltGr).

هنا على ويندوز 10 بناء 18362.175 تشغيل محطة معاينة Windows الإصدار 0.2.1831.0، مع لوحة المفاتيح الفرنسية، AltGr+E لم تسفر € في كل من قذائف التالية:

• كمد
• Windows PowerShell 5.1
• PowerShell Core 6.2.1
• PowerShell Core 7.0.0-preview.1

هل يمكن لأي شخص لديه مشاكل متبقية من AltGr _ في PowerShell_ التحقق من إصدار PSReadLine الذي يتم تشغيله؟

$psrl = Get-Module PSReadLine $psrl.Version $psrl.PrivateData.PSData['Prerelease']

@sba923 :

PS C:\Users\myself> $psrl = Get-Module PSReadLine
PS C:\Users\myself> $psrl.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      0      -1

PS C:\Users\myself> $psrl.PrivateData.PSData['Prerelease']
beta2

HBelusca هل يمكنك المحاولة من فضلك:

1. تعطيل PSReadLine
2. الترقية إلى أحدث beta4 ، راجع https://github.com/PowerShell/PSReadLine

• نظام التشغيل Windows 10 1903
• Windows Terminal 0.2.1831.0
• PowerShell v7 (الذي يتضمن PSReadline 2.0.0-beta4)
• تخطيط لوحة مفاتيح QWERTZ الألمانية

✅ AltGr + Q → @
✅ AltGr + E → €
❌ Ctrl + Alt + Q → q

هذا أمر محبط بشكل خاص نظرًا لوجود خطأ آخر متعلق بـ mstsc والذي كانت Microsoft تتجاهله لمدة عقد على الأقل حيث توقف AltGr + Q عن العمل إذا كانت جلسة RDP مفتوحة. في هذه الحالات ، لا يزال Ctrl + Alt + Q يعمل ، لذلك يستخدمه الكثير من الناس كحل بديل.

ما يجب أن تفعله Microsoft هو عدم لمس KEYBOARD STREAM.

يجب أن يلتقط shell (explorer.exe) أي ضغطات مفاتيح يحتاجها ويمرر كل شيء آخر في اتجاه مجرى النهر.
يجب أن يلتقط Terminal.exe في النهاية Alt-F4 فقط - وربما حتى ذلك - يجب على explorer.exe حقًا التقاط ذلك وتطبيقه على العملية النشطة.

مما يعني أن Terminal.exe يجب أن يأخذ دفق لوحة المفاتيح فقط ويمرره إلى عملية الطفل النشطة. لا شيء آخر.

يجب أن يعرف CMD.exe [command.com] كيفية التقاط ما يحتاج إليه ثم تمرير الباقي إلى أطفاله.

يجب أن تحصل WSL على أكبر قدر ممكن من المدخلات الأولية. لا تتعامل مع AltGr. Ctrl-Alt و AltGr ليسا نفس تسلسل لوحة المفاتيح. في Linux ، توجد اختصارات باستخدام ctrl-alt -... تنتج نتائج مختلفة عن AltGr -...

لديك فرصة واحدة فقط للقيام بذلك بشكل صحيح. الفرصة الأولى منذ ما يقرب من 40 عامًا. من فضلك ، لا تضيع هذه الفرصة - مايكروسوفت ، أنا أنظر إليك :)

thorsig آه ، إذا كان لدينا فقط عندما تم تصميم مكدس إدخال Win32 منذ أربعين عامًا. للأسف ، لم نفعل ذلك ، لذلك هناك طريقتان أساسيتان لتلقي مدخلات لوحة المفاتيح:

• كأحرف ، بدون معدّلات (لذلك لا يمكننا اكتشاف ALT لإرساله عبر الأنابيب الطرفية) أو اتجاه الضغط على المفاتيح
• كرموز مسح تحتوي على مُعدِّلات واتجاهات ، ولكنها في الحقيقة مجرد تمثيلات لمواقع رئيسية مادية

عندما تبدأ في النظر إلى ما دون مستوى نظام التشغيل ، امسح الرموز _are_ وضع "الإدخال الأولي قدر الإمكان". ومع ذلك ، فإنها تتطلب القليل من الطهي قبل أن يتم نقلها إلى التطبيقات التي تتطلب إدخال نص. (تحرير للإضافة :) تفضل التطبيقات الطرفية حقًا إدخالها كنص. لا يمكننا إرسال رموز المسح الضوئي عبر اتصال SSH! حتى لو استطعنا ، سيحتاج المستلم بعد ذلك _itself_ إلى فهم تخطيط لوحة المفاتيح للقيام بالترجمة. ربما لا تحتوي الأجهزة مقطوعة الرأس على تخطيط لوحة مفاتيح. (/تعديل)

إذا كان الأمر سهلاً مثل "الحصول على الحرف الحرفي الذي ضغطوا عليه وإرساله معهم" ، فعليك أن تثق في أننا سنفعل ذلك بالضبط. نحن لا نصمم حلولاً مجنونة لأننا أناس مجانين! :ابتسامة:

حسنًا ، كنت موجودًا على الرغم من أنني ربما لم يكن لدي الكثير من الأدلة حول كيفية التعامل مع تدفق الإدخال في ذلك الوقت.

ومع ذلك ، يعمل Linux مع رموز المفاتيح الأولية بشكل افتراضي ، لذلك لا توجد مشكلة. ومع ذلك ، فإن مثالك على اتصال ssh معيب ، نظرًا لأن ssh لا يتم تنفيذه مباشرة من قبل التطبيق الطرفي - فهناك غلاف داخلي (أو تجريد كامل لنظام التشغيل مثل WSL) مسؤول عما يصل إلى الغلاف.

إذا كان ما تقوله صحيحًا ، فسيتعين على كل تطبيق تمت كتابته لنظام التشغيل Windows (يعمل على رأس المستكشف) تنفيذ معالجة لوحة المفاتيح الداخلية الخاصة به. لا يفعلون. لأنه يتم الاعتناء به في المنبع والمصب.

لقد نظرت في الكود وحصلت على نصيبي من "SMH". هل يمكنني القيام بذلك بشكل أفضل؟ مع الوقت ، على الأرجح. هل يمكنني تحمل الكراهية حيال ذلك؟ بالنظر إلى أنه ليس لدي الوقت للقيام بذلك بنفسي - ربما لا.

ما زلت أجد أنه من الجدير بالذكر ، أنه يتم هندسته بشكل مفرط كما هو ، وسيؤدي ذلك إلى حدوث مشاكل في المصب في مرحلة ما (ربما عاجلاً وليس آجلاً).

حسنًا ، كنت موجودًا على الرغم من أنني ربما لم يكن لدي الكثير من الأدلة حول كيفية التعامل مع تدفق الإدخال في ذلك الوقت.

ومع ذلك ، يعمل Linux مع رموز المفاتيح الأولية بشكل افتراضي ، لذلك لا توجد مشكلة. ومع ذلك ، فإن مثالك على اتصال ssh معيب ، نظرًا لأن ssh لا يتم تنفيذه مباشرة من قبل التطبيق الطرفي - فهناك غلاف داخلي (أو تجريد كامل لنظام التشغيل مثل WSL) مسؤول عما يصل إلى الغلاف.

لا تقوم WSL بأي نوع معين من الترجمة. يقوم conhost.exe أو Windows Terminal (أو Gnome-terminal إذا قمت بتشغيل تطبيق رسومي من خلال ، على سبيل المثال ، XMing) بالترجمة المناسبة لإرسالها إلى pty. وحتى القشرة ... ليست القشرة نفسها تقوم بمعظم العمل. إنه برنامج التشغيل الطرفي والتطبيق في النهاية الرئيسية (والذي ، مرة أخرى ، إما conhost.exe ، Windows Terminal ، ربما Cygwin Terminal إذا كنت مائلاً ، وتطبيقات Linux الطرفية).

إذا كان ما تقوله صحيحًا ، فسيتعين على كل تطبيق تمت كتابته لنظام التشغيل Windows (يعمل على رأس المستكشف) تنفيذ معالجة لوحة المفاتيح الداخلية الخاصة به. لا يفعلون. لأنه يتم الاعتناء به في المنبع والمصب.

لا تهتم معظم التطبيقات بإدخال لوحة المفاتيح الخام في الواقع. يتم التعامل مع ذلك من خلال بعض مكتبات Win32 بطرق تكون بطبيعتها مع فقدان البيانات. لا يستخدمون مدخلات لوحة المفاتيح الخام مباشرة. تهتم معظم التطبيقات بالشخصيات فقط ، إلى جانب الألعاب التي قد تهتم بإدخال التخطيط المادي بالضبط. في كلتا الحالتين تعمل بشكل جيد.

لقد نظرت في الكود وحصلت على نصيبي من "SMH". هل يمكنني القيام بذلك بشكل أفضل؟ مع الوقت ، على الأرجح. هل يمكنني تحمل الكراهية حيال ذلك؟ بالنظر إلى أنه ليس لدي الوقت للقيام بذلك بنفسي - ربما لا.

ما زلت أجد أنه من الجدير بالذكر ، أنه يتم هندسته بشكل مفرط كما هو ، وسيؤدي ذلك إلى حدوث مشاكل في المصب في مرحلة ما (ربما عاجلاً وليس آجلاً).

أقترح عليك النظر في Gnome-Terminal ، نظير Linux ، والتحقق مما إذا كان أبسط أو أكثر تعقيدًا. أظن أنه أكثر تعقيدًا لأن X هو في الواقع أغرب من GDI32 أو أي واجهة برمجة تطبيقات نافذة قيد الاستخدام.

هل هناك انحدار من 0.2.1831.0 ؟
على لوحة المفاتيح الدنماركية ، لا يستجيب Windows Terminal Preview v0.3.2142.0 لـ AltGr.

Windows Terminal (معاينة)
الإصدار: 0.3.2142.0
Microsoft Windows 1903 [الإصدار 10.0.18362.267]

لدي لوحة مفاتيح دانمركية و v0.3.2142.0 Windows build 10.0.18362.239 إنه نظام تشغيل إنجليزي بدون أي حزم لغوية. تعمل أحرف Alt Gr الخاصة هنا ، بينما لا يعمل تسلسل Ctrl + Alt

لدي لوحة مفاتيح دانمركية و v0.3.2142.0 Windows build 10.0.18362.239 إنه نظام تشغيل إنجليزي بدون أي حزم لغات. تعمل أحرف Alt Gr الخاصة هنا ، بينما لا يعمل تسلسل Ctrl + Alt

نظام التشغيل الخاص بي: Win10 Home 1903 Build 10.0.18362.267
نظام التشغيل الدنماركي مع حزمة لغة أمريكية إضافية مثبتة على الرغم من أن حزمة اللغة الدنماركية هي الافتراضية.
هم - بناء 10.0.18362.267 مقابل 10.0.18362.239 - هل هناك دليل هناك؟ !!!

نظام التشغيل الخاص بي: Win10 Home 1903 Build 10.0.18362.267
نظام التشغيل الدنماركي مع حزمة لغة أمريكية إضافية مثبتة على الرغم من أن حزمة اللغة الدنماركية هي الافتراضية.
هم - بناء 10.0.18362.267 مقابل 10.0.18362.239 - هل هناك دليل هناك؟ !!!

للحصول على كافة التفاصيل:
أنا على
فوز 10 Enterprise en-US 1903 build 18362.239.1
لوحة مفاتيح دانمركية ، لا توجد حزمة لغة

حاولت للتو تسجيل الدخول على حساب بحزمة اللغة الأمريكية كإعداد افتراضي ، - محطة مثبتة هناك وتحولت إلى لوحة المفاتيح الدنماركية لمعرفة ما إذا كان لحزمة اللغة المختارة أي تأثير ، ولكن لا حظ هناك.

لا أعرف ما إذا كان هذا قد يكون دليلًا لشخص ما على دراية ولكن قبل الترقية إلى 1903 من 1809 ، أظهرت لوحة المفاتيح على الشاشة ( c:\windows\system32\osk.exe ) نفس السلوك في جميع تطبيقات conhost ، cmd.exe ، ubuntu / wsl و powerhell.exe (تجاهل AltGr) ولكن في عام 1903 يبدو هذا ثابتًا.

أستطيع أن أؤكد أن بعض تسلسلات AltGr لن تعمل.
AltGr Q (= @ ) يعمل معي ، بينما على سبيل المثال AltGr 8 (= [ ) لا يعمل.

لقد قمت بإنشاء إصدار المتجر v0.3.2142.0 محليًا لتصحيح هذه المشكلة. نظرًا لأنني لم أتمكن من معرفة كيفية إنشاء AzureConnector ، فقد اضطررت إلى استبعاده على الرغم من: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉 تبين أن الإصدار 0.3.2142.0 الذي تم بناؤه محليًا يعمل بشكل جيد. تعمل جميع تسلسلات AltGr بشكل صحيح.
فقط نسخة المتجر من Terminal لا تفعل ذلك. هل يمكن أن يكون AzureConnector هو الخطأ هنا ، لأنني استبعدته؟ (أعني أنني أشك في أن الأمر كذلك ، ولكن فقط للتأكد ...)

@ DHowett- MSFTminiksa هل يمكنك (أو أي شخص آخر) إعادة التحقق من إصدار المتجر الخاص بـ v0.3.2142.0 ومقارنته بالإصدارات التي تم إنشاؤها محليًا؟

لدي نفس المشكلة. المحطة غير قابلة للاستخدام مع هذه المشكلة لأن AltGr أمر لا بد منه. ولماذا هذا الخيط مغلق؟ يجب أن تكون قضية ذات أولوية قصوى.

ولماذا هذا الخيط مغلق؟

MasMedIm قد تلاحظ عند الفحص الدقيق أننا نعتقد أن هذا الخطأ قد تم إصلاحه ، بل

@ المدقق هذا غير عادي للغاية. لا يجب أن يكون للموصل Azure أي علاقة بهذا لأنه في طبقة مختلفة (اتصال وليس تحكم) ... لكن هذا مثير للاهتمام بغض النظر.

هل يمكنك (أو أي شخص آخر) إعادة التحقق من إصدار Store لـ v0.3.2142.0 ومقارنته بالإصدارات المحلية؟

الإصدار الذي أستخدمه حيث يعمل حرف AltGr الخاص هو إصدار المتجر

يعمل AltGr ( ~#{[|`\^@]}¤€ ) جيدًا هنا باستخدام لوحة مفاتيح فرنسية ، وإصدار Windows 10 1903 build 18362.267 ، و Windows Terminal Preview 0.3.2142.0

@ sba923 لدي أيضًا لوحة مفاتيح فرنسية ونفس إصدار Windows. تركيبات AltGr التي لا تعمل هي: & ~ # {[| `\ ^ € ù \
يتم تنزيل المحطة الطرفية الخاصة بي من المتجر أيضًا. سأحاول بناءه محليًا لنرى.

فقط لتوضيح وضعي ، - بعض تركيبات AltGr + Key تعمل بالفعل بينما البعض الآخر لا يعمل.

لا يعمل:

| مفتاح | توقع AltGr + Key: |
| ----- | ----------------------- |
| '2' | "@" |
| "3" | "£" |
| "4" | '$' |
| "7" | '{' |
| "8" | '[' |
| "9" | ']' |

يعمل:

| مفتاح | توقع AltGr + Key: |
| ----- | ----------------------- |
| '0' | '}' |
| '´' | '|' |
| '<' | '\' |
| '¨' | '~' |
| 'ه' | "€" |

ملاحظة: "´" ، "¨" هي أنواع مفاتيح ميتة.

النظام: Windows 10 64bit Home 1903 Build 10.0.18362.267
Windows Terminal: معاينة v0.3.2142.0 - إصدار المتجر
تخطيط لوحة المفاتيح: الدنماركية.

MasMedIm ، @ sba923 ، lhecker - هل إصدارات Windows الخاصة بك
تحرير: نسيت سؤالي. كنت على وشك بدء مطاردة أوزة برية هناك ؛-) ، ولكن يبدو أن @ checker قد حل الانحدار!

@ DHowett-MSFT @ henrik-jensen et. al: لقد وجدت سبب الانحدار. ¯ \ _ (ツ) _ / ¯
... وهذا يجعلنا جميعًا هنا مجموعة من الحمقى لملاحظتهم سابقًا. 😂

يحتوي profiles.json على اختصارات من النوع Ctrl+Alt+[0-9] للانتقال بسرعة إلى علامة التبويب 1-10.
إذا قمت بإزالة هذه الاختصارات من ملف الإعدادات ( Ctrl ) ، فسيتم إصلاح الانحدار.
بعض التركيبات مثل AltGr E مقابل € للأسف لم تنجح أبدًا حتى الآن ، ويجب على شخص ما قضاء الوقت اللازم لإصلاح ذلك.

نظرًا للطريقة التي تعمل بها واجهات برمجة تطبيقات Windows القديمة ، سيكون من الصعب التمييز بشكل موثوق بين اختصارات Ctrl Alt وضغط مفاتيح AltGr الفعلي ، لكنني

تضمين التغريدة
تم تأكيد. جوبي

مجموعات معينة مثل AltGr E مقابل € للأسف لم تنجح أبدًا على الرغم من ذلك ، ويجب على شخص ما قضاء الوقت اللازم لإصلاح ذلك.

يعمل AltGr E -> "€" على تخطيط لوحة المفاتيح الدنماركية. سأحاول إضافة تخطيط ألماني لي لمعرفة ما إذا كان قابلًا للتكرار في الإعداد الخاص بي.

ماذا عن مجرد عض الرصاصة؟ احتفظ بـ CMD.EXE القديم للتطبيقات القديمة (DOS) وتصميم المحطة الطرفية الجديدة للمستقبل فقط؟ لا يعني ذلك أن التوافق مع الإصدارات السابقة ليس رائعًا - ولكن في بعض الأحيان ، عليك فقط قطع العلاقات ...

تضمين التغريدة
تم تأكيد. جوبي

مجموعات معينة مثل AltGr E مقابل € للأسف لم تنجح أبدًا على الرغم من ذلك ، ويجب على شخص ما قضاء الوقت اللازم لإصلاح ذلك.

يعمل AltGr E -> "€" على تخطيط لوحة المفاتيح الدنماركية. سأحاول إضافة تخطيط ألماني لي لمعرفة ما إذا كان قابلًا للتكرار في الإعداد الخاص بي.

الألمانية المثبتة ~ Kezboard ~ ups ولوحة المفاتيح :-) * و AltGr E -> '€' تعمل في هذا الإعداد.

تحرير: يتم تبديل * 'z' / 'y' على لوحات المفاتيح الألمانية / الدنماركية.

يحتوي profiles.json على اختصارات من النوع Ctrl+Alt+[0-9] للانتقال بسرعة إلى علامة التبويب 1-10.

لسبب ما ، تكون هذه الاختصارات هي alt + [0-9] في ملف الإعدادات الخاص بي ولذا لم أواجه مشكلة

بعض الأسئلة تطرأ علي الآن:

• lhecker ربما يتعين علينا إصدار مشكلة جديدة -lhecker قدم طلب سحب # 2235
• أتساءل أين تم إنشاء الإعدادات الافتراضية ~ settings.json ~ profiles.json . إنه ليس موردًا لذا أفترض أنه من الصعب ترميزه في مكان ما؟ تحرير: وجدتها CascadiaSettings.cpp L369
• ما هي الاختصارات البديلة التي يجب اختيارها بدلاً من ذلك. ربما هؤلاء saadanerdetbare لديهم في ~ settings.json ~ profiles.json (هل كانوا الخيار الافتراضي في ما قبل 0.3.2142.0؟ تعديل: يبدو كذلك - # 2014)

lhecker @ profiles.json لذا إذا لم يقم التحديث بالكتابة فوق الملف لأنه مخصص وليس افتراضيًا ، فلن أحصل على اختصارات Ctrl + Alt

@ DHowett-MSFT @ henrik-jensen et. al: لقد وجدت سبب الانحدار. ¯_ (ツ) _ / ¯
... وهذا يجعلنا جميعًا هنا مجموعة من الحمقى لملاحظتهم سابقًا. 😂

يحتوي profiles.json على اختصارات من النوع Ctrl+Alt+[0-9] للانتقال بسرعة إلى علامة التبويب 1-10.
إذا قمت بإزالة هذه الاختصارات من ملف الإعدادات (Ctrl) ، فسيتم إصلاح الانحدار.
بعض التركيبات مثل AltGrE مقابل € للأسف لم تنجح أبدًا على الرغم من ذلك ، ويجب على شخص ما قضاء الوقت اللازم لإصلاح ذلك.

نظرًا للطريقة التي تعمل بها واجهات برمجة تطبيقات Windows القديمة ، سيكون من الصعب التمييز بشكل موثوق بين اختصارات CtrlAlt وضغطات مفاتيح AltGr الفعلية ، لكنني سأفحص ما إذا كان يمكن تحسين الوضع بطريقة ما.

بالنسبة للرد ، فقد كانت إعدادات Ctrl + Alt + [0-9]

saadanerdetbare ، نعم ، تم تغييره من إعداداتك إلى الإعدادات الجديدة هنا # 2014 بواسطة @ zadjii-msft

أؤكد أن الاختصارات الجديدة تكسر AltGr ( ~#{[|`\^@]} ) على لوحة المفاتيح الفرنسية.

السبب الذي يجعل البعض منا لا يرى الانحدار مرتبط بالترقية 0.3 التي لا تتجاوز profiles.json ، الموثق في Windows Terminal Preview v0.3 الإصدار :

ملاحظة: إذا كنت قد قمت مسبقًا بتثبيت Terminal قبل هذا الإصدار ، فلن تظهر روابط المفاتيح هذه إلا بشكل افتراضي بمجرد حذف ملفات التعريف الخاصة بك. json والسماح لها بالتجديد. يمكنك حفظ ملفات التعريف الأصلية الخاصة بك في مكان آخر ونسخ تخصيصاتك أو إضافة روابط المفاتيح هذه يدويًا. نحن ندرك أن هذه ليست تجربة مثالية ونعمل على تحسينها.

يمكن للمرء استخدام ctrl + alt + shift + _digit_ ، على الرغم من أنه ليس من السهل جدًا إدخال ...

@ henrik-jensen فتحت # 2235.

thorsig لقد تم
خاصة إذا أخذنا بعين الاعتبار أن مثل bash على Linux (مثل معظم القذائف التي قد ترغب في استخدامها على Windows في المستقبل) _لا_ يتلقى رموز المفاتيح الأولية ، بل نصًا عاديًا مشبعًا بتسلسلات الهروب. هروب التسلسلات التي يحتاجها جهازك الطرفي لتوليدها من أحداث لوحة المفاتيح. _لا تتعامل قذيفة Linux الخاصة بك مع رموز المفاتيح الأولية. محطة الخاص بك تفعل.
قبل متابعة هذا ، يجب أن تفهم أولاً كيفية عمل xterm و vt100 (والإصدارات الأحدث).
راجع للشغل: رموز المفاتيح على Linux هي أيضًا مجرد تجريد افتراضي (! = خام) فوق رموز scancodes من لوحة المفاتيح - راجع keymaps.5 . الاختلاف الوحيد هو أنه في نظام التشغيل Windows ، تقرر منذ زمن طويل أن Ctrl + Alt هو نفسه AltGr ، لأن بعض لوحات المفاتيح تفتقر إلى مفاتيح AltGr ، ولكن لا يزال المرء يريد أن يكون قادرًا على الضغط على AltGr بطريقة ما. الأشخاص الذين قرروا هذا قد يكونون أكثر من 60 في الوقت الحاضر. تغيير هذا ليس بالأمر الهين وله فائدة ضئيلة فقط (حيث يمكنك اكتشاف ضغطات مفتاح AltGr في الممارسة العملية بالفعل على أي حال).

أؤكد أن الاختصارات الجديدة تكسر AltGr ( ~#{[|`\^@]} ) على لوحة المفاتيح الفرنسية.

السبب الذي يجعل البعض منا لا يرى الانحدار مرتبط بالترقية 0.3 التي لا تتجاوز profiles.json ، الموثق في Windows Terminal Preview v0.3 الإصدار :

ملاحظة: إذا كنت قد قمت مسبقًا بتثبيت Terminal قبل هذا الإصدار ، فلن تظهر روابط المفاتيح هذه إلا بشكل افتراضي بمجرد حذف ملفات التعريف الخاصة بك. json والسماح لها بالتجديد. يمكنك حفظ ملفات التعريف الأصلية الخاصة بك في مكان آخر ونسخ تخصيصاتك أو إضافة روابط المفاتيح هذه يدويًا. نحن ندرك أن هذه ليست تجربة مثالية ونعمل على تحسينها.

يمكن للمرء استخدام ctrl + alt + shift + _digit_ ، على الرغم من أنه ليس من السهل جدًا إدخال ...

من الأسهل استخدام alt + _digit_ وهو مشابه للاختصارات في gnome-terminal.
إنه يعمل على لوحة المفاتيح الفرنسية.

إذا كنت تستخدم Alt + digit ، فاعلم أنك لن تتمكن من إرسال هذه المفاتيح إلى تطبيق وحدة التحكم.

: tada: تمت معالجة Windows Terminal Preview v0.3.2171.0 .: tada:

روابط مفيدة:

• ملاحظات الإصدار
• تنزيل المتجر

يعمل AltGr ( ~#{[|`\^@]}¤€ ) جيدًا هنا باستخدام لوحة مفاتيح فرنسية ، إصدار Windows 10 1903 الإصدار 18362.267 ، Windows Terminal Preview 0.3. 2171 0.0، واختصارات تبديل علامة التبويب المقرر أن Ctrl+Alt+digit .

عمل جيد!

شكرا على التأكيد!

اهلا وسهلا!

تم تأكيد إصلاح 0.3.2171.0 لنظامي - لوحة المفاتيح الدنماركية Win10 Home 1903 build 10.0.18362.267.
حذفت profiles.json للحصول على الإعدادات الافتراضية والآن يعمل AltGr أيضًا مع تثبيت جديد (أفترض).
عمل رائع lhecker وكل شخص آخر معني.

مرحبًا ، أعتقد أن لدي هذه المشكلة في الإصدار 0.7.

لا يمكنني إدخال مفتاح الشرطة المائلة على لوحة المفاتيح الخاصة بي إما باستخدام لوحة المفاتيح الرقمية ou AltGr + Q (لوحة المفاتيح البرازيلية ABTN2 لجهاز كمبيوتر محمول من سامسونج لا تحتوي على علامة الاستفهام / مفتاح الشرطة المائلة).

تحرير: لا يمكنني إدخال أي مفتاح AltGr.

بعد إزالة نسخة قديمة من PSReadline ، كل شيء يعمل الآن.

FWIW ، لقد كتبت نصوص PowerShell النصية المرفقة للتحقق من إصدارات PSReadline الموجودة على نظامي / أي منها نشط.

CheckPSReadLineStatus.zip

HTH

لإصلاح نفس المشكلة التي أبلغ عنها Beppler ، قم بما يلي:

بعد إزالة نسخة قديمة من PSReadline ، كل شيء يعمل الآن.

من جلسة بوويرشيل المرتفعة قم بما يلي:

Install-Module -Name PowerShellGet -Force
Exit

من جلسة cmd المرتفعة قم بما يلي:
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

ما هي حالة هذه القضية؟
نظرًا لأن البحث في المشكلات المرتبطة يبدو أنه تم إصلاحه ، لكنه لا يزال لا يعمل معي. من أجل طباعة الحرف ~ على تخطيط لوحة مفاتيح إيطالي ، اعتدت على عمل Alt + 126 ولكن هذا له سلوك مختلف اعتمادًا على نوع الجهاز الطرفي ، لكن في أي منها لا يمكنني الحصول على الحرف ~ طبع ، أثناء القيام مباشرة في الغلاف الأساسي (git / cmd /owershell / wsl غير مضمن في windows terminal) يعمل كما هو متوقع

هذا ما يحدث لي مع أحدث إصدار من windows terminal ، في لحظة كتابة هذا التقرير:

Windows Terminal (Preview)
Version: 0.8.10091.0)

ilmax لقد كسرت إدخال Alt + Numpad في # 3117. الآن بعد أن تم دمج # 3117 وتم إصلاح المشكلة المرتبطة ، يمكننا العمل على إعادة إدخال إدخال Numpad في قاعدة التعليمات البرمجية.
سأجعل هذا سلوكًا اختياريًا وقابل للتهيئة ، لأنني متأكد تمامًا من أن معظم المستخدمين المحتملين لتطبيق Terminal لن يستفيدوا منه بعد الآن. يجب أن يكون التطبيق افتراضيًا لإرسال كل مدخلات لوحة المفاتيح الممكنة إلى shell حتى تتمكن من تكوين روابط أكثر تقدمًا ، إلخ.
يجب أن يكون تنفيذ ذلك أسهل قليلاً بمجرد دمج # 4192. سيتعين عليك إضافة المنطق الإضافي هنا والتحقق مما إذا كان مفتاح Alt (ومفتاح Alt فقط) محتجزًا في states ، بينما ينطلق vkey من اللوحة الرقمية بدلاً من المفاتيح الرقمية العادية . لا تتردد في تقديم العلاقات العامة في أي وقت! 🙂

lhecker شكرًا للاستجابة السريعة ، أردت فقط معرفة حالة هذا لأن كل مشكلة وجدتها كانت مغلقة ولكن المشكلة لا تزال قائمة.
لست متأكدًا من أنني سأخرج بعلاقات عامة حول هذا الأمر ، لم ألقي نظرة على الكود من قبل 😄 لذلك لا أعرف حقًا من أين أبدأ ، على الرغم من اقتراحك.

أردت فقط معرفة كيفية إصلاح سير العمل الخاص بي لـ git rebase -i لأنه يتعين علي الآن فتح شيء مثل notepad ++ ، واكتب الحرف ~ ، وانسخه ولصقه في الجهاز.

فقط حتى أفهم: أنت في موضوع حول AltGr مع سؤال حول _alt + تسلسلات رقمية_؟ قد يكون هذا هو سبب إغلاق جميع سلاسل الرسائل التي تعثر عليها: تم إصلاح مشكلة AltGr.

أعتقد أن لدينا مشكلة منفصلة تتبع مشاكل إدخال alt + Numpad.

نعم ، أنت على حق ، آسف للارتباك. أعتقد أن # 657 قد يكون هو الصحيح