Problem with window.open()

[Ian Sedwell]

Hi guys

The following code works just fine in Netscape on MacOS and Windows. But in
Explorer on MacOS and Windows it throws a type mismatch error at the point
marked with the comment ³// bug out at this point². (The functions that are
called, but not listed here work fine in both Netscape and Explorer in this
and other contexts, so I can confidently discount them as the source of any
error.)

I have also tried just a plain and simple ³window.open()² command with
appropriate parameters, but to no avail. Explorer just does not seem to like
the command. But that is just plain stupid... Microsoft can¹t possibly be
wrong, it must be me that is screwing up.

Any help will be most appreciated.

All the best

Ian
var bulletinSignupW indow

function displayBulletin Signup () {
var theURL = "bulletinsignup .htm";
var winName = "Bulletin Signup";
var features = "scrollbars=yes ,";
features += "location=n o,";
features += "toolbar=no ,";
features += "menuBar=no ,";
features += "directories=no ,";
features += "status=no, ";
features += "resizable=no," ;
features += "width=500, ";
features += "height=500 ,";
features += "left=30,";
features += "top=30";

bulletinSignupW indow =
openDisplayWind ow(bulletinSign upWindow,theURL ,winName,featur es);
}

function openDisplayWind ow (windowRef,cont entURL,windowNa me,features) {
var whichBrowser = checkBrowser();
var nullWindow;

switch (whichBrowser) {
case "Netscape":
nullWindow = undefined;
break;
case "Explorer":
nullWindow = null;
break;
default:
nullWindow = undefined;
break;
}

if (windowRef == nullWindow) {
windowRef = window.open(con tentURL,windowN ame,features);

if (windowRef != nullWindow) {
windowRef.focus ();
}
else {
alert("The " + quoteString(win dowName,SQUOTE) + " window cannot be
opened. You might be low on memory.");
}
} ³// bug out at this point²
else {
windowRef.focus ();
}

return windowRef;
}

[DU]

Ian Sedwell wrote:

Hi guys

The following code works just fine in Netscape on MacOS and Windows. But in
Explorer on MacOS and Windows it throws a type mismatch error at the point
marked with the comment ³// bug out at this point². (The functions that are
called, but not listed here work fine in both Netscape and Explorer in this
and other contexts, so I can confidently discount them as the source of any
error.)

I have also tried just a plain and simple ³window.open()² command with
appropriate parameters, but to no avail. Explorer just does not seem to like
the command. But that is just plain stupid... Microsoft can¹t possibly be
wrong, it must be me that is screwing up.

Any help will be most appreciated.

All the best

Ian
var bulletinSignupW indow
var bulletinSignupW indow = null;

