cookie not sent with window.open

I link to a web site from an Excel spreadsheet. The page i link to is
getCookie.asp which sets a cookie then returns back some html which opens a
new window, to the same site but a different page (same folder).

The cookie is not received. Can someone explain why?

I worked around this by adding a cache-control header with a value of
no-cache. This fixes the problem. Unfortunately that causes another
problem with Internet Explorer that no-one can figure out (basically with
friendly error messages turned on IE shows an error page for no reason - i
posted a lengthy message about this to m.p.i.asp.general but no-one has a
clue).

I have tried every combination of every cache busting header i can think of
but no other one fixes this problem about the cookie not being received.

So basically i'm in a catch-22. If i put the cache-buster in then users
will get a nasty error message from IE unless they have 'friendly' error
messages off. If i leave out cache-buster code then the session cookie
doesn't get returned which means the users cant access my site. Help!

Example asp's are below. To recreate the problem simply create a hyperlink
to getCookie.asp in excel then open it (after each attempt you need to shut
down Excel). By the way everything works fine if you type the URL into IE
directly... the problem is when opening from Excel.

Thanks in advance

Paul

----getCookie.asp------
<%
'cache code which makes next page work
'Response.CacheControl = "no-cache"
'send cookie back to client
Response.Cookies("PaulSessionID") = "PaulsCookie"
%>
<HTML>
<HEAD>
<SCRIPT>
window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar')
;
</SCRIPT>
</HEAD>
<BODY> </BODY>
</HTML>
------------------------

-----useCookie.asp------
<%Response.CacheControl = "no-cache"%>
The cookie set by the previous page is:
"<%=Request.Cookies("PaulSessionID")%>"
---------------------------

First, I find it very odd that any kind of caching header would have
anything to do with cookies not being recieved.
The two are completely unrelated AFAIK.

Anyway, I'm trying to grasp what you are doing here, so if I'm getting this
right this is what happens:
- a user has an excel sheet open with a hyperlink in it to getCookie.asp
- the user clicks this hyperlink, which opens a new Internet Explorer
window, loading getCookie.asp
- getCookie.asp sets a cookie, then returns some HTML & JavaScript to open a
new window calling useCookie.asp
- useCookie.asp retrieves the cookie set by getCookie.asp, and uses it
(duh!)

the first thing that I can think of is that that second browser window is
running a new browser session, making it impossible for that window to
retrieve that session-based cookie set by the first window,
I'm not sure that is the case, cause I'm not sure if using window.open() can
cause a new browser session to be created, by I do know for sure this can be
the case if you open a new window by right-clicking, and opening a page in a
new window

