app.hideToolbarButton

First of all, you have an error in your script. It needs to be:
console.println(toolbarItems[i] + "\n")
and
console.println(menuItems[i] + "\n")
(you're currently missing the [i])

The Toolbar Buttons list returned in Reader is empty. These items can no longer be controlled via a script.
The Menu Items list contains "Print" and "Save", as expected.

Hi,

this may be something for you
http://acrobatninja.blogspot.com/2011/03/enterprise-toolbar-customization-in.php

Can anybody explain why Adobe has removed configurability options in Adobe Reader 10.0.1 that have existed in previous versions?

And also, why was the example on how to use it (even though it doesn't work anymore) was left unchanged in the JS Developer Guide in the SDK of version 10 (p. 147)?

The UI in the Acrobat X Family follows the basic rule that aside from enterprise deployment (via the Customizer or registry keys) only the user gets to modify the toolbar entries, and only via manual decisions on the UI (contexts and drags). Any automated system (plugins, scripts, etc.) will have any toolbar-related drawing functions directed to a custom panel in the Tools Pane. They can still write to the menu tree if they want, but the system toolbars are now entirely fixed - the user can turn entries off and on but can't move them about, re-dock subpanels, etc. and plugins/scripts have no access to the System Toolbars whatsoever. It also reflects the shift of logic that the Panes are now where all the fun stuff lives, so the toolbars are really only there for the basic navigation buttons and a library of things you use very frequently (i.e. Quick Tools).

From what I've heard the reasoning is about keeping the "default" UI as fixed as possible, so users in a multi-workstation environment see a recognizable UI every time (remember Acrobat is an enterprise product). Reader does what Acrobat does, because that's how the Family is written.

Users can play about with their toolbars but as that's an account preference, multiple users on a system don't care what's been done by others. All plugins and scripts dump their buttons to the Tools Pane so users should get used to going there for anything they've just installed, and if they want to move a button into Quick Tools they can. IT can pre-populate the Quick Tools area in both Acrobat and Reader, but primarily it's the user who gets to decide which buttons he/she has up there.

Not everyone will agree that's how they want it to be, but that's how it is.

The Developer Guide wasn't entirely redone for Acrobat X so there are sections in there which are only relevant to previous versions (for example we have examples of controlling legacy media even though you can't author it anymore). I agree the version applicability needs to be clarified.

UVSAR, I can appreciate Adobe's direction but I do question it. They have removed the ability to deploy a locked down version of Reader. These capabilities have existed in previous versions and keeping them as an available option would not have reduced their product. If a company had decided to not employ the lock downs they would have had that option. Sadly for those of us that do want things locked down we no longer have that option. In general it is better to provide for more options not less, especially when it's an enterprise product.

I imagine the line will form to the left of people that would like to see this added back so that they have a few extra tools in their arsenal but that's just my 2 cents.

As per previous posts - I am questioning the logic (and sanity) of you guys wanting to disable such items as printing and commenting. I have not hear what amounts to a clear business reason for doing so.

We lock out such items as Acrobat.com* and other web services for two business reasons 1) They are outside of our security influence 2)They cost money that we do not wish to spend.

* The lock-out only extends to our colleagues initiating the services. They can still participate in Acrobat.com services if initiated by someone else.

I am sure that if you were able to provide some clear business reasons as to why you want to do this (sorry, the blanket locking out your employees ability to print is not generally considered a business reason) Adobe may listen and add such items to Customizer. I know they did when I, among others, presented such a case with Acrobat.com.

(Note: I do not work for Adobe Systems and am not speaking for them - the below is only a terse parody of my imagining what the conversation might look like.)

Here is a sample discussion - just to help you out..
You - We don't want them to print because the data in the documents is confidential.
Adobe - Then secure the documents so they can't be printed.
You - Our tools don't allow us to set this when the document is created.
Adobe - Our tools do.

My point is, that if you want to effect such change you need to have a business reason to do so. 90% of such requests are simply because folks do not want to take the time to properly learn their business, learn their employees, train their leadership, etc. They are just some gut reaction and have no basis or foundation in reality.

