logo
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
ecarrupt  
#1 Posted : Thursday, August 9, 2018 7:06:04 AM(UTC)
ecarrupt

Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 3
Switzerland
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
Paul Rayman  
#2 Posted : Friday, August 10, 2018 3:32:16 AM(UTC)
Paul Rayman

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

thanks 1 user thanked Paul Rayman for this useful post.
ecarrupt on 8/13/2018(UTC)
Paul Rayman  
#3 Posted : Friday, August 10, 2018 3:52:47 AM(UTC)
Paul Rayman

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

ecarrupt  
#4 Posted : Monday, August 13, 2018 3:20:40 AM(UTC)
ecarrupt

Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 3
Switzerland
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
Paul Rayman  
#5 Posted : Monday, August 13, 2018 5:19:55 AM(UTC)
Paul Rayman

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 Go to Quoted Post
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.

ecarrupt  
#6 Posted : Monday, August 13, 2018 8:17:02 AM(UTC)
ecarrupt

Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 3
Switzerland
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?
Paul Rayman  
#7 Posted : Monday, August 13, 2018 10:32:41 PM(UTC)
Paul Rayman

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).
Users browsing this topic
Guest (4)
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.