Hi VK, Gerard,
Thanks for the replies. Please see below.
Gérard Talbot said:
Richard Maher wrote :
It depends. You have not given a lot of details here. Which form
control? Which user action? What kind of behavior? It could be, just a
guess, that you are looking for DOMActivate event.
and a setEvent() function but, in the
No details. No specifics. No url. No general description of what you are
actually looking to accomplish in a given webpage, having a specific
issue or something.
change the contents: it could be that you are looking for mutation
events here.
(i.e.
onselect can be used only on input text form control and on textarea. If
you want to highlight a particular string on a webpage, that's a
different story. onfocus on a lot of element but not on any/all HTML
elements.
(or anything!) to
Not possible to queue an event really. Again, some of your questions
would be easier to answer if we knew exactly what you are trying to do:
general description, overview, which form control, what user action, etc.
Gérard
Let me try to explain; painful experience coupled with the lack of responses
to my other "Stop! Button" thread has led me to the belief that it is simply
not possible (within the constrains of a Web Browser html,Javascrip,DOM) to
implement a a hot-abort or "Stop!" button that could interrupt, or bypass,
an ONevent long enough to use an Applet method to send an OOB character down
the socket, so that my server knows to stop what it's doing.
[Actually, it's a lot worse than that! The ludicrous state of affairs
witnessed just now on my IE6 Windows2000 session is that, whilst an ONevent
is currently executing my JS function, not only can I not press one of *my*
form buttons but the Global IE STOP button is also disabled and whatsmore is
if I try to close the bloody browser, Windows says "The program is not
responding" do I wish to kill it :-( And yes I have induced extended delays
with timed waits; elapsed-time is not the norm or expected behaviour.]
So, in desperate search of Plan B, I decided to look at the idea of
surrendering the event thread as often as possible so as to give all the
other events a window of opportunity to get on the event
stack/que/whateveryoucallit. This is how I'd imagine it "working": -
I send the work request down the socket via my applet. Now, instead of just
blocking on the Read I create a new applet method that does a
inputstream.available() and if I don't have enough bytes then I
fireEvent(this) and RETURN. If there are enough bytes then I continue with
the Read and process the server message then go again till EOF. Would it
work?
The main problem I have with it is the whole idea of polling is completely
anathema to me! I know PC people (and especially many web pages) do it all
the time, but it is simply badness. Having said that, would it work? Would
other events get through that tight little loop?
OK, I give up! Randy was right; just do it all in Java. When the user get's
the dialog box for username/password I'll stick another tick box that asks
if they want "CornuCopiaeControl". I suppose this could result in that
dangling dialog box with, in addition to a Stop button (that could change
color when it was active) I could put "Bytes sent, Bytes received, Connect
time, Username, HostName etc etc". Or I could forget the whole hot-abort
idea. Shit it was only meant to be a nice-to-have 'cos the server took
interrupts
Alles klar?
Regards Richard Maher