I have a switch function with four cases: each case executes a sequence of six css changes.

How to stop it, if the viewer wants to abort, by choose another menu option?

I've done a trawl, and the closest I've come to finding something which could be adapted is from this site,
by MattEvans, a while back, buit it had to do with a loop in the function to be stopped:

create a public/global variable called "stopped", set it to false when you start the loop.
inside the loop put:
then when you press "cancel" set the stopped variable to true .

So, maybe something like


function wrapSwitch() {
if(stopped){ break; }
function doSwitch{ etc }

<a href="#" onclick=" 'stopped=true'; doMore(); return false">stop</a>

Any pointers?


5 Years
Discussion Span
Last Post by ctoz

Thanks, I'm actually halfway there, so I won't stop.

Obviously, var stopped = true

if(stopped){ break; }
if this code is inserted in each case of the switch, it will stop whichever function is currently running, but not the ones still to come—they run.

So, it looks like that code needs to be inserted in each of the functions, before they're gathered up into the switch.

I'll get back when/if it's solved.

Another solution is to make the elements which the switch function operates on, and the links which activate it, ajax-loaded so they can all be ajaxed out.


It's not clear what the nature of "running" is. ie. what is going on that needs to be stopped?

I think the solution may lie outside the switch-case structure.

ie. a condition that determines whether the switch-case block, in its entirety, is called.


Edited by Airshow: n/a


what is going on that needs to be stopped

quicker to point to the code than to explain:
from line 224, or look for the comment "//sequence", which lists the components of the switch function, after the big arrays;

to see it in action click "welcome", choose the menu item "ask", and then hit "ready?" and follow through.
There's no kill-link currently, you just have to go through the processes, or re-load.

a condition that determines whether the switch-case block, in its entirety, is called

That's better logic. Maybe the solution is simpler than I think?



I still don't understand enough to be able to help but can offer a critique of the code in general.

In no particular order:

  • Use of global namespace can and should be completely avoided.
  • Event handlers are attached elsewhere, not in the javascript I can see; hopefully not in the HTML.
  • "var" is missing in some functions, thereby making unintentional globals.
  • makeLine1() to makeLine6() could, with a few simple associated changes, be made into one generalised function, saving about 200 lines of code.
  • Inefficient rediscovery of static DOM nodes, eg. $('#loadIt') , $('#bg1') , can be avoided.
  • Inefficient rediscovery of DOM nodes immediately after after insertion, eg. in addX() and addO() , can be avoided.
  • Use of setTimeout("string", xxx) should be avoided in favour of the setTimeout(function(){...}, xxx) form.
  • Obsolete code should be removed.
  • The whole thing would benefit from being refactored to better exploit javascript's object-oriented capabilities. In particular, there could be a hexGram() constructor with methods to give much of the bahaviour currently coded as global functions.
  • With efficient coding, there's no particular reason why Opera users should get a "rough ride".


Edited by Airshow: n/a


Thank you for taking the time to wade through the code.

It had greater redundancies before I started on this re-write.

Ideally, there should be no inline js or css. [ That happens primarily because, for a cut'n'paster, inline is the quickest way to get something working. Then you see if it needs to be an id or class in the css, and whether it's a standalone function or one with variables, in the js—which, I can see, are pretty inefficient but that's as far as I've progressed. So there's a constant cleanup process required. ]

I don't actually understand how to remove code, even after many readings and having the resources within the scripts used on the site. Haven't tackled that yet. My problem not yours. Specific comments, eg about globals, are useful and encouraging. The idea of a hexGram() constructor is at present beyond my competence.

Where, d'you reckon, might one find a professional who'd be interested in taking the code to the level it deserves?




Where, d'you reckon, might one find a professional who'd be interested in taking the code to the level it deserves?

Well, in the first instance, you could ask me. I would be more than happy to discuss.



Thankyou. I'm working on cleaning up the css.

The contact link on the menu at that page is working.

I'll keep an eye out for a message from you.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.