IE has/had some setting where each new IE window runs as a seperate
application, which also caused session cookies to "get lost" (they don't
really, cause it's a new session).

A funny session bug I ran into in IE 5 is when you start IE and your
homepage is not a website (file:// protocol instead of http), also causes
your session to get lost when a new window is openened using window.open().

maybe this helps?

"Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
news:c39gte$258bfj$1@ID-141222.news.uni-berlin.de...[color=blue]
> I link to a web site from an Excel spreadsheet. The page i link to is
> getCookie.asp which sets a cookie then returns back some html which opens[/color]
a[color=blue]
> new window, to the same site but a different page (same folder).
>
> The cookie is not received. Can someone explain why?
>
> I worked around this by adding a cache-control header with a value of
> no-cache. This fixes the problem. Unfortunately that causes another
> problem with Internet Explorer that no-one can figure out (basically with
> friendly error messages turned on IE shows an error page for no reason - i
> posted a lengthy message about this to m.p.i.asp.general but no-one has a
> clue).
>
> I have tried every combination of every cache busting header i can think[/color]
of[color=blue]
> but no other one fixes this problem about the cookie not being received.
>
> So basically i'm in a catch-22. If i put the cache-buster in then users
> will get a nasty error message from IE unless they have 'friendly' error
> messages off. If i leave out cache-buster code then the session cookie
> doesn't get returned which means the users cant access my site. Help!
>
> Example asp's are below. To recreate the problem simply create a[/color]
hyperlink[color=blue]
> to getCookie.asp in excel then open it (after each attempt you need to[/color]
shut[color=blue]
> down Excel). By the way everything works fine if you type the URL into IE
> directly... the problem is when opening from Excel.
>
> Thanks in advance
>
> Paul
>
> ----getCookie.asp------
> <%
> 'cache code which makes next page work
> 'Response.CacheControl = "no-cache"
> 'send cookie back to client
> Response.Cookies("PaulSessionID") = "PaulsCookie"
> %>
> <HTML>
> <HEAD>
> <SCRIPT>
>[/color]
window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar')[color=blue]
> ;
> </SCRIPT>
> </HEAD>
> <BODY> </BODY>
> </HTML>
> ------------------------
>
>
> -----useCookie.asp------
> <%Response.CacheControl = "no-cache"%>
> The cookie set by the previous page is:
> "<%=Request.Cookies("PaulSessionID")%>"
> ---------------------------
>
>[/color]

J. Baute wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:[color=blue]
> the first thing that I can think of is that that second browser window is
> running a new browser session, making it impossible for that window to
> retrieve that session-based cookie set by the first window,[/color]

The test of the pudding should be the [temporarily] giving a expiration
date to the cookie, so the cookie is session independent, as long as the
two files are in the same domain.

Even better:

test with 2 cookies at once,
giving only one an expiration date in 2020,
and also with a session variable.

If the session cookie [the one without expiration date] and the session
variable return empty, you know what the problem is.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

J. Baute wrote:[color=blue]
> First, I find it very odd that any kind of caching header would have
> anything to do with cookies not being recieved.
> The two are completely unrelated AFAIK.[/color]

I know... tell me about it!!!
[color=blue]
> Anyway, I'm trying to grasp what you are doing here, so if I'm
> getting this right this is what happens:
> - a user has an excel sheet open with a hyperlink in it to
> getCookie.asp
> - the user clicks this hyperlink, which opens a new Internet Explorer
> window, loading getCookie.asp
> - getCookie.asp sets a cookie, then returns some HTML & JavaScript to
> open a new window calling useCookie.asp
> - useCookie.asp retrieves the cookie set by getCookie.asp, and uses
> it (duh!)[/color]

Correct, this is exactly what i'm trying to do.
[color=blue]
> the first thing that I can think of is that that second browser
> window is running a new browser session, making it impossible for
> that window to retrieve that session-based cookie set by the first
> window, I'm not sure that is the case, cause I'm not sure if using
> window.open() can cause a new browser session to be created, by I do
> know for sure this can be the case if you open a new window by
> right-clicking, and opening a page in a new window
> IE has/had some setting where each new IE window runs as a seperate
> application, which also caused session cookies to "get lost" (they
> don't really, cause it's a new session).[/color]

Yes going back a bit now i've looked into how IE (and different versions of
it) shares its memory between instances of itself.
That's a really good hypothesis... unfortunately i've just checked it out
and it isn't the cause.
[color=blue]
> A funny session bug I ran into in IE 5 is when you start IE and your
> homepage is not a website (file:// protocol instead of http), also
> causes your session to get lost when a new window is openened using
> window.open().
>
> maybe this helps?[/color]

Nope... tried all combinations of home page and its still the same.

Have you (anyone?!?) not managed to reproduce this issue? I've tried it on
at least computers, some inside the office some outside, either w2k or NT4.
The issue is always there.

I'm starting to think its a symptom of a security update related to
window.open. But it can't be... because if it was then the cookie would
*never* be sent, would it!

[color=blue]
> "Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
> news:c39gte$258bfj$1@ID-141222.news.uni-berlin.de...[color=green]
>> I link to a web site from an Excel spreadsheet. The page i link to
>> is getCookie.asp which sets a cookie then returns back some html
>> which opens a new window, to the same site but a different page
>> (same folder).
>>
>> The cookie is not received. Can someone explain why?
>>
>> I worked around this by adding a cache-control header with a value of
>> no-cache. This fixes the problem. Unfortunately that causes another
>> problem with Internet Explorer that no-one can figure out (basically
>> with friendly error messages turned on IE shows an error page for no
>> reason - i posted a lengthy message about this to m.p.i.asp.general
>> but no-one has a clue).
>>
>> I have tried every combination of every cache busting header i can
>> think of but no other one fixes this problem about the cookie not
>> being received.
>>
>> So basically i'm in a catch-22. If i put the cache-buster in then
>> users will get a nasty error message from IE unless they have
>> 'friendly' error messages off. If i leave out cache-buster code
>> then the session cookie doesn't get returned which means the users
>> cant access my site. Help!
>>
>> Example asp's are below. To recreate the problem simply create a
>> hyperlink to getCookie.asp in excel then open it (after each attempt
>> you need to shut down Excel). By the way everything works fine if
>> you type the URL into IE directly... the problem is when opening
>> from Excel.
>>
>> Thanks in advance
>>
>> Paul
>>
>> ----getCookie.asp------
>> <%
>> 'cache code which makes next page work
>> 'Response.CacheControl = "no-cache"
>> 'send cookie back to client
>> Response.Cookies("PaulSessionID") = "PaulsCookie"
>> %>
>> <HTML>
>> <HEAD>
>> <SCRIPT>
>>[/color]
>[/color]
window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar')[color=blue][color=green]
>> ;
>> </SCRIPT>
>> </HEAD>
>> <BODY> </BODY>
>> </HTML>
>> ------------------------
>>
>>
>> -----useCookie.asp------
>> The cookie set by the previous page is:
>> "<%=Request.Cookies("PaulSessionID")%>"
>> ---------------------------[/color][/color]

Evertjan. wrote:[color=blue]
> J. Baute wrote on 18 mrt 2004 in
> microsoft.public.inetserver.asp.general:[color=green]
>> the first thing that I can think of is that that second browser
>> window is running a new browser session, making it impossible for
>> that window to retrieve that session-based cookie set by the first
>> window,[/color]
>
> The test of the pudding should be the [temporarily] giving a
> expiration date to the cookie, so the cookie is session independent,
> as long as the two files are in the same domain.
>
> Even better:
>
> test with 2 cookies at once,
> giving only one an expiration date in 2020,
> and also with a session variable.
>
> If the session cookie [the one without expiration date] and the
> session variable return empty, you know what the problem is.[/color]

I just did this. What happens is the cookie with the date does get sent.
The cookie without the date (as before) does not.

What does this tell me?

Paul

Paul wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:
[color=blue]
> I just did this. What happens is the cookie with the date does get sent.
> The cookie without the date (as before) does not.
>
> What does this tell me?
>[/color]

That both windows are not in the same session.

You could prove this with a session variable as I suggested.

==================

But why not add a expiration of say one hour,
and everyone [with cookes allowed] will be happy?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Evertjan. wrote:[color=blue]
> Paul wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:
>[color=green]
>> I just did this. What happens is the cookie with the date does get
>> sent. The cookie without the date (as before) does not.
>>
>> What does this tell me?
>>[/color]
>
> That both windows are not in the same session.
>
> You could prove this with a session variable as I suggested.[/color]

Ok cool, so i know that window.open is creating a new session.
Is this:
a) a bug?
b) a feature?!
or c) by design?

