I guess this is a provocative question that need a background to be clarified before proceeding.
Recently an old idea popped out to my mind again, I decided to try to make it real.
Basically speaking I wanted Acrobat Reader to persist the page I'm in when I close the reader. (of course the idea is more than that, but this is all you need to know for the matter of this post).
So it's sound rather easy, quick enough I had Acrobat Reader ActiveX control embedded inside my app showing a pdf. I was happy, so far so good.
Next step get to know the current page of the document.
well, here things got more difficult.
Browsing through the methods and stuff I've got from Intellisense brought up many useful things such has setCurrentPage, GotoNextPage, etc, and yet no getCurrentPage or a similar name.
I figured out that I must have missed something, information from search engines didn't quite get me to what I need.
Began to research the ActiveX Api, nothing.
I began to understand that this is going to be a long and frustrating day, because the API just don't give you this kind of information.
I posted up a question in Adobe forum and resolved to get this data by brute force.
And actually I did manage to get it by using extremely ugly ways of memory manipulations. Unfortunately (or fortunately) Acrobat Reader may open few documents in the same process and I couldn't correlate between the memory data and the document, so I regarded this to be a dead-end and either way it is a really not recommended procedure - but I just need this page number, why can't he just give it to me?
(and as a side note I know more ugly ways I could have done)
Meanwhile back at Adobe town, I've got a reply from one of their moderators I suspect.
The answer I got is that this data is a deliberate limitation of Acrobat Reader; you want more abilities make your client buy Acrobat Standard or Professional.
Here is the exact quote:
"One reason could be the deliberate limitation of Adobe Reader to what
is needed to just be a viewer (perhaps with external navigation). To
go further, e.g. to provide feedback to use PDF files in a more
powerful way, maybe Adobe want to sell Acrobat. Just a thought."
Well this "thought" actually got me thinking, more on the business aspects of such policies.
Adobe want to sell Acrobat (Standard or Professional) this is very legitimate, but what is more profitable, making poor developers as me that want to develop a rather basic feature for the benefit of Adobe as well, the more products that use PDF the happier Adobe should be and thus increase their profits from selling PDF related products or by the direct revenues from products that must need an Acrobat product that need license.
Anyway Adobe choose the 2nd option: Instead of supporting development of PDF oriented solutions, it is doing the opposite, hindering it by limiting the API.
I am not a business analytics, maybe Adobe is right.
But think that .net would have come in two packages one is limited and one is fully functional only after you client pay microsoft more money he can use your application.
of course I'm simplifying here, Microsoft has already made a profit from the OS itself and related products of Windows, but it's not a far cry, they could have walked that road.
Thankfully they haven't and my application is now using XPS.
Feel free to actually answer the question raised by topic, I've just supplied the context, background and some provocative rhetoric, feel free to add your own vote :)
Ariel