Triggers "when state of ... is ..." not working as expected
Dec 19, 2018
Since accessing objects state is not possible from javascript I decided to do boolean variables reflecting the down state of a number of pictures (the internal hover and down states added manually to a picture object).
After a while I found a solution to this but it doesn't work as I expected it to do in all cases.
As you see in the screenshot I have four picture objects, what you don't see is that they have a hover and down state. You see the triggers I have inserted on each picture to set and clear the boolean variables displayed below each picture.
Picture 1 and 2 would probably not work as intended anyway since they check for state normal for clearing the variable and I have a hover state, but even that doesn't really seem to work as should be expected since leaving the picture doesn't clear it either.
Picture 4 works as expected, but not picture 3. The triggers are displayed the same in the trigger panel but are set up differently and I can't understand why nr 3 doesn't work as well as nr 4.
Attaching example file.
30 Replies
This post was removed by the author
I want the corresponding variable to be true when the respective picture is pressed, that is when the state is "Down".
I would expect picture 3 and picture 4 tp change V3 and V4 respectively in the same way. The parts you have higlighted looks the same in the trigger list and I would expect the same behaviour even if they are created slightly different, but I don't, picture 4 works but not picture 3
... when State None Of ... Is: Down
should behave the same as
... when State All Of ... Is not: Down
If there is only one object selected in the list of objects.
By pure logic this should be the same, one works the other doesn't and I would like to know why, and I strongly suspect this to be a bug.
This post was removed by the author
Thanks for your time, but I am not really looking for a way to solve it, but rather to understand why it doesn't work as expected. Picture 4 in my example file solve my immediate problem fine enough but understanding why the other ones doesn't work is an important part in developing faster and with less errors in the future.
This post was removed by the author
Yes, I am aware of that, and I would like to know why "none of is down" doesn't work when "all of is NOT down" does. Logically they are the same when only one object is selected.
Hi there, Johan. Thanks for sharing your file. I looked and also saw some behavior that felt a bit counterintuitive. Picture 3 wouldn't change the variable when in the down state. When I removed the second trigger, Picture 3 would then change the variable in the down state.
I'm going to ask for some help from my teammates on the support team to have a closer look at the logic between "none of X is X" and "any of X is not X." We've identified some issues with using "Normal" in these "when state of X" setups as well, so I'll ask my team to address that with you too.
You'll get an email from them soon!
Thanks
John was able to identify a couple of issues with these "when state of X is X" triggers. We found that triggers referring to the Normal state were failing to execute. And we also noticed timing issues with "none of" used in the state trigger setup.
Thanks for working through it with us. We'll let you know of any changes we make to this behavior. For now, does using the "all of X is NOT X," as in picture 4, work for you?
Yes that works for me for the moment.
When will this be fixed
When none of .... are Normal or When all of .... are not Normal still do not work.
See also my recent post: https://community.articulate.com/discussions/articulate-storyline/strange-behavior-states-in-drag-and-drop-interaction
I also tried it with an own state myNormal (see attached project), but that was not the solution.
Thanks for reaching out and letting us know that you've been affected by this as well, Chris.
It's still open with our team.
I wanted to share some information on how we define bugs and how we tackle them when they occur.
I'll update the impact to reflect additional users.
Great news, everyone!
We fixed the issue where there would be timing issues when 'none of' and 'all of' were used in the state trigger setup. Here's how to update Storyline 360 to see all the recent enhancements and fixes.
If the problem reappears, please record a Peek 360 screencast for me and I'll be happy to help!
I tried it, but it still does not work as expected (see also https://community.articulate.com/discussions/articulate-storyline/strange-behavior-states-in-drag-and-drop-interaction). The change of the states of drop objects is not detected by the state trigger.
Hey there, Chris!
Thanks so much for replying back with your findings, and I'm sorry this problem resurfaced.
We'll need to take a second look at this, where I've shared your example with our Support Engineers. Keep an eye out for an email from the support@articulate.com soon after we carefully review the behavior!
This issue is still present and has been for the past several versions. I am currently running v3.46.23620.0. If I could use this functionality it would significantly reduce the time it takes to create a work around for it.
For example, I have a toggle switch on screen (on/off). If I could trigger based on the state of the toggle it would be a simple matter of creating two triggers. But the best work around I have found is to create a variable and toggle it true/false and then change the state based on the variable change. This gets really bad when you have multiples of these types of toggles as I have to create a new variable for every single one.
Same here. I would love to see this fixed.
Hello Fridolin,
I appreciate you chiming in to share that you're experiencing a similar issue, but I'm unsure which conversation above you are referring to.
If you could share the details of what you are seeing, that would be helpful. With your permission, I'd like to take a look at your project file to investigate what's happening. You can share it publicly here, or send it to me privately by uploading it here. I'll delete it when I'm done troubleshooting.
This post was removed by the author
Hi Leslie,
I am referring to states as a trigger. I attached a file showing the issue.
I have 4 buttons as a set and a shape which is hidden and set the trigger as follows:
(i have the egrman version, so translation might be incorrect)
If state of all "button 1,2,3,4" is not "normal"
then: change state of "shape "to "normal"
So, if I click all 4 buttons, the should all have the state "visited" or "active" which means the hidden shape should appear. But it does not - the shape never appears.
If I set it to:
If state of none "button 1,2,3,4" is "normal"
then: change state of "shape "to "normal"
The shape appears as soon as I clicked the first button.
If I set the trigger to:
If state of at least one "button 1,2,3,4" is not "normal"
then: change state of "shape "to "normal"
I expect the shape to appear as soon as i clicked the first button. Even when i clicked all the buttons, the shape does not appear.
I then set the default state to a custom state, since i read that "normal" sometimes leads to unexpected result.
If state of none "button 1,2,3,4" is "start"
then: change state of "shape "to "normal"
the shape shows from the very beginning. Althought allof the buttons are "start"
If I set it to:
If state of all "button 1,2,3,4" is not "start"
then: change state of "shape "to "normal"
the shape will not appear, even if all buttons are visited/active.
Thanks for sharing your .story file, Fridolin.
I was able to take a look and I'm seeing the behavior you are reporting and it is similar to the other reports we've seen and this conversation is attached so that we can share updates with you in the future.
In the meantime, I've added an additional slide to your sample project. If you take a look at Slide 2.1, I've set the trigger to change the state of 'OK' to Normal when the state of all of the buttons (1, 2, 3, and 4) are visited. It's working as expected.
Fridolin,
Be aware that "Visited" is a normal state, and reports itself as "Normal".
Be aware that "When states are..." is very flakey, because it is not an action, so doesn't always fire triggers. This is especially true when there are more states to check (four or five seem to be the limit), and is even more of a problem with a NOT condition.
That's why Leslie's approach (States are "Visited") works.
It's not just the Normal state that is a problem. I've attached simple 1-slide Storyline file in which I have 3 buttons that all have a Selected state.
I want the Submit button to be in the Normal state if at least one of the other buttons is in the Selected state, and I want the Submit button to be set to the Disabled state if none of the other buttons are in the Selected state.
The trigger to change the state of the Submit button to Normal is straightforward and works fine:
As Johan identified over 2 years ago, the logic for changing the state of the Submit button back to disabled when all of the other buttons are not in the Selected state can be expressed in two equivalent ways. The more obvious way is to use the "When the state of none of...is Selected":
Unfortunately, this does not work--the Submit button never gets changed to the Normal state, even when none of the other three buttons are Selected.
A logically-equivalent way to express this is to use the "When the state of all of...is not Selected":
This statement is a bit more awkward, but is logically equivalent to the statement that doesn't work. However, this trigger works fine.
Bottom line: There appears to be a bug (perhaps a long-standing one) in the implementation of the "When the state of none of" trigger, and it does not appear limited to instances where the Normal state is involved.
I've attached my Storyline file which has both versions of the trigger to disable the Submit button, so you can toggle back and forth between them (by disabling the one you don't want) to make testing easier.
Thanks for that explanation and sample file, Ray.
I was able to follow along and record a Peek 360 video outlining the issue with my team, so much appreciated.
This conversation is attached so that we can share any updates with you here, but I'm happy that you were also able to find a solution in the meantime.