Extending Reader Rights causing Initialize event to fire twice?

[kingphysh]

I have a few drop-down boxes populated by scripts on their respective Initialization events. Everything worked great through development--except, when I demonstrated the form for a group, I noticed the drop-down boxes were populating twice. I wasn't using a clearItems()--shouldn't have needed it, right?

So, this was something I couldn't reproduce in Desiger. Once the the Extended Rights had been removed, the form performed as expected in Acrobat, and Reader, too. Put the Extended Rights back on, and the drop-down boxes are double populating again. Take the Extended Rights off, no misbehaving, everythings fine. Extended Rights on, bad doggie, no biscuit!!

Now, obviously I can get past this by using clearItems(), or moving the scripts to preOpen. However, I'd like to know what the heck is causing this? Is this a bug? a known issue? or is it something caused by something somewhere else in the form? I have always assumed forms would behave the same with or without Extended Rights. But it looks very much like the Initialize event is firing twice upon opening with Extended Rights.

Any insights out there?

Thanks,

Stephen

[Niall_O_Donovan · Accepted solution]

Hi Stephen,

I have come across this before and thought I had a "proper" answer, but I can't find it. I think that when reader enabling rights are applied by Acrobat the the form does a check as part of the opening process. There appears to be a bunch of events that fire twice when the form is reader enabled (in Acrobat - I can't test if the form is enabled in LC RE ES2).

Here is an example showing how, when and in what order, events fire.  The form is at the end of the post (at http://cookbooks.adobe.com/post_How_often_events_fire_and_their_sequence-16547.html). There are 13 objects in the form, whose events are tracked.

When the form is not enabled the start up looks like this (certain events firing once as expected):

When I apply the reader enabling rights through Acrobat, the firing of events doubles for:

• initialise;
• form:ready;
• layout:ready
• IndexChange;
• docReady.

One indicator of what is potentially happening is that in the RE version the preSave event fires (but not postSave event).

Not the full answer - just an indication.

Good luck,

Niall

[kingphysh]

Niall,

Very interesting--very, very interesting.

Thank you for your expanantion. I am impressed with your work here. I can't imagine why you don't consider this a "formal" answer? It is really good work.

This is incredibly important stuff to understand. That last thing a form desiger needs is to be battling processes blindly. I thought I had given adequate  consideration to the order in which events fired, I never considered that there were different sequences under different scenereos.

Best,

Stephen

PS I found it interesting in your demo how late the "Click" event fires--after the user interacts with the messageBox that was launched by the script?

[Niall_O_Donovan]

Thanks Stephen,

It is interesting and I learnt a lot doing up the form. Paul Guerette helped me understand the events.

Niall

[kingphysh]

A great big "Thank you!" to Paul, as well.

[Eric_E_1234]

Hi,

I've run into a problem with my form with a similar issue, when Reader Extensions (extra usage rights in Adobe Reader) are added to the form:

• there are tables  with header rows
• header rows are set to repeat in the pagination settings
• In Reader v9 only, it seems, for the very FIRST page the table appears on, it will have one duplicate header on that first page for every instance of subsequent pages

For example, if my Table X spans 3 pages, then Table X has a total of 3 header rows, one for the first page and one for each of the subsequent pages.   AND it also has header rows on those subsequent pages, but only one on each page.

This is truly bizarre, and I've been bashing my head against the wall trying to figure out what's causing it.  Only today I have finally found some posts that seem to point to the real culprit:  Reader Extensions combined with tables with header rows, when viewed in version 9 of Acrobat Reader.  And even then, it doesn't seem to happen all the time.  It has been VERY difficult to reproduce this issue.

Can anyone help me?  Does anyone have a workaround, OTHER than setting the table header row not to repeat?

[Eric_E_1234]

Nevermind, it turns out there was some code in the form that was causing my problem.

Apparently if you try to set the presence of a table header when it's already visible, that can cause the rendering to get messed up.  Who knew?