Trying to control an automatic submit... need help

[Dodger]

I've been working on this little doohickey for a bit now... (please
ignore the speed issues of some of the queries -- things aren't all
optimised up in mysql yet)

http://www.xfx3d.net/test/storebrowser_frameset.html

Well, I'm also running into Javascript problems...

The idea is supposed to be that a user can select one or more options
from any given menu. As they do so, the options in the table will
repopulate. That bottom frame will be an iframe later, BTW. It was just
simple to throw together this way.

Now, here's the thing... what it should be doing in the javascriptish
end of things:
1) Any time any selection is made other than 'All' in one of the menus,
'All' should be deselected.
2) Any time a selection is made and is different than what was there
before (i.e. an onchange), the form should be submitted.
HOWEVER: If the Control (or Command, on a Mac) key is currently
down, then the form should not be submitted until it's released,
allowing the user to select multiples without them going away while
trying to select them.
3) Based on the selections made, the stuff in the multi selects should
be repopulated.

So the issues I've had:

1) In FireFox, it's a little inconsistent as to whether it realises the
Ctrl/Cmd key is pressed. Sometimes I'll have Control firmly held down,
select something, go to select something else, and... pppprt -- the
form has submitted and the something else goes away now. Not what it's
supposed to do, and not what I coded it to do... but sometimes it just
does. Any idea on why and how to fix?

2) In Safari, the multiselect options are not being repopulated. They
don't go away, and nothing gets added. I get ReferenceError: Base is
not an object. Huh? What's base? Do it all belong to us? I have nothing
in here called Base. To make matters worse, while hitting the Search
and Test this thang buttons works right, the automated submit is
opening a new friggin tab...!?!

3) I haven't even tried it in IE yet. Honestly, I want to make it work
in decent browsers before worrying about that hunk of crap. I figure
with these issues already... well... yeah. FF and Safari, then I'll try
and make the rubbish work with it, too.

Any help? Any at all? Pleaaase?

 

[VK]

http://www.xfx3d.net/test/storebrowser_frameset.html

I can tell one thing (and sorry in advance): that is a *highly*
user-unfriendly interface (almost user-abusing one). You do care about
Ctrl key, but you seem do not care if I'm using Shift to select a range
of options. And if I want to select a range of options and then uncheck
just one which I don't need? And if I prefer to navigate through
options using keyboard? (there is nothing unusual in that, many people
- even w/o disabilities - are using this way)?

So I would highly suggest do not grab the interface out of your
visitor's hands every time she pressed a button or clicked: give her a
second to think, for Chris sees it! ;-) :-|

Get all this autosubmission stuff off completely, make a nice *big*
submit button, and as the last touch assign an accesskey to it so users
could "press" it by using a keyboard shortcut Alt+letter
(Apple+letter).

In application to compatibility tests the suggested sequence would be
also a bit different: make it first to work for Firefox, then see if
you can make it work for Internet Explorer 6.0 That will help you to
sort out unacceptable approaches: because if something doesn't work for
IE6 - it is not suitable for a web-solution.

The rest of UA's can be left for sport in the last turn (if you make it
to work - it's nice, if not - just make sure to have a graceful
degradation).

 

[Dodger]

I can tell one thing (and sorry in advance): that is a *highly*
user-unfriendly interface (almost user-abusing one). You do care about
Ctrl key, but you seem do not care if I'm using Shift to select a range
of options. And if I want to select a range of options and then uncheck
just one which I don't need? And if I prefer to navigate through
options using keyboard? (there is nothing unusual in that, many people
- even w/o disabilities - are using this way)?

You know, I really have to stick with Apple on this one.

So I would highly suggest do not grab the interface out of your
visitor's hands every time she pressed a button or clicked: give her a
second to think, for Chris sees it! ;-) :-|

Get all this autosubmission stuff off completely, make a nice *big*
submit button, and as the last touch assign an accesskey to it so users
could "press" it by using a keyboard shortcut Alt+letter
(Apple+letter).

I figure once Ctrl is taken care of, shift can be worked out too the
same way. Once step at a time for that.

This is what I am doing and what I intend to do, and I really don't
consider there to be anything unfriendly about the UI, and people seem
to be quite fond of iTunes, which takes the same approach.

In application to compatibility tests the suggested sequence would be
also a bit different: make it first to work for Firefox, then see if
you can make it work for Internet Explorer 6.0 That will help you to
sort out unacceptable approaches: because if something doesn't work for
IE6 - it is not suitable for a web-solution.

Actually, since I'm going to be selling 3d assets to artists... Safari
really does take precedence over IE anything.

The rest of UA's can be left for sport in the last turn (if you make it
to work - it's nice, if not - just make sure to have a graceful
degradation).

Nope, Safari really is important. I expect 30% Mac users, and Mac users
use 90% Safari. Even me.

So again,

Any help anyone might have in getting *THIS* to work properly, please!
I need *this* to work *as intended* and reliably -- not something else.

 

[VK]

Any help anyone might have in getting *THIS* to work properly, please!
I need *this* to work *as intended* and reliably -- not something else.

Please don't take it as "do what I said or get out". An insistent
suggestion, but nothing beyond this border.

You cannot do THIS to work for IE, because IE implements different
onChange schema for <select>, that forcely excludes interface users
using IE and keyboard, which will be (on a real run) higher than MacOS
users viewing your page using Safari.
So putting it in plain words you want a browser-specific solution with
disregard to the amount of users unable to benefit out of your
solution: and this is typically out of interests of c.l.j. *but* I'm
sure there can be people around here willing to help you.