Adobe X Enable protected mode on startup - disable using code

Question

Our application, written in Delphi, generates a series of reports, most of which are then in PDF format, which opens automatically when it is created. Adobe X introduced a feature that is enabled by default, "Enable protected mode at startup." PDF report files are opened using ShelExecute.

var pdfFile: string; begin pdfFile := 'C:\Users\Ronaldo\Documents\appName\reports\file.pdf'; ShellExecute(0, 'open', PChar(pdfFile), '', '', SW_SHOW); // end; 

Due to this new new option in Adobe Reader, under Win 7 or Vista, we get an error message when opening a document. Double-clicking on a document to open it does not cause any problems. Is there a way to disable a protected method - or another way to open a document without getting an error (workaround)?

* Additional Information *

A PDF file is created on our server application, streamed to the client, and the client generates pdf (using Write). At first I, although this may be a problem, but again, why double-clicking works fine.

I created a dummy application that does nothing but uses the same code above to open pdf and it works. I checked the privileges of the application - anyway - the only difference is that the one that does not work is installed in the OS using the appropriate installer - the other (fictitious) that I just created and dropped it there.

One of the comments asks about file associations - this should not be a problem since the application successfully launches Adobe Reader - Adobe Reader then gives me a "denied access" error message. Double-clicking on the same file works fine.

New Information - 03/30/2011 - 14:50 - Time in New Zealand

I made changes to the code to check the only difference between the application itself and the dummy application. Instead of automatically getting the file path and file name, OpenDialog now opens - the Filename property for opendialog is used as a parameter for ShellExecute (as a comment after Ken's response states) - it works. Why does this happen when you get the file name from an open dialog, it works - note that I do not open the file from the dialog box - I get the file name and use it as a parameter for ShellExecute.

Updated sample code

When the user clicks the "generate report" button, the report opens automatically after its creation. In addition, there is a grid for this, showing all the generated reports, for this user, this is the double-click code for this grid:

 if GetSelectedReport <> nil then // this will check if the user selected an report if TReportItemState(GetSelectedReport.State) in [risGenerated,risViewed] then // checks if the report selected is in the correct state to be displayed. begin fileName := TClientReportManager.Singleton.Directory+'\'+GetSelectedReport.Filename; // a string with the filePath + fileName ShellExecute(0, 'open', pchar(fileName), '','', SW_MAXIMIZE); // command to open the file end; 

My first guess at the work of Opendialog is that an open dialog changes the CurrentDir. So I already tried SetCurrentDir and ChDir to change the current directory to the one where the files are. No success.

In Win 7, the file path is translated to C: \ Users \ Ronaldo \ Documents \ CompanyName \ AppName

Answer 1

I left this behind, but now I have time when I returned to try to solve the problem.

I found out that the client application uses GetEnvironmentVariable ('USERPROFILE') to get the part of the folder where the reports are located. This will give me something like "c: \ users \ user_name \" on Windows 7, and then add a constant with something like "My Documents \ CompanyFolder \ ProductFolder".

In win XP, this worked fine, but under Win 7 it seems that UAC for some reason will not allow you to directly and specifically refer to My Documents - instead, you need to use Documents.

I changed the constant to delete the "My Documents" part and added a function to retrieve the personal personal document folder using the CSIDL_Personal parameter and the function:

 function GetSpecialFolderPath(folder : integer) : string; const SHGFP_TYPE_CURRENT = 0; var path: array [0..MAX_PATH] of char; begin if SUCCEEDED(SHGetFolderPath(0,folder,0,SHGFP_TYPE_CURRENT,@path[0])) then Result := path else Result := ''; end; 

and calls a function of type GetSpecialFolderPath (CSIDL_Personal).

Thank you all for receiving comments and answers.

I just want to add that this answer is the correct answer in my case. It may be that @Ken White's answer is the right answer for someone else.

Answer 2

I do not think you can completely disable it in the code; If you could do this, it would surpass all the goals of Protected Mode (preventing the use of malware to associate .pdf files). However, you can work on this legal way. :)

I suspect this is due to the open verb that you use with ShellExecute . You assume (possibly incorrectly) that the verb open does the same thing in protected mode on Win7 as in previous versions of Adobe Reader and Windows. ( NOTE : I do not have such a version of Acrobat installed on my system, these are all assumptions.)

The first thing I will try is to change the ShellExecute call as follows:

 ShellExecute(0, nil, PChar(pdfFile), nil, nil, SW_NORMAL); 

The first change is to pass nil as the second parameter. This tells Windows what you want it to happen by default. It could be, for example, view instead of open .

I also changed two parameters after the file name to zero. This is more readable than using an empty string ('').

The final change is in the last parameter; I usually use SW_NORMAL instead of SW_SHOW , simply because it tells Windows to show it regardless of its default size and position; it may be something saved by the application and enforce user settings (if any).

If this does not work, the time will come to scroll ( carefully !! ) in the Windows registry. Open regedit in the Start menu search and go to HKEY_CLASSES_ROOT. Scroll through the list of files until you find an entry for .pdf and double-click this branch. You will see Default , which (on my system, anyway) AcroExch.Document with Content Type from application/pdf .

Continue down the tree in the left pane until you find AcroExch.Document , and expand it. You will see several values ​​(again, from my car), as you can see in the image below. Expand the Shell branch and you will see certain verbs, as well as the command associated with them. On my machine (again) I have one verb open , the command of which is set to "C:\Program Files (x86)\Adobe\Reader 9.0\Reader\AcroRd32.exe" "%1" .

(The bear is with me - we are almost there. I promise.)

You can see that double-clicking does differently, learning the default value (click Shell in the left pane, and then see what is set as (Default) to the right. Then look at the command line (in the second image above, it's open ), to see which switches, if any, are transferred to the Acrobat Reader application (if you cannot determine which one by default, right-click the .pdf file in Windows Explorer and see if the bold item is in the context menu.)

If a parameter other than "%1" passed, you need to add the same parameter to the command line provided in ShellExecute . For example, if the option is /v , you should change your call to ShellExcute something like this:

 ShellExecute(0, nil, PChar(pdfFile), PChar('/v'), nil, SW_NORMAL);