On Wed, 5 Apr 2006 11:55:18 -0600, "Waldemar Osuch" <[EMAIL PROTECTED]> wrote:
>I know Dispatch used to work with the Reader. Did Adobe broke the >Reader to force us to pay for the full version or is it pythoncom at >fault here? The Acrobat 5 Reader exposed an AcroExch.App object, but (according to Google) was an accident. They didn't mean to expose that unless you had purchsed the full product. >But then again I have working .Net application that uses Reader to >display files. >I did not write the .Net one so do not ask me how it does it :-) . >But I do have source and could try to find out. That would be interesting to know. If it is using it as a hosted ActiveX control, rather than a simple COM object, that could be the difference. >>> The Acrobat ActiveX wrapper in wxPython explodes with version 7, deep >>> within Acrobat, where it has never done so before. The problem has not >>> been isolated yet. > >It is the same issue. I think. The failure mode is different. The AcroPDF.PDF / LoadFile thing crashes very early, only about two calls deep into acropdf.dll, dereferencing a null pointer. Is it possible that the LoadFile API requires some other parameter that is defaulting to NULL? >>> >>> The only reliable and portable way to do what you ask is to fire up the >>> reader from a command line. > >Yes but then you can not control it at all. There is a command-line parameter asking it to print the file immediately. For many purposes, that is enough. -- Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