"Paul" wrote:[color=blue]
>
> Ok cool, so i know that window.open is creating a new session.
> Is this:
> a) a bug?
> b) a feature?!
> or c) by design?[/color]

You forgot:
d) unreliable
e) all of the above

Since IE 5.01, the "open new windows in a separate process" option has been
taken out of the user's hands and has been made the responsibility of IE.
IE, for its part, decides whether to do so based on the resources available
to it.

I have demonstrated for many people that this behavior can be changed by
running more (or fewer) applications on the client machine. It is so fickle
as to render session variables useless in our business environment.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

"Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
news:c3cdmc$24uvkc$1@ID-141222.news.uni-berlin.de...[color=blue]
> Evertjan. wrote:[color=green]
> > Paul wrote on 18 mrt 2004 in microsoft.public.inetserver.asp.general:
> >[color=darkred]
> >> I just did this. What happens is the cookie with the date does get
> >> sent. The cookie without the date (as before) does not.
> >>
> >> What does this tell me?
> >>[/color]
> >
> > That both windows are not in the same session.
> >
> > You could prove this with a session variable as I suggested.[/color]
>
> Ok cool, so i know that window.open is creating a new session.
> Is this:
> a) a bug?
> b) a feature?!
> or c) by design?[/color]

The only KB I can find explaining this bug is this one:
http://www.kbalertz.com/Feedback_315713.aspx

