single and double quote keyboard key doesn't show single and double quotes in editor #33678

New Issue

Jananton Bijsterbosch · 2012-12-27T12:04:40+01:00

2012-12-27 12:04:40 +01:00

%%%Pressing the single and (shift)double quote key on the keyboard does not result in a single or double quote becoming visible in either the text editor window, or the interactive python console. Needless to say this key works in any other application installed on this computer.
This erroneous behaviour started in version 2.63, in all previous versions the key worked / works as expected.

CPU: Intel(R) Core(TM) i7 920 @ 2.67Ghz 2.67Ghz
RAM: 6 Gb
GFX: Nvidia GTS 250 1Gb
OS: Windows 7 Pro, 64bits
Drivers: Nvidia 285.62
Blender: release 2.65a, build 2.65.0 r53189%%%

%%%Pressing the single and (shift)double quote key on the keyboard does not result in a single or double quote becoming visible in either the text editor window, or the interactive python console. Needless to say this key works in any other application installed on this computer. This erroneous behaviour started in version 2.63, in all previous versions the key worked / works as expected. CPU: Intel(R) Core(TM) i7 920 @ 2.67Ghz 2.67Ghz RAM: 6 Gb GFX: Nvidia GTS 250 1Gb OS: Windows 7 Pro, 64bits Drivers: Nvidia 285.62 Blender: release 2.65a, build 2.65.0 r53189%%%

Jananton Bijsterbosch commented

2012-12-27 12:04:40 +01:00

Changed status to: 'Open'

Campbell Barton commented

2012-12-27 13:21:28 +01:00

%%%odd, can't redo this - works here.

Blender r53341, 64bit linux.
GeForce GTS 450

I'd guess if this was a common problem we'd get many more reports about this.

Could you make sure your using recent graphics card drivers?,

Can anyone else confirm this issue?%%%

%%%odd, can't redo this - works here. Blender r53341, 64bit linux. GeForce GTS 450 I'd guess if this was a common problem we'd get many more reports about this. Could you make sure your using recent graphics card drivers?, Can anyone else confirm this issue?%%%

Ton Roosendaal commented

2012-12-27 16:26:15 +01:00

%%%Works fine for me too, but I use a standard english keyboard layout.

What layout you have? Probably there's the problem... A lot of people use Blender to work with Python, so it's certainly not a common error :)%%%

%%%Works fine for me too, but I use a standard english keyboard layout. What layout you have? Probably there's the problem... A lot of people use Blender to work with Python, so it's certainly not a common error :)%%%

Jananton Bijsterbosch commented

2012-12-27 17:06:45 +01:00

%%%Well, I presume you mean the settings in the Country and Language settings in the configuration section of windows 7.
It's a Dutch version of windows 7pro 64bits, so I'm not sure if I use the exact correct labels, but here's the translation for: text services and input languages.

Default input language: Nederlands(Nederland) - Verenigde Staten(internationaal)
Installed Services: NL - keyboard - Verenigde Staten (Internationaal).

The graphic drivers are the latest certified ones from nvidia afaik. And to make a final stand: "Hello", and 'here you go'. ;-))%%%

%%%Well, I presume you mean the settings in the Country and Language settings in the configuration section of windows 7. It's a Dutch version of windows 7pro 64bits, so I'm not sure if I use the exact correct labels, but here's the translation for: text services and input languages. Default input language: Nederlands(Nederland) - Verenigde Staten(internationaal) Installed Services: NL - keyboard - Verenigde Staten (Internationaal). The graphic drivers are the latest certified ones from nvidia afaik. And to make a final stand: "Hello", and 'here you go'. ;-))%%%

Ton Roosendaal commented

2012-12-27 18:20:55 +01:00

%%%Dutch keyboards are nearly the same as US keyboards...

I assume the ' and " characters are on same key? I type " with shift.

Problem with this issue is that it's not reproducible, so you have to start digging to find out which setting is causing the error.

