Forum Discussion
Overlapping States
Hello Carrie,
Thanks for reaching out!
Just to clarify the behavior you're experiencing, the built-in states by design are treated as a layer on top of the normal state, which means if an object from the normal state is not completely covered when a built-in state is shown, the object will be visible in the built-in layer. We have an open feature request to improve this behavior based on the feedback shared here in the community, and we'll let you know if there are any updates.
One way around this is to use custom states instead. I've attached a sample project file that compares the behavior of built-in states with custom states. You'll notice using custom states prevents objects in the normal state from appearing when a change state occurs.
If you don't mind me mentioning, as the original poster, this was not 'normal' behavior several years ago when I reported the bug originally. It actively caused issues mid-project, which was what prompted me to open a support case, where Articulate staff acknowledged the issue and logged it as a "software bug".
Could you provide some context or history on the issue? I've been trying to find out information about my support case that's been open for over three years, but I'm finding out more information in Articulate's replies to other people's comments on my post than I am directly from Articulate.
I don't mean to come off as complaining! I believe some transparency would really help in instances like this! I don't mind if it takes several years for Articulate to address a bug, so long as its being addressed and I can see/know its being addressed. I get that Articulate has a lot of pots on a lot of stoves, and some things can sit on the back burner a bit longer. However, reading that the bug is now considered 'normal' behavior and the fix is now a 'requested feature' is a bit disheartening and confusing.