Hello to everyone,
There are 3 scenes using the same name. Using Javascript, how do I go from scene 1 to scene 3 without changing scene names?
I apologize for the English. I use Google Translate.
The API is based on naming (hypeDocument.showSceneNamed()), so the names must be different.
A workaround in this specific case could be to call hypeDocument.showNextScene() twice, but that is silly 
.
Is there any particular reason they must be named the same?
Hi Jonathan,
Names in the project should be the same.
hypeDocument.showSceneNamed () does not work because the method gets “string” as a parameter.
The buttons added to the scene go to the desired scene.
If there is no solution, it will be sad for me. 
Why do they have to be the same? Could you not name them Activity1, Activity2? Would make it easier to use javascript API. If you really had to use Javascript then you can store all the scenes in an array and then access them that way. 2 ways to do this
- on scene load run a javascript function that pushes the scene (accessed by element) to a global array or
- do the same but run some code in the Head HTML that does this at runtime instead of having to load a function manually
1 Like
It is true that the runtime falls short at exposing reliable indexed order of scenes. getSceneNames abstracts the index with initially unique keys into an arbitrary index map with user defined keys. Reversing the process and addressing a scene (getSceneNamed) from that dataset is bound to be error prone as the retrieval of a scene is satisfied with the first occurrence of the key. In most cases it is fine but maybe it would be an option to expose showSceneContainer (maybe as getSceneByIndex) in the next release. BTW I would also suggest exposing a hype runtime version getHypeVersion string.
Even if I didn’t bring this up originally but I can think of cases where I need a index over an name. Specially if we use scenes in some programming task or use them in a unusual way. Currently this requires …
- to fetch all names into an array
- the get the current name
- then loop over the array and find a match
- then jump to the scene
Given that there is a scene index array as the basis of the currently exposed
- showSceneNamed
- showNextScene
- showPreviousScene
It wouldn’t be hard to expose it…
Then again this could and has been done in a extension but as mentioned before. The moment somebody names a scene like another (and the interface doesn’t prevent it). We run into the situation that poses the problem above and even a extension can’t fully solve!.
As much as I would also want a goToSceneByIndex
I suspect the issue here is really about the scene names not being named in a useful way.
To me it looks like that should be named
Which can also be used in both actions and javascript.
var buttonClicked = element.id // botton id example : 'Animation_3'
hypeDocument.showSceneNamed( buttonClicked, hypeDocument.kSceneTransitionCrossfade, 1.1)
scenes.hype.zip (67.0 KB)
Thanks for the additional thoughts. As an FYI the API was designed specifically knowing this would be an issue but made to favor ease of use over an object-oriented approach that requires more knowledge. Interestingly this is the vaguely “anti-case” of goToTimeInTimeline labels .
NOOOOoooooo!
1 Like
NO! NO! NO! - Heretical Thinking!!! 
Haha, I just meant that the scene name is like a label, whereas the scene index is more like a time value. That is to say, with document iteration the index-based call may lose the symbolic meaning since it isn’t coupled well. If anything it is a case for timeline labels!
I wonder (loosely ) if we had the ability use the scene id and or class name (append) in GUI we could name and shame them regardless of or in conjunction to scene names.
I will join in … No No No…
The thought that people can remember label or names better then handling numbers is the right approach but it only goes so far… but why must we think dualistic on this matter: it’s neither this or that …it’s… Tada: Both.
If the convenient way (names,labels) isn’t as precise one needs it or doesn’t lend itself to some programming effort we got (numbers and pure timecodes). So it is no contradiction that we argue for either side as both oposite approaches are currently present in Hype and we would be doing unification a great service (timelines get labels and scenes get indexes).