Check factory settings (file menu) to rule out add-on installs or so
check any other computer you can access to compare
there might be some other programs disbehaving too... try non-microsoft open source programs, such as Gimp or Inkscape. Firefox?
%%%

%%%Dutch keyboards are nearly the same as US keyboards... I assume the ' and " characters are on same key? I type " with shift. Problem with this issue is that it's not reproducible, so you have to start digging to find out which setting is causing the error. - Check factory settings (file menu) to rule out add-on installs or so - check any other computer you can access to compare - there might be some other programs disbehaving too... try non-microsoft open source programs, such as Gimp or Inkscape. Firefox? %%%

Jananton Bijsterbosch commented

2012-12-27 23:44:14 +01:00

%%%Yup, they're on the same key that's why I said (shift)double quotes.
I don't have Firefox, but do have Gimp 2.6.8 and Inkscape 0.48.1
In both, when I want to enter text the key does what it's supposed to do and provides quotes and double quotes.
Since both are obviously 32bits programs I downloaded the 32bits version of blender 2.65a, but with the same result as the allready installed 64bits version, e.g. no quotes.

I'm not sure what you mean with factory settings. I did press that option in the file menu, but after that there didn't change anything either...

I can see if I can fire up another pc tomorrow, but if that's comparable? Gimp nor Inkscape display the mentioned problem.
That other pc would be an intel P4. Win XP Sp3 32bits with another ps2 connected keyboard instead of this usb connected Logitech ultra slim one I use on my current box. %%%

%%%Yup, they're on the same key that's why I said (shift)double quotes. I don't have Firefox, but do have Gimp 2.6.8 and Inkscape 0.48.1 In both, when I want to enter text the key does what it's supposed to do and provides quotes and double quotes. Since both are obviously 32bits programs I downloaded the 32bits version of blender 2.65a, but with the same result as the allready installed 64bits version, e.g. no quotes. I'm not sure what you mean with factory settings. I did press that option in the file menu, but after that there didn't change anything either... I can see if I can fire up another pc tomorrow, but if that's comparable? Gimp nor Inkscape display the mentioned problem. That other pc would be an intel [P4](https://archive.blender.org/developer/P4.txt). Win XP Sp3 32bits with another ps2 connected keyboard instead of this usb connected Logitech ultra slim one I use on my current box. %%%

Harley Acheson commented

2012-12-28 01:52:41 +01:00

%%%There are two keyboard "layout" issues. First is specifying the type of physical keyboard (where each key is located) and the "keyboard layout" which is how the keys behave.

If you have a keyboard like the "US 101" keyboard then you have a key with quote and double-quote immediately to the left of the "Enter" key. But if you tell Windows that you are using this keyboard with the "International" layout then that key behaves differently. That key becomes a "dead" key that allow you to enter international accented characters.

So I think you have to change your keyboard layout from "Verenigde Staten(internationaal)" to just "Verenigde Staten"...%%%

%%%There are two keyboard "layout" issues. First is specifying the type of physical keyboard (where each key is located) and the "keyboard layout" which is how the keys behave. If you have a keyboard like the "US 101" keyboard then you have a key with quote and double-quote immediately to the left of the "Enter" key. But if you tell Windows that you are using this keyboard with the "International" layout then that key behaves differently. That key becomes a "dead" key that allow you to enter international accented characters. So I think you have to change your keyboard layout from "Verenigde Staten(internationaal)" to just "Verenigde Staten"...%%%

Campbell Barton commented

2012-12-28 12:15:34 +01:00

%%%Can you make sure we know if this is this a display issue or keyboard input?

Does copy-pasting "" '' from an external program into the console and text editor show up the characters?%%%

%%%Can you make sure we know if this is this a display issue or keyboard input? Does copy-pasting "" '' from an external program into the console and text editor show up the characters?%%%

Jananton Bijsterbosch commented

2012-12-28 12:48:15 +01:00

%%%Yes, copy and paste the quotes in from somewhere else does work, in fact that's what I did to work round the problem the past few days. ;-)

