Problem with window.open()

DU · Jul 23 '05, 01:25 PM

Re: Problem with window.open()

Ian Sedwell wrote:
[color=blue]
> 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[/color]

var bulletinSignupW indow = null;
[color=blue]
>
> function displayBulletin Signup () {
> var theURL = "bulletinsignup .htm";
> var winName = "Bulletin Signup";[/color]

winName must be a one word string without any blank spaces. This is a
well known issue with MSIE 5+.
[color=blue]
> var features = "scrollbars=yes ,";
> features += "location=n o,";
> features += "toolbar=no ,";
> features += "menuBar=no ,";[/color]

[color=blue]
> features += "directories=no ,";
> features += "status=no, ";[/color]

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?
[color=blue]
> features += "resizable=no," ;[/color]

So you want to prevent your users from resizing their own browser
window? How user-friendly of you!
[color=blue]
> features += "width=500, ";
> features += "height=500 ,";[/color]

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.
[color=blue]
> features += "left=30,";
> features += "top=30";
>[/color]

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

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).
[color=blue]
> }
>
> 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 ();[/color]

Not optimized here too. You only need 1 if..else; not 2 if(){..} .
[color=blue]
> }
> else {
> alert("The " + quoteString(win dowName,SQUOTE) + " window cannot be
> opened. You might be low on memory.");[/color]

Not low on memory. One string without blank spaces.
[color=blue]
> }
> } ³// bug out at this point²
> else {
> windowRef.focus ();
> }
>
> return windowRef;[/color]

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

[color=blue]
> }
>
>[/color]

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

**Ian Sedwell** · Jul 23 '05, 01:26 PM

Re: Problem with window.open() (Thanks DU)

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 2puagcFp3r9mU1@ uni-berlin.de, "DU"
<drunclear@hotN OSPAMmail.com> wrote:
[color=blue]
> Ian Sedwell wrote:
>[color=green]
>> 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[/color]
>
> var bulletinSignupW indow = null;
>[color=green]
>>
>> function displayBulletin Signup () {
>> var theURL = "bulletinsignup .htm";
>> var winName = "Bulletin Signup";[/color]
>
> winName must be a one word string without any blank spaces. This is a
> well known issue with MSIE 5+.
>[color=green]
>> var features = "scrollbars=yes ,";
>> features += "location=n o,";
>> features += "toolbar=no ,";
>> features += "menuBar=no ,";[/color]
>
>
>[color=green]
>> features += "directories=no ,";
>> features += "status=no, ";[/color]
>
> 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?
>[color=green]
>> features += "resizable=no," ;[/color]
>
> So you want to prevent your users from resizing their own browser
> window? How user-friendly of you!
>[color=green]
>> features += "width=500, ";
>> features += "height=500 ,";[/color]
>
> 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.
>[color=green]
>> features += "left=30,";
>> features += "top=30";
>>[/color]
>
> Why do you slow down the whole process of creating that string with 12
> string appending.
>[color=green]
>> bulletinSignupW indow =
>> openDisplayWind ow(bulletinSign upWindow,theURL ,winName,featur es);[/color]
>
>
> 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).
>[color=green]
>> }
>>
>> 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 ();[/color]
>
> Not optimized here too. You only need 1 if..else; not 2 if(){..} .
>[color=green]
>> }
>> else {
>> alert("The " + quoteString(win dowName,SQUOTE) + " window cannot be
>> opened. You might be low on memory.");[/color]
>
> Not low on memory. One string without blank spaces.
>[color=green]
>> }
>> } ³// bug out at this point²
>> else {
>> windowRef.focus ();
>> }
>>
>> return windowRef;[/color]
>
>
> This whole openDisplayWind ow function can be replaced by much more
> efficient code without jeopardizing cross-browser interoperabilit y.
>
>[color=green]
>> }
>>
>>[/color]
>
> DU[/color]

**Jim Ley** · Jul 23 '05, 01:26 PM

Re: Problem with window.open() (Thanks DU)

On Sun, 5 Sep 2004 16:34:16 +0000 (UTC), Ian Sedwell
<ian.sedwell@bt click.com> wrote:[color=blue]
> 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![/color]

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** · Jul 23 '05, 01:26 PM

Re: Problem with window.open() (Thanks DU)

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 413b4248.612129 475@news.indivi dual.net, "Jim
Ley" <jim@jibbering. com> wrote:
[color=blue]
> On Sun, 5 Sep 2004 16:34:16 +0000 (UTC), Ian Sedwell
> <ian.sedwell@bt click.com> wrote:[color=green]
>> 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![/color]
>
> 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.[/color]

Problem with window.open()

Problem with window.open()

Comment

Comment

Comment

Comment