Change class based on coordinates and/or hit?

Warning: I’m not entirely sure that I’m about to explain the following very well (lack of sleep/frazzled noodle/overthinking-things-now) :crazy_face:

So my question is… is it possible to change the class of an element as it’s dragged on-and-off another element?

For example, an element… let’s say an ellipse… would have a class of ‘draggable’ while it’s located ‘outside’ let’s say a background rectangle. The ellipse’s class would change from ‘draggable’ to a class of ‘dropped’ whenever it’s dragged over the rectangle. Conversely, it would revert to a class of ‘draggable’ whenever it’s dragged off the rectangle.


I’ve been scouring tonnages of info about hit tests etc but I’m now so deep in confusion I think it’s time to throw my quandary to you dudes in the hope that fresh minds might be able to point me in the right direction :slightly_smiling_face:

Many thanks, in advance, for any advice.


Hype Demo: (12.7 KB)


Drag the ellipse (starting color “grey” - set in Hype interface) onto the rectangle - it turns red (class “dropped”).
Drag the ellipse off the rectangle it turns green (class “droppedAndMoved”).


The CSS (class) is set in “HTML Head”. Function “hitCheck” does the work.

In the code the rectangle is given an ID of “dropTarget”; the ellipse is simply referenced as the “element”.

Example code in the demo for changing the class:


Note: If You just wanted the ellipse turned back to grey (original color set in Hype) you will not need the “droppedAndMoved” class (green color) in the CSS or the “droppedAndMoved” add/remove class code in the “hitCheck” function.


Given you have a worked with dragging in Hype before the JS needed to add and remove a class can be found here … basically all you need is to do the following commands:


and vice versa …


Update: Just saw that @JimScott posted something :slight_smile: along these line! Two people same thought…

1 Like

You superstars, both of you! I’m checking out all you’ve posted right now!

@MaxZieb, I was having a look at the classList side of things earlier today but I obviously wasn’t implementing it properly. I’ll study it all more closely.

And @JimScott, thank you so much for your demo… I’m keenly investigating it even as I type! :slightly_smiling_face:

Cheeeeeeeeeeeeeeers! x

1 Like

Honking Horn right

Just a quick (although who knows :flushed:) extra question… is there a relatively simple way to target the classes that have changed and return them to their original class when a scene reloads?

I can’t seem to get the changed classes to ‘respond’ to anything.

I’ve been trying hard but getting nowhere for ages. Hope you can help shed some light :slightly_smiling_face:


Hype Demo: (22.7 KB)

This demo is slightly different in the set-up than my previous version…

There are now two scenes:

Scene 1
There are two elements now to drag on to the target square; and there is only one type of class change - from the original color to the new color (red) when moved on to the target square. When moving the element(s) out of the square they revert to their original color.

Scene 2
Basic scene with a back button to Scene 1.

New function “resetClasses”
Uses “querySelectorAll” to create a list all the elements with the class name “dropped”.
A “for loop” then cycles through this “classList” and removes the “dropped” class from the given element.

“setTimeout” is used to control when this class removal happens (in the Demo 2000 milliseconds - 2 seconds). Please see below for an additional note.

This function is triggered by the “On Scene Unload” handler in “Scene 1”.

In order to hide the switching of colors when the “dropped” class is removed “setTimeout” is used in the function “resetClasses”. This is done so the removal of the “dropped” class (i.e. the color change) is delayed by a set amount of time, and therefore not obvious when using Scene transitions other than “Instant”.

So for transitions other than “Instant” make sure the “setTimeout” is longer than the Scene transition time You select for the Scene (“Jump to Scene”) in the “Actions” menu. In the Demo the Scene transition is 1.1 seconds; in the function the setTimeout is 2000 milliseconds (2 seconds).
You must use milliseconds in the Javascript.

Please see the bottom lines of the code below showing this time set-up.

function "resetClasses"

setTimeout(function(){ // wait 2 seconds (i.e. 2000 milliseconds) before resetting the class(es)
		var resetClass = document.querySelectorAll(".dropped");
		var i;
		for (i = 0; i < resetClass.length; i++) { 
	}, 2000);
// make sure this time is longer than the scene transition time for transitions other than instant. This time is in milliseconds - so our time here, 2000, is equal to 2 seconds

Outstanding! Huge, huge thanks for that - and for the wonderfully informative overview and comments (I love the tip about ‘hiding’ the class change by time-delaying the reset… brilliant!).

It does exactly what I was hoping to achieve… and now I’m going back over it all and studying it with forensic curiosity, just for fun, at 2.00am on a Bank Holiday Monday; yes, I am that sad :grinning:

Anyway, many thanks, once again! :clap::clap::clap::clap::clap:

1 Like

You’re Welcome!

What I wrote to You was possible because of what I learned from the generous offerings of other members.

What would the rest of the World would be like if it operated with the ethos of this Forum? :smiley:

1 Like

A much, much, much better one, I think we can say :slightly_smiling_face:

1 Like

I would just run this code on scene unload :smiley: unless there are other dependencies? That way no need to worry about timeout

1 Like


The function “resetClasses” is triggered by the “On Scene Unload” event in the Demo.

I found that if I did not use the “setTimeout” method the removeClass (i.e. reset the element colors) would occur before “Scene One” had transitioned to “Scene Two” - or am I not catching your drift? :ocean:

Screen Capture Example:
“Scene One” to “Scene Two” transition without the “setTimeout” method being used (reset of colors visible):


@JimScott Whoops, my bad. Should’ve read the whole thing.

You can also put the reset without the timer on scene load on the 2nd scene. Thus not having to worry about timers and transition… :wink:

1 Like

Could also run an external script that does the reset for you negating the need to include a function on every scene load within the doc. :wink: (831 Bytes)

Just drag into Hypes resources pane :wink:


Actually, I tried this approach first - but realized as a larger strategy - if there were several scenes that were linked to from the “initiating” scene, each “linked to scene” would need to have this code; and it would be more efficient to have a singular “reset” from the initiating Scene.

Also, I had never worked with a “visual reset” before when transitioning Scenes (as opposed to storing data) - I would have thought that “On Scene Unload” cleaned up the visuals after the Scene had transitioned. I wish it worked in this fashion - I do not see the benefit of making any changes (visual resets) manifested immediately - but a minor detail easily compensated.

Beautiful… minimal.

Thanks to You both for your amazing stewardship on this Forum! :notes:


Thank you @JimScott for this sample and for the many others!

It would be possible to change the class of the elements when an element it is part of a Persistent Symbol?

Thank you.


Demo: (23.0 KB)

In this Demo we are changing the class (i.e. background color established in the “Head HTML” section) of a rectangle element in a persistent symbol from red to blue (and back again) via the “changeRectColor” function triggered by the “Toggle” button in either of the two scenes.

As You will see, going back and forth between scenes yields the same background color for the rectangle unless the color is changed by the “Toggle” button in either scene.

I commented out two lines in the “changeRectColor” function:

These lines demonstrate an alternate way to change class instead of a “toggle” effect.

1 Like

I am sorry but my current project is not going to allow time for working out a solution in the near future - hopefully one of the other Forum members can help out with your request. Good luck!

perhaps it’s a good idea to keep things simple :slight_smile:

at least your request should be understandable …