Because of Harley's post I added an English(Verenigde Staten) keyboard service to the keyboard list and that setting does work.
However, allthough this seems to solve the immediate problem, the question still remains why Gimp and Inkscape don't have this problem with the original Dutch keyboard service.

And, before someone asks, the Dutch service doesn't allow setting the keyboard to just 'Verenigde Staten', 'Verenigde Staten (International)' is the only available option.%%%

%%%Yes, copy and paste the quotes in from somewhere else does work, in fact that's what I did to work round the problem the past few days. ;-) Because of Harley's post I added an English(Verenigde Staten) keyboard service to the keyboard list and that setting does work. However, allthough this seems to solve the immediate problem, the question still remains why Gimp and Inkscape don't have this problem with the original Dutch keyboard service. And, before someone asks, the Dutch service doesn't allow setting the keyboard to just 'Verenigde Staten', 'Verenigde Staten (International)' is the only available option.%%%

Harley Acheson commented

2012-12-28 18:15:51 +01:00

%%% Jananton,

Gimp and Inkscape are much simpler (as far as keyboard interaction is concerned) and they are designed to act as well-behaved Windows applications. They leave it up to the operating system to supply them with processed keyboard characters. So they get an uppercase "L" from Windows and they don't have to worry about how it got there, what type of keyboard was used, what language, what arrangement, or even if if was dictated by voice.

Blender uses keystrokes in very complex ways and is designed to interact with your computer at a lower level. It will only get an uppercase "L" if you press the key that is three over from the "Enter" key while having the shift key pressed down, no matter what is printed on your keyboard.

When you have the "International" layout turned on the interaction gets really complex. If you press double quote and then a 'P" you will get both of those characters. But press double-quote and then an "e" and you will get only one: an e with an accent. Windows does this behind the scenes to help typing accented characters but this behavior screws up Blender.%%%

%%% Jananton, Gimp and Inkscape are much simpler (as far as keyboard interaction is concerned) and they are designed to act as well-behaved Windows applications. They leave it up to the operating system to supply them with processed keyboard characters. So they get an uppercase "L" from Windows and they don't have to worry about how it got there, what type of keyboard was used, what language, what arrangement, or even if if was dictated by voice. Blender uses keystrokes in very complex ways and is designed to interact with your computer at a lower level. It will only get an uppercase "L" if you press the key that is three over from the "Enter" key while having the shift key pressed down, no matter what is printed on your keyboard. When you have the "International" layout turned on the interaction gets really complex. If you press double quote and then a 'P" you will get both of those characters. But press double-quote and then an "e" and you will get only one: an e with an accent. Windows does this behind the scenes to help typing accented characters but this behavior screws up Blender.%%%

Jananton Bijsterbosch commented

2012-12-28 19:59:18 +01:00

%%%Allthough I understand your explanation completely, since I've done quite some c(++) programming in the past, as a hobby I must add, I find it curious that this behaviour started with version 2.63 of blender. Version 2.62 and before work fine with the original keyboard setting here, so the change must be somewhere during the optimalisation, c.q. programming changes for the 2.63 release.%%%

Ton Roosendaal commented

2012-12-28 20:05:45 +01:00

%%%I wanted to add that blender is supposed to read characters from what the OS provides, not trying to interpret it self.%%%

Harley Acheson commented

2012-12-28 23:41:22 +01:00

%%%Very simple Windows programs will get all their character input via character messages (wm_char), but that isn't a good way to go if you need more information about key presses. Programs that need to know about keystrokes will quite often instead respond to keystroke messages (wm_keydown, wm_keyup, etc) and ignore wm_char.

We ignore both types of messages and instead ask Windows for raw input events associated with the keyboard, which is like the second way of doing it but it lets us know the real physical key that is pressed. This is what ties us to the US keyboard.

I'm also guessing that we make the assumption that input characters are the result of key presses, and use that wm_input event for character input. But there is not always a one-to-one correspondence between key presses and output characters. it is probably best to separate keypress processing from character input. So examine wm_input to determine what was pressed for shortcut command purposes but discard the input character.. For character input we should probably just look at wm_char, which will give us what the user intended no matter what keyboard, layout, language, method, etc. So one message tells us that a physical key was pressed, but a different message tells us which letter it is.

