Compiling PDF forms

Hi,

just tried the new beta. Invisible text in text fields issues seems solved.
Thank you for your continued support!

Regards,
Michele

Hello everyone,

some time has passed since I last wrote here, which means I went on with development without encountering blocking issues, at least until now
Unfortunately I just stumbled upon a new issue, so I need your help one more time.

Our PDF forms have some repeating fields, aka several identical fields with the same name. This means that you can input, say, a date field on the first page, and the value for this field will be replicated to all the other companion fields. Of course the library does not do that for me, but I have code in place that handles this nicely.

The issue is that, if more than one field has the same name, GetEditTextFormat() calls on any of them them return an empty string. If, instead, the field names are different, GetEditTextFormat() works as expected.

I expect that you have some safeguard in place that makes GetEditTextFormat() return an empty string if multiple fields have the same name, since in this scenario you would not know which value to return. However, in this particular usage scenario it is correct to assume that all fields with the same name share the same format (or at least they should), hence GetEditTextFormat() can safely return the format of any of them.

Could you please perform this change?

Thank you in advance,
Michele

may you attach a sample file link here?

Sure, here it is:
dl.dropboxusercontent.com/u/7172743/IH-P..._N_it-de_2_0_pdf.pdf

In this PDF, starting from page 2, in the upper right of each page there is a date field.
This field is repeated on each page of the document, starting from page 2.
Field name is 'Text1' (your library returns it as 'Text1.' which is not a problem for me).
Field format is AFDate_FormatEx("dd/mm/yyyy");
Calls to GetEditTextFormat on this field fail to return the field format.

Regards,
Michele

Please check the latest beta 3.0beta5

Hi,

thank you for the new beta.
I tried it out, but got mixed results.

If I scroll to the first occurrence of the repeated annotation and tap it, GetEditTextFormat indeed returns the correct format for the annotation: AFDate_FormatEx("dd/mm/yyyy");

However, as soon as I scroll to the second occurrence of the annotation, the application will crash with the following error:
09-12 10:44:07.411 16799-16877/com.radaee.reader A/libc﹕ Fatal signal 7 (SIGBUS) at 0x5e05b6d9 (code=1), thread 16877 (Thread-1408)

Same happens when, after editing the first occurrence, my code tries to update the other occurrences, it crashes with the same error as soon as I try to edit the second occurrence of the annotation:
09-12 10:38:27.761 16678-16783/com.radaee.reader A/libc﹕ Fatal signal 7 (SIGBUS) at 0x5a37dda1 (code=1), thread 16783 (Thread-1392)

Visually, when I scroll to the first occurrence of the annotation, I can see the library drawing the text field around it.
When I scroll to the second occurrence of the annotation, I don't see the text field around it and the library will crash a moment afterwards.

Note that on this version I also get other crashes when tapping other text fields. For instance, I can consistently crash the application by tapping on 'Cliente' and 'Cogome1', 'Cognome2'. Interestingly enough, it does *not* crash if I tap on other fields such as 'Data1', 'Data2', 'Veicolo1'. From what I could see, it seems to crash on text fields that do not have format constraints.

So, to summarize:
1) GetEditTextFormat now correctly returns the format for repeated annotations
2) it crashes as soon as I try to access the second instance of a repeated annotation
3) it crashes on annotations where GetEditTextFormat should not return anything

regards,
Michele