I'm thinking it might have something to do with with the original window
starting from Excel as well, since you didn't get that problem when you
loaded the original URL straight from IE.

I've seen this behavior before but I cannot duplicate it any more.

What I have seen in the past is that if the link to the ASP page was
embedded in an HTML pages that was launched from the file system instead of
through the web-server then the browser would not pass the session cookie to
windows opened with window.open().

What version of IE are you using? I have IE 6 with all the latest patches.

--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com

"Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
news:c3bt3v$25k5k3$1@ID-141222.news.uni-berlin.de...[color=blue]
> J. Baute wrote:[color=green]
> > First, I find it very odd that any kind of caching header would have
> > anything to do with cookies not being recieved.
> > The two are completely unrelated AFAIK.[/color]
>
> I know... tell me about it!!!
>[color=green]
> > Anyway, I'm trying to grasp what you are doing here, so if I'm
> > getting this right this is what happens:
> > - a user has an excel sheet open with a hyperlink in it to
> > getCookie.asp
> > - the user clicks this hyperlink, which opens a new Internet Explorer
> > window, loading getCookie.asp
> > - getCookie.asp sets a cookie, then returns some HTML & JavaScript to
> > open a new window calling useCookie.asp
> > - useCookie.asp retrieves the cookie set by getCookie.asp, and uses
> > it (duh!)[/color]
>
> Correct, this is exactly what i'm trying to do.
>[color=green]
> > the first thing that I can think of is that that second browser
> > window is running a new browser session, making it impossible for
> > that window to retrieve that session-based cookie set by the first
> > window, I'm not sure that is the case, cause I'm not sure if using
> > window.open() can cause a new browser session to be created, by I do
> > know for sure this can be the case if you open a new window by
> > right-clicking, and opening a page in a new window
> > IE has/had some setting where each new IE window runs as a seperate
> > application, which also caused session cookies to "get lost" (they
> > don't really, cause it's a new session).[/color]
>
> Yes going back a bit now i've looked into how IE (and different versions[/color]
of[color=blue]
> it) shares its memory between instances of itself.
> That's a really good hypothesis... unfortunately i've just checked it out
> and it isn't the cause.
>[color=green]
> > A funny session bug I ran into in IE 5 is when you start IE and your
> > homepage is not a website (file:// protocol instead of http), also
> > causes your session to get lost when a new window is openened using
> > window.open().
> >
> > maybe this helps?[/color]
>
> Nope... tried all combinations of home page and its still the same.
>
> Have you (anyone?!?) not managed to reproduce this issue? I've tried it[/color]
on[color=blue]
> at least computers, some inside the office some outside, either w2k or[/color]
NT4.[color=blue]
> The issue is always there.
>
> I'm starting to think its a symptom of a security update related to
> window.open. But it can't be... because if it was then the cookie would
> *never* be sent, would it!
>
>
>[color=green]
> > "Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
> > news:c39gte$258bfj$1@ID-141222.news.uni-berlin.de...[color=darkred]
> >> I link to a web site from an Excel spreadsheet. The page i link to
> >> is getCookie.asp which sets a cookie then returns back some html
> >> which opens a new window, to the same site but a different page
> >> (same folder).
> >>
> >> The cookie is not received. Can someone explain why?
> >>
> >> I worked around this by adding a cache-control header with a value of
> >> no-cache. This fixes the problem. Unfortunately that causes another
> >> problem with Internet Explorer that no-one can figure out (basically
> >> with friendly error messages turned on IE shows an error page for no
> >> reason - i posted a lengthy message about this to m.p.i.asp.general
> >> but no-one has a clue).
> >>
> >> I have tried every combination of every cache busting header i can
> >> think of but no other one fixes this problem about the cookie not
> >> being received.
> >>
> >> So basically i'm in a catch-22. If i put the cache-buster in then
> >> users will get a nasty error message from IE unless they have
> >> 'friendly' error messages off. If i leave out cache-buster code
> >> then the session cookie doesn't get returned which means the users
> >> cant access my site. Help!
> >>
> >> Example asp's are below. To recreate the problem simply create a
> >> hyperlink to getCookie.asp in excel then open it (after each attempt
> >> you need to shut down Excel). By the way everything works fine if
> >> you type the URL into IE directly... the problem is when opening
> >> from Excel.
> >>
> >> Thanks in advance
> >>
> >> Paul
> >>
> >> ----getCookie.asp------
> >> <%
> >> 'cache code which makes next page work
> >> 'Response.CacheControl = "no-cache"
> >> 'send cookie back to client
> >> Response.Cookies("PaulSessionID") = "PaulsCookie"
> >> %>
> >> <HTML>
> >> <HEAD>
> >> <SCRIPT>
> >>[/color]
> >[/color]
>[/color]
window.open('useCookie.asp','newWin','resizable,sc rollbars,menubar,toolbar')[color=blue][color=green][color=darkred]
> >> ;
> >> </SCRIPT>
> >> </HEAD>
> >> <BODY> </BODY>
> >> </HTML>
> >> ------------------------
> >>
> >>
> >> -----useCookie.asp------
> >> The cookie set by the previous page is:
> >> "<%=Request.Cookies("PaulSessionID")%>"
> >> ---------------------------[/color][/color]
>
>
>[/color]

Mark Schupp wrote:[color=blue]
> I've seen this behavior before but I cannot duplicate it any more.
>
> What I have seen in the past is that if the link to the ASP page was
> embedded in an HTML pages that was launched from the file system
> instead of through the web-server then the browser would not pass the
> session cookie to windows opened with window.open().
>
> What version of IE are you using? I have IE 6 with all the latest
> patches.
>[/color]

Me too. These days its hard to find a machine that doesn't have all the
latest patches! Its a shame that what windowsupdate tells you can't be
totally relied upon; e.g. the other week for Internet banking i had to
install Q831167 which for some reason windowsupdate hadnt previously
installed.

I'd like to have a collection of bootable CD's each one with a different
OS/Brower on, that i could use for testing weird stuff like this. Even if
it was possible (assuming it isnt) the i'm sure licensing cost would be
horrific!!

Paul

J. Baute wrote:[color=blue]
> "Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
> news:c3cdmc$24uvkc$1@ID-141222.news.uni-berlin.de...[color=green]
>> Ok cool, so i know that window.open is creating a new session.
>> Is this:
>> a) a bug?
>> b) a feature?!
>> or c) by design?[/color]
>
> The only KB I can find explaining this bug is this one:
> http://www.kbalertz.com/Feedback_315713.aspx
>[/color]