In short I am guessing that while having the "international" layout we got a message for the pressing of that double-quote key, but the vkey inside was blank (as it is a dead key until you press something else). We ignore wm_char so didn't get the real key once Window figured out it was meant as a quote and not a request to accent the next character.%%%

%%%Very simple Windows programs will get all their character input via character messages (wm_char), but that isn't a good way to go if you need more information about key presses. Programs that need to know about keystrokes will quite often instead respond to keystroke messages (wm_keydown, wm_keyup, etc) and ignore wm_char. We ignore both types of messages and instead ask Windows for raw input events associated with the keyboard, which is like the second way of doing it but it lets us know the real physical key that is pressed. This is what ties us to the US keyboard. I'm also guessing that we make the assumption that input characters are the result of key presses, and use that wm_input event for character input. But there is not always a one-to-one correspondence between key presses and output characters. it is probably best to separate keypress processing from character input. So examine wm_input to determine what was pressed for shortcut command purposes but discard the input character.. For character input we should probably just look at wm_char, which will give us what the user intended no matter what keyboard, layout, language, method, etc. So one message tells us that a physical key was pressed, but a different message tells us which letter it is. In short I am guessing that while having the "international" layout we got a message for the pressing of that double-quote key, but the vkey inside was blank (as it is a dead key until you press something else). We ignore wm_char so didn't get the real key once Window figured out it was meant as a quote and not a request to accent the next character.%%%

Jananton Bijsterbosch commented

2012-12-29 01:26:18 +01:00

%%%Well, in a way this corresponds with what I was thinking. What you call dead keys are in fact symbols that are put in a small buffer. The next keypress detects either if that buffer is empty and sends its own symbol into the loop, or, if there's a symbol in that buffer, flushes it and combines the two. In XP this was called 'smart character decoration' or something like that. Actually one could switch this behaviour off in XP, but I couldn't find it in Win7. I would have loved to try this before adding a new keyboard service, because if that would have worked in presenting a single or double quote in blender we would know what to look for.

My guess is that somehow between versions 2.62 and 2.63 that 'dead' buffer check got removed or mangled.%%%

%%%Well, in a way this corresponds with what I was thinking. What you call dead keys are in fact symbols that are put in a small buffer. The next keypress detects either if that buffer is empty and sends its own symbol into the loop, or, if there's a symbol in that buffer, flushes it and combines the two. In XP this was called 'smart character decoration' or something like that. Actually one could switch this behaviour off in XP, but I couldn't find it in Win7. I would have loved to try this before adding a new keyboard service, because if that would have worked in presenting a single or double quote in blender we would know what to look for. My guess is that somehow between versions 2.62 and 2.63 that 'dead' buffer check got removed or mangled.%%%

Harley Acheson commented

2012-12-29 01:42:26 +01:00

%%%
I remember this behavior from way back, 15 years at least. I live in Canada and our computers come with the same style keyboard as they have in the US. But every so often I'd get a customer/client/friend who would change the layout to "US (International)" and the result was hilarious. You could type "test" (with the quotes) just fine but try typing "elephant" and the first quote and e would turn into an e with an accent. So they would be mystified because it would work correctly most of the time but not every so often, depending on what letter was typed after the quote.

this page has information on the "international layout" including one on its use in the Netherlands:

http://en.wikipedia.org/wiki/Keyboard_layout#US-International
%%%

%%% I remember this behavior from way back, 15 years at least. I live in Canada and our computers come with the same style keyboard as they have in the US. But every so often I'd get a customer/client/friend who would change the layout to "US (International)" and the result was hilarious. You could type "test" (with the quotes) just fine but try typing "elephant" and the first quote and e would turn into an e with an accent. So they would be mystified because it would work correctly most of the time but not every so often, depending on what letter was typed after the quote. this page has information on the "international layout" including one on its use in the Netherlands: http://en.wikipedia.org/wiki/Keyboard_layout#US-International %%%

