Discussion:
Problem with -DDE and Adobe Reader (again)
Ulrike Fischer
2014-03-29 13:37:02 UTC
Permalink
Normally I use sumatra for the pdf preview but I also have to use
the adobe reader sometimes e.g. to check form fields.

I'm using winedt Build: 20131031 (v. 8.1) - 64-bit on a windows 7
system. Adobe Reader has version 11.0.06.

Since a few weeks I have problems with PDF search.edt. It doesn't
matter if I call the script through the shortcut (ctrl + ä in my
case) or through the menu.

I get the error
******************************
Cannot Open DDE Link to:
"C:\Program Files (x86).... \AcroRd32.exe
Service:
Topic:

DDEOpen("%$('PDF-View');","%$('Acro-DDE_Service');","...
********************************

and PDF Search.edt opens and highlights line 105.

DDEOpen("%$('PDF-View');","%$('Acro-DDE_Service');","%$('Acro-DDE_Topic');");

Despite the error message the pdf is opened in the adobe reader.
Sometimes I get the "language dialog" of the reader.

I got around the open problem by using pdf preview when Adobe is the
active viewer:

MACRO="IfStr('%$(|UFpdf|);','Adobe','=',|Exe('%b\Exec\PDF\PDF
Preview.edt');|,|Exe('%b\Exec\PDF\PDF Search.edt');|);"

(UFpdf is a variable which holds an information about the viewer on
my system).

But then I get the same error message for PDFCloseDoc.edt when
trying to close the pdf before pdflatex is run ;-(

I have no idea which change/update has triggered the problem.
So what can I do? (Beside closing the reader manually every time).



Btw: I doubt that winedt can do something about it, but I also ran
into the problem that the pdf file preview of the windows explorer
did block a pdf so that pdflatex couldn't write on it.
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
WinEdt Team
2014-03-29 16:27:12 UTC
Permalink
Ulike,
Post by Ulrike Fischer
Since a few weeks I have problems with PDF search.edt. It doesn't
matter if I call the script through the shortcut (ctrl + =E4 in my
case) or through the menu.
I get the error
******************************
"C:\Program Files (x86).... \AcroRd32.exe
DDEOpen("%$('PDF-View');","%$('Acro-DDE_Service');","...
********************************
and PDF Search.edt opens and highlights line 105.
I have no idea which change/update has triggered the problem. So
what can I do? (Beside closing the reader manually every time).
If my memory serves me well you have created custom ways of
switching PDF preview. It appears that you forgot to initialize
Acro-DDE_Service and Topic variables when you switch to Adobe.
That's why DDE (required for closing and forward search) fails for
you (they are empty in the above report).

If you switch the previewer through Execution Modes Dialog this
will likely get remedied because the interface will call the
required macros.

In particular, the macro %B\Config\Adobe.edt initializes these
variables. It should be called if you switch PDF Viewer to Adobe.

Something like this will work with version 11 if you want to do it
manually:

Assign(!"PDF-Caption",!"Adobe Reader");
Assign(!"Acro-DDE_Topic",!"Control");
Assign(!"Acro-DDE_Service",!"AcroviewR11");
Post by Ulrike Fischer
Btw: I doubt that winedt can do something about it, but I also ran
into the problem that the pdf file preview of the windows explorer
did block a pdf so that pdflatex couldn't write on it.
I think that initializing the above variables will solve the
"problem". The rest depends on how you have customized switching
between previewers without using Execution Modes Dialog. They are
no initialized because of some customization on your part...

Best regards,

alex
Ulrike Fischer
2014-03-29 17:07:30 UTC
Permalink
Post by WinEdt Team
Post by Ulrike Fischer
I have no idea which change/update has triggered the problem. So
what can I do? (Beside closing the reader manually every time).
If my memory serves me well you have created custom ways of
switching PDF preview. It appears that you forgot to initialize
Acro-DDE_Service and Topic variables when you switch to Adobe.
That's why DDE (required for closing and forward search) fails for
you (they are empty in the above report).
Hm. Yes I have a custom way. But why does it break now? I made the
changes at the start of the last year.
Post by WinEdt Team
If you switch the previewer through Execution Modes Dialog this
will likely get remedied because the interface will call the
required macros.
Yes changing through execution modes works.

And now I have also an idea why it suddendly broke: I think some
weeks ago I decided to make sumatra the default viewer at startup.
And so the adobe.edt has no longer be called.
Post by WinEdt Team
In particular, the macro %B\Config\Adobe.edt initializes these
variables. It should be called if you switch PDF Viewer to Adobe.
Post by Ulrike Fischer
Btw: I doubt that winedt can do something about it, but I also ran
into the problem that the pdf file preview of the windows explorer
did block a pdf so that pdflatex couldn't write on it.
I think that initializing the above variables will solve the
"problem". The rest depends on how you have customized switching
between previewers without using Execution Modes Dialog. They are
no initialized because of some customization on your part...
Adding Adobe.edt to the switching command helped. It also helped
with the windows explorer problem -- but only if adobe is the active
viewer. Can something be done so that the preview in the explorer is
closed in the other cases too. And do the other viewers need some
initialization too? The current version of my popup command is this:

SUBMENU="&Viewer"
ITEM="UF-Acrobat"
CAPTION="&Acrobat"

MACRO="Exe('%b\Exec\PDF\PDFCloseDoc.edt');Assign('PDF-View','%$(|PDF-View1|);');Exe('%b\Config\Adobe.edt');Assign('UFpdf','Adobe');SetInfo(1,'%$(`UFTeX`);-%$(`UFpdf`);','');"
ITEM="UF-Sumatra"
CAPTION="&Sumatra"

MACRO="Exe('%b\Exec\PDF\PDFCloseDoc.edt');Assign('PDF-View','%$(|PDF-View3|);');Assign('UFpdf','Sumatra');SetInfo(1,'%$(`UFTeX`);-%$(`UFpdf`);','');"
ITEM="UF-TeXworks"
CAPTION="&TeXworks"

MACRO="Exe('%b\Exec\PDF\PDFCloseDoc.edt');Assign('PDF-View','%$(|PDF-View2|);');Assign('UFpdf','TeXWorks');SetInfo(1,'%$(`UFTeX`);-%$(`UFpdf`);','');"
END="Viewer"
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
Pétiard François
2014-03-29 17:07:21 UTC
Permalink
Hello

Le 29/03/2014 17:27, WinEdt Team a écrit :
....
Post by WinEdt Team
Assign(!"PDF-Caption",!"Adobe Reader");
Assign(!"Acro-DDE_Topic",!"Control");
Assign(!"Acro-DDE_Service",!"AcroviewR11");
Are you sure of "AcroviewR11"?
On my computer, Adobe Reader XI is installed and the two registry keys
where I can see AcroView are:

HKCR\acrobat\shell\open\ddeexec\application
HKLM\Software\Classes\acrobat\shell\open\ddeexec\application

and the value is "AcroViewR10"

François
WinEdt Team
2014-03-29 17:56:28 UTC
Permalink
Fran=E7ois,
Are you sure of "AcroviewR11"? On my computer, Adobe Reader XI is
HKCR\acrobat\shell\open\ddeexec\application
HKLM\Software\Classes\acrobat\shell\open\ddeexec\application
and the value is "AcroViewR10"
I am quite sure as with my Reader XI DDE works with AcroviewR11 but
fails with AcroviewR10.

The registry indeed contains the wrong value. Even for Adobe 10 it
did not contain the right one. That's why I call it "Adobe
Blues"...

Adobe.edt contains this comment and you can check the thread on
problems with Adobe (as encounter by other non-WinEdt users):

// Adobe Blues: Registry does not contain proper value for Adobe X!
// http://forums.adobe.com/message/3323310

Consequently, WinEdt's macro Adobe.edt ignores this value (since it
is wrong) and append the version automatically. But there is no
telling if this, too, will fail in future versions of Adobe...

Best regards,

alex
Pétiard François
2014-03-29 18:02:36 UTC
Permalink
François,
Are you sure of "AcroviewR11"? On my computer, Adobe Reader XI is
HKCR\acrobat\shell\open\ddeexec\application
HKLM\Software\Classes\acrobat\shell\open\ddeexec\application
and the value is "AcroViewR10"
I am quite sure as with my Reader XI DDE works with AcroviewR11 but
fails with AcroviewR10.
The registry indeed contains the wrong value. Even for Adobe 10 it
did not contain the right one. That's why I call it "Adobe
Blues"...
Adobe.edt contains this comment and you can check the thread on
// Adobe Blues: Registry does not contain proper value for Adobe X!
// http://forums.adobe.com/message/3323310
Consequently, WinEdt's macro Adobe.edt ignores this value (since it
is wrong) and append the version automatically. But there is no
telling if this, too, will fail in future versions of Adobe...
Best regards,
alex
OK, thank you.
I must admit I've not seen the macro Adobe.edt (I use Sumatra as viewer
when I latex, because inverse-search...).
I thought you took the value in the registry.

Best regards

François

Loading...