Expand my Community achievements bar.

Elevate your expertise and be recognized as a true influencer! Nominations for the exclusive Adobe Community Advisor program 2023 are now OPEN.

11 dropdown lists


Not applicable
Got a XDP form that has 11 dropdown lists,

it's rendered as PDF in WorkSpace;

and at the form:Ready event, it uses the "clearItems()" and "addItems()" to build those 11 dropdowns. there's no other java scripts.

each dropdown has about 100 items. each item has less than 10 characters.

and it took about 2 minutes to show up in IE on a decent machine with 2 Gig ram.

the XDP file itself is about 280K in size.

any recommendations on how to speed it up please?


5 Replies


Not applicable
This slowness really puzzles me... because I just tried hard-coding the data and ran it on a local Turnkey version of LC-ES, and the form got loaded rather quickly. Could somebody shed some lights on this please?

here's what happens:

on my fast version, it uses the same XDP that has 11 dropdown fields. and in the "ready:form" event, I have this piece of Java Script running at Client:

var astrChoiceList;

var choices;

// Clear drop-down list box












astrChoiceList = "0002,0003,0004,0005,0007,0008,0009,0010,0011,0012,0013,0014,0015,0016,0017,0018,0019,0021,0023,0024,0025,0026,0027,0028,0029,0031,0033,0034,0035,0036,0037,0038,0039,0040,0041,0042,0043,0044,0046,0047,0049,0050,0051,0053,0054,0055,0056,0057,0058,0059,0060,0062,0063,0069,0070,0072,0073,0074,0075,0077,0078,0079,0080,0081,0082,0083,0084,0085,0086,0087,0088,0091,0092,0093,0095,0096,0097,0098,0099,0100,0103,0104,0105,0106,0107,0108,0109,0110,0111,0112,0113,0114,0115,0116,0117,0118,0119,0120,0121,0122,0123,0124,0125,0126,0128,0129,0130,0134,0135,0136,0137,0138,0139,0144,0145,0146,0147,0148,0149,0150,0151,0153,0154,0155,0156,0157,0158,0159,0160,0162,0163,0164,0165,0166,0167,0168,0169,0171,0172,0173,0174,0175,0176,0177,0178,0179,0180,0181,0182,0183,0184,0185,0186,0187,0188,0189,0190,0192,0193,0194,0195,0196,0197,0198,0199,0200,0201,0202,0203,0204,0205,0206,0207,0208,0209,0210,0211,0212,0213,0214,0215,0216,0217,0218,0219,0220,0221,0222,0223,0224,0225,0226,0227,0228,0229,0230,0231,0232,0235,0236,0249,0251,0252,0253,0254,0255,0256,0258,0259,0260,0261,0262,0266,0267,0268,0269,0270,0271,0272,0273,0274,0275,0276,0277,0278,0279,0280,0281,0282,0283,0284,0285,0286,0287,0288,0289,0290,0291,0292,0293,0294,0295,0296,0298,0299,0300,0301,0302,0303,0304,0305,0306,0307,0308,0309,0310,0311,0312,0313,0314,0315,0316,0317,0318,0319,0320,0321,0322,0323,0324,0325,0326,0327,0328,0329,0330,0331,0332,0333,0334,0335,0336,0337,0338,0339,0340,0341,0342,0343,0344,0345,0346,0347,0348,0349,0350,0351,0352,0353,0354,0355,0356,0357,0358,0359,0360,0361,0362,0363,0364,0365,0366,0367,0368,0369,0374,0375,0376,0377,0378,0379,0380,0381,0382,0383,0384,0385,0386,0387,0388,0389,0390,0391,0392,0393,0394,0395,0396,0397,0398,0399,0400,0401,0402,0403,0404,0405,0406,0407,0408,0409,0410,0411,0412,0413,0414,0415,0416,9002,9003,9017,9018,9019,9021,9022,9023,9057,9062,9070,9071,9072,9073,9074,9077,9078,9082,9093,9127,9134,9140,9141,9142,9143,9160,9161,9168,9183,9191";

// add each choice to the dropdown list

choices = astrChoiceList.split(",");

var numchoices = choices.length;

for (var i = 0; i < numchoices; i++) { P1.CompanyCode.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode1.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode2.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode3.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode4.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode5.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode6.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode7.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode8.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode9.addItem(choices[i], choices[i]); }

for (var i = 0; i < numchoices; i++) { P1.Cocode10.addItem(choices[i], choices[i]); }

as I mentioned, the "astrChoiceList" variable is hard-coded with some data as you can see above.

The process is the standard "Render PDF Form" in the Samples.

and it worked pretty quickly. there was no slowness.

However, in the slow version, it has the same fields, the only differene is that the "astrChoiceList" variable is not hard-coded, it's like this:

astrChoiceList = P1.fieldName.rawvalue;

the data is stored in a hidden field called "fieldName".

the rest of the script is exactly the same as the fast version.

The process for the slow version uses a custom Render service. That Render service queries a database table to get the data, and put it in the hidden field "fieldName". The rest of process is identical to the "Render PDF Form" in the Samples. The data taken from the database is identical to the hard-coded data in the fast version.

I cannot figure out why these differences would cost the slow version 2 minutes slower in loading the form. Could somebody tell me why?




Not applicable

Not knowing anything about your custom render function, can you perform your database call before the form is rendered, and merge your data with the SQL Query for Multiple Rows as XML and Set Value QPACs? Then perform the default render to create your form. I'm wondering if the slowness is coming from your custom component, as it is another difference between your two described render processes.


Not applicable
Actually, I think I have found the cause to this problem. My previous posting has missed one thing... (I will describe below)

The slowness was not caused by database interaction, because I have performed more tests after my last posting, and I have taken out everything in the slow Render service, it has the exact same steps/actions as the Sample Render, but the hard-coded form still came out more than 1000% slower.

The difference between the slow version and the fast version is this:

in the slow version, the 2nd step (named "render Form") of the "Render PDF Form" service has the input parameter "Render at Client" set to "No".

The fast version, uses the out-of-the-box Sample Render PDF Form service, has it set as blank/nothing.

At least two other people have reproduced this slowness on their LC-ES. It's very easy to reproduce it, all you need to do is to change that one input parameter.

So, you might say, why set it to "No"? The problem is that, if you don't set it to "No", your form will not work with the Reader even if you put the UsageRights action in your Render service. The form when loaded in the WorkSpace will behave as if it's not Reader-Extended even if you have applied the UsageRights. -- (there's another post in the forum about this problem)

I have filed a case with Adobe's Tech Support about this issue, case number is 180142615. It has been escalated to Tier-3 (or higher) of Adobe's Support organization.


Not applicable
I got a response from Adobe, I thought people might want to know.

As described in previous postings, my Render service was based on the "Samples - Forms - Render PDF Form"; and the issue was that, in order for that to work with the Reader, you need to set the "Render at Client" parameter to "No" (the default was blank).

However, once you set it to "No", you will get a performance problem. Some of your forms may be very slow in coming up into WorkSpace.

And, the solution is, DON'T model your custom Render after that Sample!

Apparently, there are other ways to render your forms that can both work with the Reader and be fast.

[[[Unfortunately, all the documentation/samples/forum-postings I have read so far have referenced that Sample Render, now I have to change everything I did. Argh!]]]

My advice is, unless you have Acrobat Pro on every desktops, be careful in modeling your Render service after that Sample Render PDF Form! Thank you.