function displayBulletin Signup () {
var theURL = "bulletinsignup .htm";
var winName = "Bulletin Signup";
winName must be a one word string without any blank spaces. This is a
well known issue with MSIE 5+.
var features = "scrollbars=yes ,";
features += "location=n o,";
features += "toolbar=no ,";
features += "menuBar=no ,";

features += "directories=no ,";
features += "status=no, ";
It's pointless, useless and very anti-user to try to remove the status
bar. MSIE 6 SP2, NS 6.2+, Opera 7.x and many other browsers allow the
users, give the users absolute veto power to force presence of status
bar. Why do you want your users to not be able to see http connections,
download, transfer, messages, notifications. Why are you trying to
remove the chrome bar by which I can see if the security padlock icon
(SSL) is locked or opened?
features += "resizable=no," ;
So you want to prevent your users from resizing their own browser
window? How user-friendly of you!
features += "width=500, ";
features += "height=500 ,";
If your user's screen is 640x480, then your window position and
dimensions will be corrected by modern browsers. Now, your anti-user
window features will then make the window you created unusable. Even
with a 800x600, your requested height value might be too strict, too
short in a minority of cases.
features += "left=30,";
features += "top=30";

Why do you slow down the whole process of creating that string with 12
string appending.
bulletinSignupW indow =
openDisplayWind ow(bulletinSign upWindow,theURL ,winName,featur es);

You can replace everything above and everything under (the whole
openDisplayWind ow) with this:

if(bulletinSign upWindow == null || bulletinSignupW indow.closed)
{
bulletinSignupW indow = openDisplayWind ow("bulletinsig nup.htm",
"BulletinSignup ", "scrollbars,sta tus,resizable") ;
}
else
{
bulletinSignupW indow.focus();
};
Often, not defining position and dimensions is better than defining
these values. The reasoning is that the os stores these values as
persistent data so that the next non-maximized window being opened
without strict values will use these stored values.
There is another policy also: make position and dimensions values
entirely proportional, scaled to the user's application workarea values
(it's a bit more complicated but it works).
}

function openDisplayWind ow (windowRef,cont entURL,windowNa me,features) {
var whichBrowser = checkBrowser();
var nullWindow;

switch (whichBrowser) {
case "Netscape":
nullWindow = undefined;
break;
case "Explorer":
nullWindow = null;
break;
default:
nullWindow = undefined;
break;
}

if (windowRef == nullWindow) {
windowRef = window.open(con tentURL,windowN ame,features);

if (windowRef != nullWindow) {
windowRef.focus ();
Not optimized here too. You only need 1 if..else; not 2 if(){..} .
}
else {
alert("The " + quoteString(win dowName,SQUOTE) + " window cannot be
opened. You might be low on memory.");
Not low on memory. One string without blank spaces.
}
} ³// bug out at this point²
else {
windowRef.focus ();
}

return windowRef;

This whole openDisplayWind ow function can be replaced by much more
efficient code without jeopardizing cross-browser interoperabilit y.

}

DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Netscape 7.2 :)

[Ian Sedwell]

Hi DU

Many thanks for your response. I appreciate the technical assistance.

As for the actual use of windows in web sites, I have a great deal of
sympathy with all that you say. I am not actually in favour of using
multiple windows in a web site. Hitherto, I have always used frames or <div>
layers to do what the client wants done here. But it is the client's choice.
I have made my case in favour of what I think both you and I would agree is
the more "friendly" way of doing things, but...

As to the size of the window. That's a red-herring. The dimensions in my
code are quite arbitrary. For the convenience of people of reading the code
I had posted as an exemplar, I had removed the code that tested the user's
screen size, set the window size accordingly and inserted scroll bars if
required. In fact this window (one of four the client wants) will only ever
contain a small table of results and there would be no point in making it
scrollable or resizable, unless the screen was too small. For the others,
that is not the case, they will contain considerable chunks of information
and so must scroll, though for cosmetic reasons I will still not allow them
to be resized. And none of them will have address, tool, menu or status
bars, either - on the client's instruction - so you can continue with your
admonishments!

Thanks again

Ian

On 2004/09/04 17:57, in article 2p************@ uni-berlin.de, "DU"
<dr*******@hotN OSPAMmail.com> wrote:

Ian Sedwell wrote:

Hi guys

The following code works just fine in Netscape on MacOS and Windows. But in
Explorer on MacOS and Windows it throws a type mismatch error at the point
marked with the comment ³// bug out at this point². (The functions that are
called, but not listed here work fine in both Netscape and Explorer in this
and other contexts, so I can confidently discount them as the source of any
error.)

I have also tried just a plain and simple ³window.open()² command with
appropriate parameters, but to no avail. Explorer just does not seem to like
the command. But that is just plain stupid... Microsoft can¹t possibly be
wrong, it must be me that is screwing up.

Any help will be most appreciated.

All the best

Ian
var bulletinSignupW indow

var bulletinSignupW indow = null;

