I have a question:
VC++ v6.0 w/MFC is my langauge":
In my code, when I shell out to run "printto" in version 9, it works just fine, but when I shell out to run "printto" in version 10, it does not send the information to the selected printer at all. If I then de-install Reader X and re-install version 9, it works perfectly again. I can run the same test against locally installed printers both LPT and USB, network printers, and even shared printers on neighboring desktops. Identical results.
In my code, I monitor the printer queue, and I can verify that it never shows up. There is no change in my code between the two versions. One works and the other doesn't. No change in client computer or configuration either, other than Acrobat Reader versions.
Could this somehow be due to DDE Server Application names changing?
Sample Code:
// szExecVerb = "printto"
// lpszFile = full path to the pdf file name
// lpszExecParam = "<printer_name>" "<driver>" "<port>"
// ##Example: "network_printer50" "spooler" "ne04"
// Whatever it is, it is identical when running with Acrobat Reader version 9 vs Reader X.
// Also, these parameters are validated and traced.
//launch the application to print the file
SHELLEXECUTEINFO sei;
memset((LPVOID) &sei, NULL, sizeof(sei));
sei.cbSize = sizeof(sei);
sei.fMask = SEE_MASK_NOCLOSEPROCESS | SEE_MASK_FLAG_DDEWAIT | SEE_MASK_DOENVSUBST;
sei.lpVerb = szExecVerb;
sei.lpFile = lpszFile;
sei.lpParameters = lpszExecParm;
sei.nShow = SW_MINIMIZE;
BOOL fSuccess = ShellExecuteEx(&sei);
I then wait for the document to show up in the selected printer's queue. Needless to say it never shows up when using Reader X, but works fine in Acrobat Reader version 9.
Anything you might offer could be helpful. Are others not having this problem?
Is there anything I else I could provide to help with figuring out why it just stops working?
Thanks Irosenth, I appreciate the response.
I did catch that the DDE names had changed. I was confused, prior to your reply, whether that applied to shelling out also. Thanks for clearing that up.
Quick follow up:
If I was creating my own DDE conversation, I could programmatically figure out which DDE name to use, but I am currently only shelling out. Is there something that I can do to to make ShellExecuteEx work again, or do I need to roll my own DDE conversation handler to use the standard context verbs (print, printto, read), and dump the use of just shelling out?
Obviously the "open" verb works just fine. Thanks again for taking the time.
I agree. I am writing one at this moment. It does take a bit to make it as robust as it needs to be for production. I am having a couple of problems like failing to connect to Acrobat Reader 9 even though I have all of the correct parameters, but I have just started. That is, of course, a discussion for another thread if I can't solve it.
But just so I am clear, you are saying that Reader 10 does not support ShellExecuteEx?
. . . or is there something I can do to allow it work, unreliable as it may be?
Any chance for an answer? I will rephrase it for clarity.
Is there anything I can do to allow the use of ShellExecuteEx with the "printto" verb? It works fine with the "open" verb but not the "printto" verb.
When using ShellExecuteEx, you don't have an option of modifying the DDE Server Application Name.
Interesting turn of events. Thought I would come back and post what I found as the final solution at least for me.
I got reports that customers using an older version of my application were able to successfully print using Adobe Reader 10.1.3. In this area of the code, I have always used the above code using "printto". The biggest difference between this older version of the application and the current one, is that the current one was compiled as a UNICODE application.
So I continued looking at possible UNICODE differences between these two versions of my applications that might help.
Since DDE conversations had changed between the two Reader versions, I of course focused on this, but was able to add UNICODE to the search.
I found that there is an additional flag you can add to the ShellExecuteEx method call. It is SEE_MASK_UNICODE to alert the DDE that a UNICODE application is requesting the connection/data, used especially when shelling out for applications that use DDE conversations. This one isn't really explained in the older C++ help files. Voila!
Changing this line above to:
sei.fMask = SEE_MASK_NOCLOSEPROCESS | SEE_MASK_FLAG_DDEWAIT | SEE_MASK_DOENVSUBST | SEE_MASK_UNICODE;
caused it to start working aginst 10.1.3.
Now, I can't say definitively why my UNICODE application worked just fine against Acrobat Reader 9.0, but not against 10, but I suspect it has something to do with the DDE changes.
Maybe Irosenth could confirm?
North America
Europe, Middle East and Africa
Asia Pacific