I suggest you start asking some questions as to WHY you need to do this. What is the business driver? and work from there.

Thanks

Doug

Doug, I hope you realize you're talking to users here, not Adobe developers (although there are some Adobe employees here.)

Gilad,

I am aware of that. I've had most of these questions asked of myself by my leadership. Yes, from the same folks that approve my pay.

They ask, can we do this, that or the other thing with Acrobat or Reader. And my first response is "Why are you wanting to do that? What's driving the action?" The exact phrasing of the question can be adjusted as needed.

If the questions are asked in an appropriate manner it will give you 1) the information you need to make an informed decision - many of them are usually just some manager or other higher ups' wistful thinking. It also provides you with an opportunity to counter misconceptions and half-truths. 2) Insight into the business. The second item is the gold in product management. Knowing how the business uses your product, how valuable it is, what it's pain points are, etc. allows you to anticipate issues during upgrades, maintenance patches and even suggest future product uses and enhancements to Adobe Systems.

@Josh - sorry if my comments were a bit terse. It's not my intention to be hostile but to challenge you as to why you need (not want) to do a particular thing.

Thanks

-Doug

Doug, no offense taken. My customer is a large airline that has customer facing devices. We have taken great pains to lock down the environment to prevent unauthorized access to not only the OS but also the web browser. In fact, we have replaced the Explorer shell with a custom shell that only includes access to applications required. Adobe has provided a way to lock down certain aspects of the Reader software but it would be nice if additional lockdowns could be employed when needed. In this case we have a button that allows a user to launch IE with no address bar. This forces them to the company's Intranet site but if they click a .PDF file and launch Adobe Reader and then launch the web driven options in Reader there is some concern the security of the device could be compromised. It is imperative that these locked down devices can ONLY view PDF files and not save them to the local hard drive, try to print them, open online help, etc. I am not sure this answers whey we need this functionality but I hope it does.

Management’s desire is to keep the environment as secure as possible and keep their support costs down. I am only trying to help meet those needs.

That's a logical impossibility. PDF files do not "stream" so they are *already* on the local drive, albeit in the cache folder.

You can prevent printing by removing all the operating system printers (the menus will still be there but won't be able to do anything). I can see no reason whatsoever for disabling the Adobe Reader help system, and it is not possible to remove the menu. You could redirect the domain to loopback if you insist, but the end result would be an error page in the browser. Adobe isn't going to go out their way to help make their product appear "broken"; they have a reputation to think about.

*SIGH* Look I wanted to know if a feature that Adobe has had for years was still available. In all of their infinite wisdom it appears that they have removed a feature that was well documented and used by many. I don't presume to know why they would take away instead of adding to their product but it appears they did. I'll find another way to fix what Adobe broke.

Josh,

Hence we learn from our children and ask the same question asked of us - why why why....

Kiosk is the key word here. In a kiosk environment all normal bets are off with how the universe works. Kiosks are havens of custom code, user interfaces and the like. With Reader it should be no exception. In short, throw Reader out the door, across the parking lot and into the ditch. That's the Reader UI, anyways... and build your own UI. Actually, it's not that hard - about 20 lines of VB code (I can be a bit sloppy at times) will get you started.

There are actually three components to the Adobe Acrobat / Adobe Reader SDK - The two most folks know about - JavaScript and Plug-in API. Then there is the IAC - the beast you want to tame. The IAC is the Interapplication Communications API. It allows you to add Reader functionality as a DDE/OLE interface into your application. In other words, it allows you to write your own Reader UI on top of the Reader application stack. A UI that does not have Save, Print, Comments or any other feature you don't wish to expose. But, such items you do wish, forward/back pages, zoom, etc. Sure. Read paragraph two here --> http://www.adobe.com/devnet/acrobat/interapplication_communication.phpSince you've already gone a long ways to create your own custom IE stack, adding Reader to that stack should be marginally extra effort.

OK Doug, where do I get this miracle tool? http://www.adobe.com/devnet/acrobat.php

Please keep in mind that since you are building a commercial application you will want to make sure that you follow along with any/all of Adobe's EULA and SDK license missives.

I hope this helps.

-Doug