function displayBulletin Signup () {
var theURL = "bulletinsignup .htm";
var winName = "Bulletin Signup";

winName must be a one word string without any blank spaces. This is a
well known issue with MSIE 5+.

var features = "scrollbars=yes ,";
features += "location=n o,";
features += "toolbar=no ,";
features += "menuBar=no ,";

features += "directories=no ,";
features += "status=no, ";

It's pointless, useless and very anti-user to try to remove the status
bar. MSIE 6 SP2, NS 6.2+, Opera 7.x and many other browsers allow the
users, give the users absolute veto power to force presence of status
bar. Why do you want your users to not be able to see http connections,
download, transfer, messages, notifications. Why are you trying to
remove the chrome bar by which I can see if the security padlock icon
(SSL) is locked or opened?

features += "resizable=no," ;

So you want to prevent your users from resizing their own browser
window? How user-friendly of you!

features += "width=500, ";
features += "height=500 ,";

If your user's screen is 640x480, then your window position and
dimensions will be corrected by modern browsers. Now, your anti-user
window features will then make the window you created unusable. Even
with a 800x600, your requested height value might be too strict, too
short in a minority of cases.

features += "left=30,";
features += "top=30";

Why do you slow down the whole process of creating that string with 12
string appending.

bulletinSignupW indow =
openDisplayWind ow(bulletinSign upWindow,theURL ,winName,featur es);

You can replace everything above and everything under (the whole
openDisplayWind ow) with this:

if(bulletinSign upWindow == null || bulletinSignupW indow.closed)
{
bulletinSignupW indow = openDisplayWind ow("bulletinsig nup.htm",
"BulletinSignup ", "scrollbars,sta tus,resizable") ;
}
else
{
bulletinSignupW indow.focus();
};
Often, not defining position and dimensions is better than defining
these values. The reasoning is that the os stores these values as
persistent data so that the next non-maximized window being opened
without strict values will use these stored values.
There is another policy also: make position and dimensions values
entirely proportional, scaled to the user's application workarea values
(it's a bit more complicated but it works).

}

function openDisplayWind ow (windowRef,cont entURL,windowNa me,features) {
var whichBrowser = checkBrowser();
var nullWindow;

switch (whichBrowser) {
case "Netscape":
nullWindow = undefined;
break;
case "Explorer":
nullWindow = null;
break;
default:
nullWindow = undefined;
break;
}

if (windowRef == nullWindow) {
windowRef = window.open(con tentURL,windowN ame,features);

if (windowRef != nullWindow) {
windowRef.focus ();

Not optimized here too. You only need 1 if..else; not 2 if(){..} .

}
else {
alert("The " + quoteString(win dowName,SQUOTE) + " window cannot be
opened. You might be low on memory.");

Not low on memory. One string without blank spaces.

}
} ³// bug out at this point²
else {
windowRef.focus ();
}

return windowRef;

This whole openDisplayWind ow function can be replaced by much more
efficient code without jeopardizing cross-browser interoperabilit y.

}

DU

[Jim Ley]

On Sun, 5 Sep 2004 16:34:16 +0000 (UTC), Ian Sedwell
<ia*********@bt click.com> wrote:

I will still not allow them
to be resized. And none of them will have address, tool, menu or status
bars, either - on the client's instruction - so you can continue with your
admonishment s!

So what are you going to do about the fact that much of what you've
just described is impossible in IE6 SV1 (currently only in XP SP2 but
will be in other IE6's soon)

Jim.

[Ian Sedwell]

Hi Jim

That is my understanding too. Thank you for confirming it. I haven't looked
at the issue in detail myself, but I have seen some technical papers. Which
is one of the reasons I have been arguing with my client against the use of
these windows in any case. The other is I do not like multi-window web
sites. It seems to that it is poor practice for a good number of reasons
that need not be rehearsed here.

As to what I am going to do... Well, I am naturally exercising due diligence
and I have an entirely frame-based version that I will produce as if by
magic from a hat as soon as the client complains that people can't use his
web site :-)

All the best

Ian

On 2004/09/05 17:44, in article 41************* ***@news.indivi dual.net, "Jim
Ley" <ji*@jibbering. com> wrote:

On Sun, 5 Sep 2004 16:34:16 +0000 (UTC), Ian Sedwell
<ia*********@bt click.com> wrote:

I will still not allow them
to be resized. And none of them will have address, tool, menu or status
bars, either - on the client's instruction - so you can continue with your
admonishments!

So what are you going to do about the fact that much of what you've
just described is impossible in IE6 SV1 (currently only in XP SP2 but
will be in other IE6's soon)

Jim.