Adobe's docs say:
For example, for a field with a value of “020”, value returns the integer 20,
while valueAsString returns the string “020”.
Share most of the fieldGetValue code by splitting it out into a 'Core'
variant and then using it in both GetValue and GetValueAsString.
BUGS: 468036
This represents the newly entered data for each keystroke. This is often a single added character, but for cases like pasting text it can be more complex.
The PDF API reference doesn't specify any algorithm to use.
The algorithm used here works by iterating through both strings from the start until the first different character is encountered. Then the rest of the new text is considered the difference.
This doesn't produce the theoretically optimal/minimal diff, but seems to work well enough for practical application.
When text is removed the diff is empty
Better enforce them now, so that the work to port doesn't increase over
time
Not a super fan of this for regular applications, but oh well the ship
has sailed
We did not take sepStyle 3 into account.
Also sepStyle 1 and 0 where mixed up and it didn't work either because
replace() needs to be assigned back to the string
BUGS: 445868
API let's you use both arguments or objects with named properties, so
support both.
This fixes the contents of the warning in 435833, the crash is still
there though, working on that next
CCBUGS: 435833
A lot of this code has been commented out for over
a decade and adds no value to the project.
It is only annoying when you look over it ;).
Same for the KNS2 support which was commented out.
Also some of the debug statements didn't even build
anymore, because the properties got removed/refactored.
find . \( -name "*.cpp" -or -name "*.h" -or -name "*.c" -or -name "*.cc" \) -exec clang-format -i {} \;
If you reached this file doing a git blame, please see README.clang-format (added 2 commits in the future of this one)
The problem was that the JS checker for the field format was using the
willCommit property of event and we don't define it so the JS
interpreter was going "ok nope, out of here" and the field didn't get edited.
I've read the willCommit definition in js_api_reference.pdf for almost
30 minutes, and even it's just 3 lines i don't think i understand it,
but i think that returning true is "safer", i.e. says that this event is
going to actually change the field, which as far as i can see it's what
we always do
BUGS: 421508
This adds utility functions to util to work with QLocale
for formatting and Number handling.
At least until we support AFNumber_Keystroke to restrict
what a user enters in Number input fields it is good
behavior to expect the user to enter Numbers in the system's
Locale.
AFNumber_Format is new for formatting and uses the
Locale util functions.
