Richard Cornford said:
*If* you really can get users to allow the execution of the ActiveX
shell object (the one that, if allowed to run from a remote web site,
allows the formatting of hard disks, the running of any and all
applications/DLLs and the re-writing of the registry: So anyone who
allows this is _so_ stupid that you really should exploit the
opportunity to the fullest and give yourself unlimited remote access the
their computer so you can take advantage of them fully at a later date)
then you can read and write registry keys. The offending key is a mass
of hex code, but if you can find out which bits represent the folder
settings in question you certainly could work out the user's current
configuration. (you can deduce the bits by recording the value, changing
settings - re-recording and comparing the results (assuming you cannot
track the details down in Microsoft documentation)).
Yes, Richard, I know if I go through the documentation eventually I
find the combination I need. Just wondering if anybody has done the
same maybe I can save some time. All I need is basically the
properties to call to determine if that Windows Classic Folders is set
or not.
My security settings will not even prompt me when such an ActiveX
request is made, they are disallowed silently.
The users of this application must have this setting to, at the very
least, PROMPT. I should have mentioned this is a very specific web
application, needs Explorer 5.5 or superior, and the site needs to be
added to the Trusted Sites list.
Need seems to be expressed much more often than it exists. On the face
of it this sounds incredibly wrong, in attitude and approach.
But even if it can be done you are going to need quite a bit of
additional knowledge to be in a position to work out the location of
anything on Windows, it is a very user configurable operating system (in
terms of such things as icon and text size, window borders, and much
else) and there is variation between versions.
And what are you planning on covering it with?
What I'm using here are FTP folders, inside frames and or iframes.
This way the user can drag and drop files to the application, with all
the beauty of FTP progress bar, reliability, etc. No ASP upload or
dll upload or stuff like that. The files are then immediately picked
up by the web application from the user temporary FTP folder (created
on the fly) and then moved to the appropriate destination folder.
(This is in part a document management web based solution)
So far this sounds like solving the wrong problem (assuming it works),
alternative suggestions can only follow from identifying the real
problem, which would probably be best done by your answering the
question: Why? (Why do you perceive the web folder area as a problem?)
Richard.
By using these FTP folders I am faced with the problem of some users
who have the setting of "Enable Web Content" who also get the
directory listing in the left side of the FTP view pane. No matter
what amount of explanation we put there, the user who thinks along
these lines:
- "because *I* want it that way. Its *my* browser, leave it the @#$@
alone. Design your page to look the way you want it, on its own, and
let the user decide what views are used." - in their infinite wisdom,
try to browse this tree in order to get the files, instead of dragging
them from windows explorer as it says in the page's instructions.
So, my solution although klumsy (but it works) is to user a popup
window that always covers the left area of the FTP folder view. So
the user cannot interact with it. The right area is left untouched,
so files can be dragged and drop there. But because some users ARE
using Windows Classic Folders, they do not need to have the left area
covered. I need to determine that somehow or the files they drag and
drop will appear "hidden" behind the popup.
Was I a bit clearer this time?
Thanks Richard