Hey Markus @snaut ,
Thanks for your answer.
Unfortunately it is not working for me, as it just returns “q” (I have a german keyboard where the “@” is “alt gr” + “q” )
Also the keyboard DAT just returns “@” as
Could it be a system problem with languages being mixed up and confusing CEF? (I’m on a windows machine as well)
Thanks for your help
(I think I unfortunately will be posting a lot of questions about webrender in the next days )
it seems like there are multiple issues related to the Keyboard DAT and the WebRender TOP regarding non-english keyboards. Initially we thought we had it working with sending not the key but using the
.sendString() method if the
key arguent had a length of 1 but that turned out to break any umlaute…
We are looking at this and I’m moving this post into the Bug section. We’ll be back with an update.
sendString() is doing the job for the “#” by the way.
Looking forward the updates
I am running into the same problem and would really appreciate a solution, since I am deep into a project using the webrenderTOP
Hey @django ,
I didn’t get it working in the end and I don’t know if it has been fix in a newer release.
The solution would be to install your system as an english machine, I couldn’t do that as I don’t have a dedicated machine or this project yet.
If you find any solution i’m interested as well as I should come back to this project soon.
I tried it with the newest release, but it hasn’t been fixed yet.
The app will be used by different people and I can’t tell them to switch their keyboards for it.
I really hope, that this can be fixed or worked around
Just a heads up for anyone running into this problem:
I tried sending the keycodes over a websocket and dispatch keyevents in my web app. The problem with this approach is, that those events are automatically marked as “not trusted” (a security measure of the webbrowser). This prevents native interaction with any textfields and is therefore useless in most cases.
I experimented with the sendString method of the webrenderTOP, but this didn’t go anywhere as well…
Can you try this for a work around? sendKey and sendString goes through the cef keyboard, which doesn’t cover all the characters depending on the keyboard. Using the system clipboard to paste strings works for me.
ui.clipboard = 'XYZ ö, ä, ü @@@@'
Thank you Selina for looking into this
This code works for almost all the keys on my funny Swiss keyboard (except ^ ` ~ for some reason):
if len(key) > 1:
webrender.sendKey(key, alt=alt, ctrl=ctrl, shift=shift)
ui.clipboard = character
Of course it clears the clipboard while typing and can therefore be very confusing for the user.
Do you think it will be possible to fix the sendKey function in a future update?
So I think what I might be able to do is to modify the sendString function so that it sends the string over, and then I do copy to clipboard, paste to keyboard focus, restore clipboard to original text, which would be a bit less confusing for the user.
I’ll have to poke around but I don’t recall a direct way to put characters onto the webpage keyboard focus without simulating keyboard events, that’s why sendString isn’t working for non keyboard characters.
I’m curious why ^ ` ~ isn’t working. Does ui.clipboard contains the correct character but it isn’t pasting? Or is it an issue of the Keyboard In DAT not recognizing those characters?
So I experimented a bit with the following result:
~ symbols are all the same key on my keyboard. ^ can be applied to characters, so when I want them on their own, I have to press space afterwards.
The ~ should work instantly with the alt-gr modifier.
But the keyboardinDAT doesn’t recognize those keys correctly.
For ^ ` only pressing the key three times in a row works.
The ~ character only appears in the keyboardin, when releasing the key, but then the state is 0 of course.
If there is no way of sending the right characters through the cef keyboard, than the copy-paste approach seems to be the only solution.
Although a more ’ native’ would be a lot nicer, since it would allow to listen for those keyevents as well.
I ran into another issue, while trying to implement a hold key behaviour.
When exiting performMode with the ESC key, the state gets stuck at 1 and stays there even when re-entering performMode. So my webapp gets unusable until another key is pressed and the state is reset. I guess there are ways to work around this issue as well, but it starts to feel very hacky.
Since the webrenderTOP looks like such a great tool to build beautiful ui’s inside of TD, it would be nice, if there was a better way to interact with it. There already is a RFE for that: Native WebRender COMP - #8 by alphamoonbase
So I came up with a workaround for the hold key issue and ran into another one.
Sometimes, after resizing the perform window, the webrendertop stays black.
I am on Windows 10 using TD version 2021.15800
WebRender HoldKey.toe (5.3 KB)
Thanks a lot Selina, this solve my original issue perfectly!
If anyone is interested, here are my workarounds for the other issues (hold key and resizing):
I just wanted to ask, if this problem is still on the radar?
Would be great to have it fully functioning.
Yes, it is still on the radar. We have 2 separate issues:
- Keyboard DAT not handling characters from certain keyboards correctly
- Web Render TOP.sendString() not pasting strings as is. This one I’ll probably fix with the copy paste hack internally.
Thats great to know, thanks Selina.
@selina: I just wanted to ask kindly, if you still think this issue could be fixed.