Yep i found this but disregarded it as its file:// although there's
probably some link in there, especially considering that bug you found to do
with file:// homepages.
[color=blue]
> I'm thinking it might have something to do with with the original
> window starting from Excel as well, since you didn't get that problem
> when you loaded the original URL straight from IE.[/color]

I checked and its actually the same behaviour opening links from Word and
Powerpoint.

Dave Anderson wrote:[color=blue]
> "Paul" wrote:[color=green]
>>
>> Ok cool, so i know that window.open is creating a new session.
>> Is this:
>> a) a bug?
>> b) a feature?!
>> or c) by design?[/color]
>
> You forgot:
> d) unreliable
> e) all of the above
>
> Since IE 5.01, the "open new windows in a separate process" option
> has been taken out of the user's hands and has been made the
> responsibility of IE. IE, for its part, decides whether to do so
> based on the resources available to it.
>
> I have demonstrated for many people that this behavior can be changed
> by running more (or fewer) applications on the client machine. It is
> so fickle as to render session variables useless in our business
> environment.[/color]

Amazing. Well, thats it then isn't it. I'm done for. I'll have to figure
out a workaround... one that doesn't involve adding the no-cache header that
(for some still unknown reason) fixes it. Maybe some code that interrogates
what window.opener is, to see if its an Office app or an IE window that
itself was spawned by an Office app.