Ton Roosendaal commented

2012-12-29 10:00:41 +01:00

%%%Hi Harley,

I appreciate help in the bug tracker, but it doesn't help much to present assumptions without knowing the code. Even though I didn't code the windows bindings for Blender, I do know our specs and the work done there :)

To summarize:

Blender stores the 'raw key' (the physical one on keyboard) separate from the interpreted key (the character you want to type).

Since a long while (part of 2.5 project) we upgraded our event code to accept international keyboards and languages. Our windows code uses the active keyboard layout configuration to retrieve a Unicode character. Even though that can have bugs (as is presented here), it's something that's meant to work, and therefore needs investigation. I will try to find the person who worked on this to investigate it.
%%%

%%%Hi Harley, I appreciate help in the bug tracker, but it doesn't help much to present assumptions without knowing the code. Even though I didn't code the windows bindings for Blender, I do know our specs and the work done there :) To summarize: Blender stores the 'raw key' (the physical one on keyboard) separate from the interpreted key (the character you want to type). Since a long while (part of 2.5 project) we upgraded our event code to accept international keyboards and languages. Our windows code uses the active keyboard layout configuration to retrieve a Unicode character. Even though that can have bugs (as is presented here), it's something that's meant to work, and therefore needs investigation. I will try to find the person who worked on this to investigate it. %%%

Harley Acheson commented

2012-12-29 17:20:40 +01:00

%%%No problem, just wanted to give details about how double-quote behaves in the International layout. Choking on double-quote key on international layout is a known issue with ToUnicodeEx (in processKeyEven in GHOST_SystemWin32.cpp).%%%

Harley Acheson commented

2012-12-29 22:43:25 +01:00

%%%Okay, I'll try again without any "guessing" or "assumptions"...

The method we use to gather input characters (raw from keyboard presses) requires the use of "ToUnicodeEx", but because that function works only on the current keyboard state it does not allow you to properly handle input that involves dead keys. This is largely an unsolved problem that can be confirmed with a google search for ToUnicodeEx and "dead key".

In this particular case the user presses the double-quote key, considered a dead key in the International layout, and ToUnicodeEx returns "-1" and so we end up sending key event with a value of all zeros (line 732 in GHOST_SystemWin32.cpp). On the next key pressed ToUnicodeEx examines the keystate at that time and outputs that next character without any regard to what was pressed previously. So the double-quote key was swallowed up.

It might be possible to change this behavior so that the double-quote is not swallowed but returned always. But I do not believe it is possible to support the proper expected behavior from that keyboard layout of the user pressing double-quote and then "e" to get an e with an umlaut.
%%%

%%%Okay, I'll try again without any "guessing" or "assumptions"... The method we use to gather input characters (raw from keyboard presses) requires the use of "ToUnicodeEx", but because that function works only on the current keyboard state it does not allow you to properly handle input that involves dead keys. This is largely an unsolved problem that can be confirmed with a google search for ToUnicodeEx and "dead key". In this particular case the user presses the double-quote key, considered a dead key in the International layout, and ToUnicodeEx returns "-1" and so we end up sending key event with a value of all zeros (line 732 in GHOST_SystemWin32.cpp). On the next key pressed ToUnicodeEx examines the keystate at that time and outputs that next character without any regard to what was pressed previously. So the double-quote key was swallowed up. It might be possible to change this behavior so that the double-quote is not swallowed but returned always. But I do not believe it is possible to support the proper expected behavior from that keyboard layout of the user pressing double-quote and then "e" to get an e with an umlaut. %%%

Harley Acheson commented

2012-12-29 23:29:56 +01:00

%%%When I said that it would be best to separate key presses from character input I meant this:

Right now we get a message with raw data whenever a key is pressed. It is examined in processKeyEvent (line 710 in GHOST_SystemWin32.cpp). That function finds the actual key pressed and then also attempts to get the character(s) created. Then all the data (physical key pressed along with UTF characters) is sent along in a single ghost event message. This ties input characters to the pressing of keyboard keys.

