"I try creating a folder in the user's documents folder, but it fails.
Disabling protected mode fixes this problem."
This issue you are experiencing is not a matter of being signed, or not
signed. It's Vista and IE7 permission levels to run elevated tasks from
within IE7 while in protected mode. All ActiveX is given the lowest level of
access until installed properly while in Protected Mode. (Hence, it works
when not in protected mode.) This lowest level means any functions called
requiring higher elevation fail unless the user acknowledges the task as
appropriate. The user will not receive a prompt unless the installation
follows the required protocols. Without the prompt, this simply fails to
So, there are two areas of concern:
First, assuming the user gets a prompt, is the "silent failure" caused when
the user may have moved their Documents folder away from the default. As a
result, the XP/2000 commands may not work in Vista and attempts to write to
the Documents folder may produce Error 1320 (if ran as administrator), or no
errors posted (if run as user):
Second, creating a folder in a user's profile (Documents folder) is an
elevated task (as is registering the DLL), so I mentioned brokering
services. Please see the following link on this functionality while in
I suspect, the second article is closest to your solution. (I only mentioned
the external executable because on occassion, DLLs have been known to seek
Using the following search on MSDN, I found 147 hits: (broker activex dll
The links provided in the other messages give more information on this path.
(I'll let someone else chime in since I'm running into a dead end for you.)
<email@example.com> wrote in message
This is a single DLL plugin, inside of a signed CAB file. No external
executables are called, nor would I want to. If I ended up having to
call an executable, then there would be no point to using the DLL in
the first place.
I try creating a folder in the user's documents folder, but it fails.
Disabling protected mode fixes this problem. So it appears the
problem, really, is protected mode completely ruins the benefit of
using signed plugins.
I'm not sure what ActiveX brokering is. Google comes up with 0 hits
that actually relate ActiveX DLLs and brokering.
Thank you though for your help.
On Jan 30, 2:39 pm, "Mark" <jmhonz...@nospam.insightbb.com> wrote:
> I will assume the ActiveX installation troubleshooting on page 78-82
> help either.
> Which would have led you
> Pay special attention to finding Vista folder paths.
> Additionally, ActiveX needs to use Brokered Services for elevated
> (I don't know which of these really apply, but there is a generic theme
> related to your problem.)
> Or, possibly:
> In Vista, with UAC enabled, IE will refuse to run any code not packaged in
> the CAB file.
> If the hook statement contains a parameter with path, you need to put
> double quotes around the EXE.
> For example:
> run="""%EXTRACT_DIR%\PrepareInstall.exe""" %OBJECT_DIR%
> (This will work in XP and 2000 also.)
> <shala...@gmail.com> wrote in message
> Hi Mark,
> Thank you for this document.
> Neither the Visual Studio 2008 automatic manifest insertion via Linker
> options, nor a manually inserted manifest resource causes a UAC popup
> to occur (as hoped). I have tried the three obvious parameters:
> asInvoker, highestAvailable, requireAdministrator.
> - Shawn
> On Jan 30, 7:20 am, "Mark" <jmhonz...@nospam.insightbb.com> wrote:>
Starting on page
> > <shala...@gmail.com> wrote in message
> > > With Protected Mode enabled, our signed plugins no longer operate as
> > > they should due to limitations on where they can write files, etc.
> > > Is there any way to get around this programmatically, without the
> > > user
> > > having to disable Protected Mode manually?
> > > I must admit that I appreciate Microsoft's continued efforts
> > > regarding
> > > security, but the entire point of having signed plugins was so that
> > > the user could explicitly grant trust to the plugin. Unsigned plugins
> > > were not allowed by default in IE6. I'm not sure who thought that was
> > > inadequate.
> > > - Shawn