IS vs. IS NOT Trigger Bug?

Jun 29, 2021

Joseph Francis
By Joseph Francis

We recently encountered an issue with re-published files where functionality which previously worked (which was based on solutions posted to this forum at least a full version of Storyline ago) no longer work.

In the attached example Storyline file, there are 4 sliders which have 2 user-draggable positions and a center starting position. Dragging a slider to either the left or the right changes the state of its (normally off-screen) assigned indicator from Normal to Activated. This is done in the Object Trigger for each slider (Change state of rectangle n to Activated When slider n moves If its value is not equal to 1). As you can see, that functionality works fine.

The problem is when all 4 sliders have been moved and the learner needs to move on. There are 3 Object Triggers, yet only 1 fires. The first Object Trigger changes the value of Boolean variable bolSlide_01 from False (its initial state) to True; the second Trigger changes the state of the Next button from Disabled (its initial state) to Normal. These Triggers are based on the states of the 4 indicators not being Normal. The 3rd Trigger, which shows the Feedback layer, is based on the states of the 4 indicators being Activated.

Programmatically, the two trigger statements (When the state of all rectangles is not Normal / When the state of all rectangles is Activated) are equivalent logical operators, and both should fire when the states of all 4 rectangles are NOT Normal, i.e. Activated.

To demonstrate the difference, run the file and observe the results. Then, change one of the 2 Object Triggers from is not Normal to is Activated and run it again.

8 Replies
Walt Hamilton
almost 3 years ago06/29/21 at 11:15 pm (UTC)

For those who may read this thread later, I would like to point out that this statement:


Programmatically, the two trigger statements (When the state of all rectangles is not Normal / When the state of all rectangles is Activated) are equivalent logical operators


is not always necessarily true. While it is true in the case of the slide you attached, if the rectangles have other states, they could be in a selected state, which is neither Normal, nor Activated.
Your question: "Is this a IS vs IS NOT bug?" isn't broad enough in scope to encompass the true problem, nor the answer. The problem is the way Articulate has designed and executed "When state of XXX is ..." Most of us recognize that "when state is" is not an action, and shouldn't be capable of initiating a trigger. So we assume that what it really means is "when state becomes", and write our triggers accordingly. But SL didn't implement it that way. It doesn't have a true listener, that is listening for states to change. Rather, it seems to sporadically check and see what the states are, and use the states as conditions. My experience is that the internal trigger really works like "Take action when checker checks states if all the rectangles are Activated." So "when state of" works sometimes, and not others. It has traditionally worked only for a maximum of 4 or 5 objects at a time. Further complicating things is the fact that the quasi-listener at best listens for objects arriving in states, but not leaving a state (as you found out.) That is why the "is Activated" works, while "is not Normal" doesn't.
Another potential problem that you don't have, but a potential reader might, is that all the built-in states are overlays of Normal, and thus all report themselves as normal. So IS NOT Normal doesn't work for any of them.
So I know; "When all of XXX are state YYY" is really glamorous and easy to write, but I try to resist. If it absolutely must work every time, I will write "Change state of Next to Normal when slide 1 changes if state of rectangles 2, 3, and 4 are activated". The listeners for variables are always listening and aren't limited in numbers.

Joseph Francis
almost 3 years ago06/30/21 at 1:48 pm (UTC)

Your response kinda glosses over the issue that at one point, that conditional trigger did work. Now, it doesn't. It's not that I couldn't code around it (I already did, and in a more-absolute way), it's the fact that for others who may have used the IS NOT state of an object as a trigger (when it was functional), Articulate, in its infinite wisdom, quietly removed that functionality. The next time they open and republish a previously-working course, it will hang at that point.

It would be akin to taking my perfectly-working car in to the shop for a simple oil change, and they, without fanfare, "fix" the way the steering wheel works, by making the wheels turn in the opposite direction of the way the wheel turns. But only when travelling above 55 MPH.

Miles Henderson
over 1 year ago10/12/22 at 3:10 pm (UTC)

So if I understand it correctly, what you're saying is:

Old trigger reads:
"Set the state of the NEXT BUTTON to NORMAL when:
     "the state of all RECTANGLES (sliders) is not Normal"

But if you change it to make it "positive" it works, so you alter the trigger to be when the state of all SLIDERS is (are) ACTIVATED

It has been a year, and I'm still fairly new to SL, but can confirm this bug still exists.

Jose Tansengco
over 1 year ago10/13/22 at 4:02 pm (UTC)

Hi Miles, 

I'd like to take a closer look at this behavior to see if this behavior is a bug that needs to be reported to the product team. Would you be willing to share a copy of your project file here or in private through a support case so we can verify the behavior? We'll delete it as soon as we're done testing. 

Jose Tansengco
over 1 year ago10/14/22 at 3:31 pm (UTC)

Hi Miles and Nejc, 

Thanks for sharing additional details regarding the behavior. I checked Nejc's support case and it looks like we still have an open bug that causes the 'Is not normal' trigger condition to not work properly under certain situations. 

I've added this support case to the bug report so we can notify everyone when a fix is released. For everyone's reference, here's a quick look at how we tackle bugs. 

Sign In to Reply