It would be best to send that message out with only the physical key pressed. The purpose of that message would then be to tell the app that a key has been pressed, and it would be used for command processing only. So the fact that physical "S" key was pressed could be used to start scaling, but that "s" would not be treated as text.

Characters do not have to arrive with key presses. One key press can result in more than one character, multiple key presses might be required for one character, or characters could arrive without any key presses at all. For that you deal with the windows message WM_CHAR (at line 935 in GHOST_SystemWin32.cpp) as it arrives and send a different ghost event message that means a character has arrived. It will arrive exactly as the user intended and it is that one that you can use as text.

This does mean you are dealing with twice as many event messages, but you would ignore one or the other depending on the context.%%%

%%%When I said that it would be best to separate key presses from character input I meant this: Right now we get a message with raw data whenever a key is pressed. It is examined in processKeyEvent (line 710 in GHOST_SystemWin32.cpp). That function finds the actual key pressed and then also attempts to get the character(s) created. Then all the data (physical key pressed along with UTF characters) is sent along in a single ghost event message. This ties input characters to the pressing of keyboard keys. It would be best to send that message out with only the physical key pressed. The purpose of that message would then be to tell the app that a key has been pressed, and it would be used for command processing only. So the fact that physical "S" key was pressed could be used to start scaling, but that "s" would not be treated as text. Characters do not have to arrive with key presses. One key press can result in more than one character, multiple key presses might be required for one character, or characters could arrive without any key presses at all. For that you deal with the windows message WM_CHAR (at line 935 in GHOST_SystemWin32.cpp) as it arrives and send a different ghost event message that means a character has arrived. It will arrive exactly as the user intended and it is that one that you can use as text. This does mean you are dealing with twice as many event messages, but you would ignore one or the other depending on the context.%%%

Jananton Bijsterbosch commented

2012-12-29 23:34:22 +01:00

%%%Hmm, since you've googled, did you see the description of ToUnicodeEx here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms646322(v=vs.85).aspx

It seems when the return value is -1 the buffer LPWSTR pwszBuff will contain the virtual code of the dead character.%%%

%%%Hmm, since you've googled, did you see the description of ToUnicodeEx here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms646322(v=vs.85).aspx It seems when the return value is -1 the buffer LPWSTR pwszBuff will contain the virtual code of the dead character.%%%

Harley Acheson commented

2012-12-30 00:07:20 +01:00

%%%Yes, as mentioned it is possible to alter the code so that you output the character returned when it is -1, rather than discard it as we are doing now.

But that only solves part of the problem (your part actually). There are many keyboard layouts that use various keys to enter characters that are not on the keyboard. Unlike shift, ctrl, or alt, these are called "dead keys" as nothing comes out until you press something else.. So you press the backward single-quote (to the left of number one) and then a to get à, for example. In the "international" layout you can press double-quote and K and you will get both the quote and the K, but press double-quote and e and you get ë.

So using the character returned when when you press the dead key just gets you that key, then the next press gets that next key alone. But you don't get the combined accented character that was intended.
%%%

%%%Yes, as mentioned it is possible to alter the code so that you output the character returned when it is -1, rather than discard it as we are doing now. But that only solves part of the problem (your part actually). There are many keyboard layouts that use various keys to enter characters that are not on the keyboard. Unlike shift, ctrl, or alt, these are called "dead keys" as nothing comes out until you press something else.. So you press the backward single-quote (to the left of number one) and then a to get à, for example. In the "international" layout you can press double-quote and K and you will get both the quote and the K, but press double-quote and e and you get ë. So using the character returned when when you press the dead key just gets you that key, then the next press gets that next key alone. But you don't get the combined accented character that was intended. %%%

Jananton Bijsterbosch commented

2012-12-30 00:28:59 +01:00

%%%Well, I didn't want to mention that before, I know there are more dead or accent keys, the little roof like symbol above the 6 key is one of those as is the one you mentioned under the tilde.
However, I somehow can't believe the windows api hasn't a function to cater for combining these, the buffer and the next character pressed, allthough I must admit my programming experience is from before the introduction and certainly the general use of unicode. ;-)%%%