btw How did you demonstrate this behaviour? Did you find a combination of
apps to load or system resources to use up that would make it happen?

We use separate partitions with different OS's for testing and select the
desired environment from the NT boot menu.

If you can afford and MSDN Enterprise or Universal subscription then you get
test licenses for just about everything MS sells (seems like there used to
be a developer program that provided test licenses as well).

--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com

"Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
news:c3ckn2$26pc68$1@ID-141222.news.uni-berlin.de...[color=blue]
> Mark Schupp wrote:[color=green]
> > I've seen this behavior before but I cannot duplicate it any more.
> >
> > What I have seen in the past is that if the link to the ASP page was
> > embedded in an HTML pages that was launched from the file system
> > instead of through the web-server then the browser would not pass the
> > session cookie to windows opened with window.open().
> >
> > What version of IE are you using? I have IE 6 with all the latest
> > patches.
> >[/color]
>
> Me too. These days its hard to find a machine that doesn't have all the
> latest patches! Its a shame that what windowsupdate tells you can't be
> totally relied upon; e.g. the other week for Internet banking i had to
> install Q831167 which for some reason windowsupdate hadnt previously
> installed.
>
> I'd like to have a collection of bootable CD's each one with a different
> OS/Brower on, that i could use for testing weird stuff like this. Even if
> it was possible (assuming it isnt) the i'm sure licensing cost would be
> horrific!!
>
> Paul
>
>[/color]

In article <c3clvm$26js9v$1@ID-141222.news.uni-berlin.de>,
"Paul" <removethisbitthenitspaulyates@hotmail.com> wrote:
[color=blue]
>
> Amazing. Well, thats it then isn't it. I'm done for. I'll have to figure
> out a workaround... one that doesn't involve adding the no-cache header that
> (for some still unknown reason) fixes it. Maybe some code that interrogates
> what window.opener is, to see if its an Office app or an IE window that
> itself was spawned by an Office app.
>
> btw How did you demonstrate this behaviour? Did you find a combination of
> apps to load or system resources to use up that would make it happen?
>
>[/color]

You tired a possible one it seems. Set a timer on the cookie. Figure
out the worst case time and double it!

In a similiar situation, I used an hour. Depending on your situation,
the called window's javascript code can delete the cookie so you don't
have to worry about it hanging around.

You can also pass data via the search parameter. Do not know if it fits
you situation. See:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Loops</TITLE>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<SCRIPT type="text/javascript">

function foo()
{
var theData, newWindow, URLstring;

// Pass this data. I believe the data is limitted to a max
// of 2k.
theData = "?data=" + escape("see if the caller gets this.");
URLstring = "tryRead.html" + theData;
newWindow = window.open(URLstring,"Printable",
"statusbar,menubar,resizable,toolbar,height=600,wi dth=800");
newWindow.focus();
}

