RE: Javascript and browser compatability

Rob,

Do you have control of the <BODY> tag? Specifically can you add an
onLoad= attribute? The onLoad attribute specifies a function for the
browser to call when it's done loading the page. This would solve two
problems:

1) Since the page was loaded you would be sure that all the elements
were there. Thus the getElementsByName and getElementById would always
work.

2) You could solve your focus problem by using the focus() method:
document.getElementsByName('AFIELD.007-016')[0].focus();

If you can't change the body tag you could also inject some code into
the body tag by placing the following in one of your script blocks:

document.getElementsByTagName("BODY")[0].setAttribute("onLoad",
"DoOnLoad()");
function DoOnLoad()
{document.getElementsByName('AFIELD.007-016')[0].focus();}

This adds the onLoad attribute to the BODY tag and tells it to call
DoOnLoad() it also defines DoOnLoad to set the focus.

-Walden


------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com 

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
 
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Rob Dixon
Sent: Thursday, 11 November, 2004 13:30
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Javascript and browser compatability - progress

Walden

Walden H. Leverich wrote:

>Rob,
>
>Did you send me the entire HTML, or just part? 
>
Part. 

I can send the lot directly if you wish

>Have you found a way to
>prevent the <HR> from being generated because it's not there now.
>
No.   I was aware of the problem, but do not have the first idea how to 
fix it.  I thought that when the document first koaded, it would not be 
a problem, and I find that NS only complains about HR when I click or 
mouseover but not if I just click on ENTER.  I it works on loading the 
form, and the button names are changed , it presumably shouldn't matter 
if it fails again?

It had not occurred to me that the whole script block would fail if any 
part failed.  Should I put the HR code in its own script block?

Remember that it does work in IE.

I will try my code without the defer and see what happens.

> I see
>two problems (I'm testing w/Firefox, but NS should be the same).
>
>1) Since there is no <HR> the code to remove <HR> is failing, and the
>rest of the script block isn't executing, hence session never gets set.
>
>2) defer=true or not, the script block with cbt2 is getting run before
>the rest of the page is loaded. So even after we fix it so session is
>loaded, the buttons don't exist when the code runs. If I move the
script
>block below the form all is good.
>
I cannot put anything after the bottow buttons which are generated by 
WSG (or at least I don't know how)

You will be very aware how very basic is my understanding of Javascript 
- I can do other things rather better (or so I believe!)

WHat I am trying to do is basic in relation to what I wish to do.  I am 
trying to create a standard GUI for my product ERROS that would 
automatically web enable any application created with ERROS.  What I 
want is not that complex - I believe that an interface should be simple,

but I want the same interface to be operable both as a point and click 
interface or as a 5250 style interface with function keys and records 
selected from a subfile style of layout.  One thing that I will need to 
do is to find a way of ensuring that it is not necessary to click on the

main input field before being able to type in it.  I vaguely remember 
that this is possible but haven't yet searched through my HTML books to 
find a solution.

I am sure that I will eventually get it all to work, but your kindness 
has cut down the time very dramatically and I much appreciate that.

I am off line the rest of today.

Best wishes

Rob

> Per the standard for defer:
>
>"When set, this boolean attribute provides a hint to the user agent
that
>the script is not going to generate any document content (e.g., no
>"document.write" in javascript) and thus, the user agent can continue
>parsing and rendering."
>
>However, that doesn't say that the agent "MUST" defer processing so
>defer won't do what you want anyway -- at least not reliably. 
>
>Finally, I assume the wrapped string constants in the fm() function are
>from the e-mail and aren't wrapped in your code so I fixed them in my
>test, but didn't count that as an error. If they're wrapped in your
code
>you need to fix that too.
>
>-Walden
>
>
>------------
>Walden H Leverich III
>President & CEO
>Tech Software
>(516) 627-3800 x11
>WaldenL@xxxxxxxxxxxxxxx
>http://www.TechSoftInc.com 
>
>Quiquid latine dictum sit altum viditur.
>(Whatever is said in Latin seems profound.)
> 
>
>  
>
>  
>

_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
RE: Javascript and browser compatability - progress
