Yep, but... you might want to make sure and wait for another member to confirm it as I am not confident. Better yet, why don't you e-mail the iContact guys because they can answer you better...
Thanks for validating the code in the form, though...
The code I posted does what you describe including loading the selected page..
What do the actual URLs you are selecting look like? They may contain characters causing the issue..
Don't use backslashes in the URL - that's a Microsoft only thing..
Your error mentions 'c', that makes me think the URL contains a reference to your c drive and because you may be using Microsoft backslashes or too many forward slashes, for example, you will have a problem in anything but IE...
Im sorry what was that about only a M$ thing??.
/ is for URL as in protocol://URLaddress/location/file.htm.
\ is for local machine drive:olderile.ext.
\ is only used by MS for local machine paths, UNIX, OpenBSD, Linux etc use forward slashes for local and URL paths - if you are having your iContact site hosted on a non-Microsoft platform beware..
Microsoft platforms will take both types of slash so you may as well stick to the cross-platform, forward-slash approach - unless you are using absolute paths on a Microsoft platform..
Back slash is best reserved for escaping..
.....But backslash is for Microsoft local paths so best avoided in favour of forward slash which is used for UNIX local paths and, of course, URLs :.
For example, if using absolute references, use.
To make it cross-platform (although UNIX-based systems would not have a drive letter)..
Just so that everyone knows, \'s are used for escaping, and as a folder delimiter on MICROSOFT OS's (windows, MS-DOS). The / is used for folder delimiting on everything else (linux, BSD, unix, and as a standard on the WEB)...
All right, here is exactly what I am generating:.
<form action="" method="get">.
<input type="hidden" name="shown" value="yes">.
<select name="fname" size=4 onchange="window.location.href=this.options[this.selectedIndex].value;">.
Now, what is wrong with it? Again, under IE I can display the content of "filea" (or any other specified as an option),.
But Netscape does not like the "protocol". Is there a way to hide "c:"? And yes, I tried using "c:/" instead of "c:\", with exactly the same result. I also tried things like "file://c:\", by the way...
If your serving up from your own machine, you have to put anything you wish to serve up within the servers scope, this means you would either add in a folder as an alias or as a folder within the servers root..
Your server addressing:-.
Protocol://domain:port/alias/location/file.ext <- Absoloute addressing.
/alias/location/file.ext <- relative addressing.
You need to specify relative addressing in URLs and these are anything past the 'protocol://domain:port' this leaves you with anything past the root / or the /alias root as shown above..
Should do what your looking to do, return a path thats relative in the value..
IM assuming that.
Is where the filea file exists...
If you want to keep the reference to the 'c' drive then this should work :.
<option value="file://C:/somefolder/somesubfolder/somepage.htm">Some page</option>.
[ Tested successfully on IE6, NN4, NN7 ]..
Yes but, if the page is on the internet in an ISP assigned webspace, the file://c:/ would be looking on the surfers machine c: for the file, thats why you bring items like that into the servers scope and apply a relative path or alias...
I changed to this format: "file://c:/directory/subdirectory/.../file.ext", as ElectricSheep suggested..
"Error: Access to 'file:///c:/directory/.../filea.tp' from script denied".
"Error: uncaught exception: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "<unknown>"]"..
Again, this only happens with Netscape. I presume that senshi is right, there is a confusion between finding the file on the server or on the client. But why this does not bother the IE?.
Also, I may want to modify the DirectoryRoot value of "httpd" file for the Apache, to point to a place common to both where the application and files of interest (filea, etc) are located. Then I can switch to relative addressing...
This is actually now a security issue, Mozilla/Netscape doesn't allow linking to local files from Web content unless it is set up in your preferences file hence the access denied message..
If you are going to do this you'll need something like the line user_pref("security.checkloaduri", false); in your Netscape profile's user.js file..
IE does not currently impose the same level of strictness although it may do once you have installed SP2...