Re: Javascript and browser compatability

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.)

Re: Javascript and browser compatability - progress