</script>

</HEAD>
<BODY onload='
alert("before.");
foo();
alert("after.");'>

<br><br>Lets open a window and pass data to the window.

</BODY>

</HTML>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Read passed data</TITLE>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<SCRIPT type="text/javascript">

function foo2()
{
var theData;
var begin;

begin = location.search.indexOf("data=");
if (begin >0 )
{

theData = location.search.substring(begin+5,location.search. length);
theData = unescape(theData);
alert("theData = " + theData);
}
}
</script>

</HEAD>
<BODY onload="foo2()">

<br><br>Read passed data.

</BODY>

</HTML>

"Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
news:c3clvm$26js9v$1@ID-141222.news.uni-berlin.de...
[color=blue]
> Amazing. Well, thats it then isn't it. I'm done for. I'll have to[/color]
figure[color=blue]
> out a workaround... one that doesn't involve adding the no-cache header[/color]
that[color=blue]
> (for some still unknown reason) fixes it. Maybe some code that[/color]
interrogates[color=blue]
> what window.opener is, to see if its an Office app or an IE window that
> itself was spawned by an Office app.[/color]

How about passing that ID as a querystring when you call window.open() ?

Yep there is always the partitions way of doing it, its just a bit 'messy'
for me!

I didn't know that you got licences like that with MSDN... i'll look into
it, thanks

Mark Schupp wrote:[color=blue]
> We use separate partitions with different OS's for testing and select
> the desired environment from the NT boot menu.
>
> If you can afford and MSDN Enterprise or Universal subscription then
> you get test licenses for just about everything MS sells (seems like
> there used to be a developer program that provided test licenses as
> well).
>
> "Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message[color=green]
>> I'd like to have a collection of bootable CD's each one with a
>> different OS/Brower on, that i could use for testing weird stuff
>> like this. Even if it was possible (assuming it isnt) the i'm sure
>> licensing cost would be horrific!!
>>
>> Paul[/color][/color]

"Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message
news:c3ed8i$27b0bp$1@ID-141222.news.uni-berlin.de...[color=blue]
> Yep there is always the partitions way of doing it, its just a bit 'messy'
> for me!
>
> I didn't know that you got licences like that with MSDN... i'll look into
> it, thanks
>
> Mark Schupp wrote:[color=green]
> > We use separate partitions with different OS's for testing and select
> > the desired environment from the NT boot menu.
> >
> > If you can afford and MSDN Enterprise or Universal subscription then
> > you get test licenses for just about everything MS sells (seems like
> > there used to be a developer program that provided test licenses as
> > well).
> >
> > "Paul" <removethisbitthenitspaulyates@hotmail.com> wrote in message[color=darkred]
> >> I'd like to have a collection of bootable CD's each one with a
> >> different OS/Brower on, that i could use for testing weird stuff
> >> like this. Even if it was possible (assuming it isnt) the i'm sure
> >> licensing cost would be horrific!!
> >>
> >> Paul[/color][/color][/color]

The MSDN Universal subscription here in Norway cost NOK 22 000.-, that is
approx. US$ 3 200.- for one year.

This gives every deveoper in your company full access to just about every
piece of software microsoft owns, including localized versions

And MSDN. All software are updated on CD/DVD 4 times a year, in addition to
access to the MSDN subscriber download area online.

--
Dag.

"Paul" wrote:[color=blue]
>
> btw How did you demonstrate this behaviour? Did you find a
> combination of apps to load or system resources to use up
> that would make it happen?[/color]

As I have said, it is unreliable, so it's nearly impossible to schedule a
demonstration. But on several occasions I have shown users who were
experiencing session loss that putting a different resource load on their
systems solved the problem. This was typically done by running more (or
fewer) apps.

And that's just stupid.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.

cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

re: cookie not sent with window.open

Similar ASP / Active Server Pages bytes

/bytes/development

/bytes/it

/bytes/about