Forum Discussion
Trigger before a "timeline ends"
Hi DanielChodos I'm pleased to announce that I did it! In fact, ChapGPT did all the work. 😄 Let me explain.
I was very surprised when I looked at your .story file. In all possible cases, SlideElapsedTime is only known at the END of the slide. “Elapsed” is a clue, even for me, who doesn't speak English very well. So, anticipating a temporal event based on an unknown final duration is... difficult.
I just spent 3 hours this morning making Chappy sweat over the difficulty of finding the expected duration of the slide. He failed a dozen times. Finally, I suggested he look at the progress bar, since its scrolling speed automatically adapts to the final duration as soon as the slide starts. Indeed, in the debugging console, it has a “max” value of 5000 if the slide duration is 5s, 10000 if the duration is 10s, and so on. Chappy warmly congratulated me on this idea and I was very proud of it. The rest was pretty quick.
Everything works exactly as you want it to, I think, whatever the length of the slide. Even if you remove the progress bar! Give it a try. The timing (-2s, -5s) of the event is adjustable in the JScode. You can now duplicate this slide and change its duration in the timeline.
Look at the .story file. It's all there: slides 2 and 3.
I'd like to know if this works for you.
ThierryEMMANUEL thank you for your help with this. The JScode works and the annotations are helpful to understand what parts are doing what.
I did find an interesting anomaly with the functionality. If you click on the seekbar and skip forward some, it breaks the timing and the EventTrigger variable changes by the amount that you change the seekbar. This happens even if you reset the slide part way through. BUT, if you let the slide play through once, it fixes itself. This is very odd, but there are ways to preventing skipping around in the seekbar.
Hello DanielChodos . I'm very happy that your problem is “marked as solved”. I must confess that I tested the slides many times before sending you the file, but I hadn't tried to crash it! 😅 I couldn't quite reproduce the anomaly described, but it makes sense. The solution is to retrieve the duration of the slide (via the progress bar) but does not depend on the behavior of the bar. So, whatever you do with the bar, the duration is always (for example) 5s, and the event takes place at 5 minus 2s. And if you make the bar disappear: no bar, no bar manipulation, no problem.