%%%Well, I didn't want to mention that before, I know there are more dead or accent keys, the little roof like symbol above the 6 key is one of those as is the one you mentioned under the tilde. However, I somehow can't believe the windows api hasn't a function to cater for combining these, the buffer and the next character pressed, allthough I must admit my programming experience is from before the introduction and certainly the general use of unicode. ;-)%%%

Harley Acheson commented

2012-12-30 00:53:01 +01:00

%%%The most extreme example would be someone dictating via voice (or composing characters using an IME maybe). Asking for data only when keyboard keys are pressed won't get that data no matter what Microsoft does. Instead they send all characters, no matter how they are created and no matter what language or keyboard, to the application message queue as wm_char events. That is the proper "character has arrived" message, while the other is "a key has been pressed"...%%%

Jananton Bijsterbosch commented

2012-12-30 00:54:35 +01:00

%%%I was a little quick with saving changes in the previous post. I would want to add; Allthough full accent, or deadkey support is preferrable, for programming uses like in the blender text editor and the python console the functioning of the combined double and single quote key seems the most important since those symbols are an integral part of allmost all programming languages. Not being able to place accents in commenting texts is a much less concern ihmo.%%%

Melvin Jacobson commented

2012-12-30 15:43:47 +01:00

%%%Got the same problem

Default input language: Nederlands(Nederland) - Verenigde Staten(internationaal)
Installed Services: NL - keyboard - Verenigde Staten (Internationaal).

But instead of switching and adding an English(Verenigde Staten) keyboard service, I just switched the default input language to Engels(Verenigde Staten) after starting Blender. %%%

%%%Got the same problem Default input language: Nederlands(Nederland) - Verenigde Staten(internationaal) Installed Services: NL - keyboard - Verenigde Staten (Internationaal). But instead of switching and adding an English(Verenigde Staten) keyboard service, I just switched the default input language to Engels(Verenigde Staten) after starting Blender. %%%

Harley Acheson commented

2012-12-31 00:07:17 +01:00

%%%I've just put in a patch here with lots of notes:
http://projects.blender.org/tracker/index.php?func=detail&aid=33709&group_id=9&atid=127

Please take a look at those notes (and caveats) and test if you can.%%%

%%%I've just put in a patch here with lots of notes: http://projects.blender.org/tracker/index.php?func=detail&aid=33709&group_id=9&atid=127 Please take a look at those notes (and caveats) and test if you can.%%%

Jananton Bijsterbosch commented

2012-12-31 11:59:10 +01:00

%%%I added a comment to your patch notes about how 'normal' your solution is concidered by me.

However, trying it out probably implies recompiling the source code, something I cannot do at the moment, or can I do something with that *.diff file with a compiled version I'm not aware of?%%%

%%%I added a comment to your patch notes about how 'normal' your solution is concidered by me. However, trying it out probably implies recompiling the source code, something I cannot do at the moment, or can I do something with that *.diff file with a compiled version I'm not aware of?%%%

Harley Acheson commented

2012-12-31 17:54:57 +01:00

%%%If you don't compile on your own, I've made a build for you, this morning's trunk with the patch. Bare bones and just 32-bit but it should be fine for testing this input issue.

http://www.hacheson.com/files/_hidden/BlenderFix33709.zip
%%%

%%%If you don't compile on your own, I've made a build for you, this morning's trunk with the patch. Bare bones and just 32-bit but it should be fine for testing this input issue. http://www.hacheson.com/files/_hidden/BlenderFix33709.zip %%%

Brecht Van Lommel commented

2013-09-19 17:55:51 +02:00

%%%This patch was committed 6 months ago but no one seems to have closed this report, so doing it now. It works as I would expect it here, testing with Belgian and Us International keyboard.%%%

Brecht Van Lommel commented

2013-09-19 17:55:52 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2013-09-19 17:55:52 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

single and double quote keyboard key doesn't show single and double quotes in editor #33678