For instance, if the event in question is a Keystroke it runs the code for the Keystroke event, making use of an event object to store information on the event and ultimately, decide what output occurs.
After or during the Keystroke event a call can be made to the Validate events which in turn can follow down to other events including the Calculate and Format events.
If the event is not a Keystroke event we start at the Validate event. This is actually a gross simplification of how events work since there are also many other possible events and the Calculate event can generate additional Validate, Blur and Focus events. But it for now I will focus on Keystroke events since they are, from what I can tell the simplest event that can occur to a form field.
In our latest version of the converter we map the keystroke actions onto the onKeyPress attributes of input objects, taking into account how the events work within PDF files. Which for the most part works correctly as they seem to have a one to one relationship with each other. Originally we tried mapping onto the onKeyDown attribute because of how the browsers implemented key presses differently but eventually we wrote a work around for this issue as onKeyDown had some undesirable properties.
It’s quite a hard subject to explain in writing, so here is an example:
As you can see we have yet to fully implement the formatting for the calculated values but it’s well on it’s way!
Do you need to solve any of these problems?
|Use PDF Forms in the Web Browser|
|Integrate PDF Forms into Web Apps|
|Convert PDF forms to HTML5|