Rank: Newbie
Groups: Registered
Joined: 8/9/2018(UTC) Posts: 3  Location: Lausanne Thanks: 1 times
|
Hello, I'm currently developing a WPF application that show PDF forms using the WPF PdfViewer of your SDK. In my scenario, I have to use the On-Screen Keyboard of Windows to fill the form (the targeted device don't have keyboard). During my test, I used the Handwriting mode of the On-Screen Keyboard: https://www.howtogeek.co...ing-input-on-windows-10/But sadly the text field of the PDF never receive the input. The field is not filled on the fly (like a standard WPF textbox) neither when I hit the return key (like it does if I open the PDF in Chrome). I want to know if you are aware of this problem and if you have solution or workaround for me. Best Regards, Etienne
|
|
|
|
|
|
Rank: Administration
Groups: Administrators
Joined: 1/5/2016(UTC) Posts: 1,138
Thanks: 10 times Was thanked: 133 time(s) in 130 post(s)
|
Hi, Pdf Acro fields is not standard textbox used in WPF or WinForms. They are just drawn by PDF renderer. To achieve the text field functionality PdfViewer call following methods from PreviewKeyDown event. Code:Pdfium.FORM_OnKeyDown(Document.FormFill.Handle, CurrentPage.Handle, (FWL_VKEYCODE)keyCode, 0);
Pdfium.FORM_OnChar(Document.FormFill.Handle, CurrentPage.Handle, ch, 0);
The first method provide functionality for non character keys, such as arrows, tab, etc and second one provide functionality for character keys. Seem onscreen touch keyboard uses non standard event to pass recognized text to the control. Due to that reason Acro fields do not receives this one. I have used spy++ to view the messages from onscreen keyboard on Win10 and I found that the WM_IME_CHAR ( https://docs.microsoft.com/en-us/windows/desktop/intl/wm-ime-char ) is passed to the control instead of WM_CHAR like when the hardware keyboard is used. So I can suggest the following workaround. The code below is WinForms code, but I hope it can be converted to WPF. You should create derived class from PdfViewer, override windows procedure and intercept WM_IME_CHAR event. Code:public class MyPdfViewer : PdfViewer
{
protected override void DefWndProc(ref Message m)
{
if(m.Msg == 0x0286) //WM_IME_CHAR
{
char ch = (char)m.WParam.ToInt32();
Pdfium.FORM_OnChar(Document.FormFill.Handle, CurrentPage.Handle, ch, 0);
}
base.DefWndProc(ref m);
}
}
Edited by user Friday, August 10, 2018 3:57:34 AM(UTC)
| Reason: Not specified
|
 1 user thanked Paul Rayman for this useful post.
|
|
|
|
Rank: Administration
Groups: Administrators
Joined: 1/5/2016(UTC) Posts: 1,138
Thanks: 10 times Was thanked: 133 time(s) in 130 post(s)
|
Maybe in WPF to intercept messages from onscreen touch keyboard the InputManager should be used instead of DefWndProc overriding. Have anybody experience in that? Edited by user Friday, August 10, 2018 3:53:58 AM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Newbie
Groups: Registered
Joined: 8/9/2018(UTC) Posts: 3  Location: Lausanne Thanks: 1 times
|
Hello Paul,
First, thanks for your reply. It put me on the right tracks, I think.
I also used Spy++ to analyze the message received by my application. Strangely, the On-Screen Keyboard send WM_CHAR messages, not WM_IME_CHAR on my machine (Windows 10 version 1803).
However, the Handwriting mode of the On-Screen Keyboard use WM_IME_NOTIFY messages, so I'll have to intercept and take care of these messages myself as you suggested.
During my search, I also found that, in WPF, only the Textbox and the RichTextbox controls are "IME-aware" and have a good response to these messages.
The workaround you proposed seem to do the trick for me, but in the short schedule I have, I don't know if I'll have the time to implement it.
Best Regards, Etienne
|
|
|
|
|
|
Rank: Administration
Groups: Administrators
Joined: 1/5/2016(UTC) Posts: 1,138
Thanks: 10 times Was thanked: 133 time(s) in 130 post(s)
|
Originally Posted by: ecarrupt  Hello Paul,
I also used Spy++ to analyze the message received by my application. Strangely, the On-Screen Keyboard send WM_CHAR messages, not WM_IME_CHAR on my machine (Windows 10 version 1803). Yes you right. The on-screen keyboard sends WM_IME_CHAR in the touch mode only. Since in the usual mode the normal message (WM_CHAR) is sent, this works by default and does not require any trick. So I did not focus on this.
|
|
|
|
|
|
Rank: Newbie
Groups: Registered
Joined: 8/9/2018(UTC) Posts: 3  Location: Lausanne Thanks: 1 times
|
Hum, I'm not sure what you mean by "touch mode only". Is it the "tablet mode" that you can switch on or off through the notification area?
|
|
|
|
|
|
Rank: Administration
Groups: Administrators
Joined: 1/5/2016(UTC) Posts: 1,138
Thanks: 10 times Was thanked: 133 time(s) in 130 post(s)
|
WM_CHAR is sent by this mode  keyboard01.png (164kb) downloaded 2 time(s).and WM_IME_CHAR by this  keyboard02.png (73kb) downloaded 2 time(s).
|
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Important Information:
The Patagames Software Support Forum uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close