Actually, not seeing what I thought. It appears that you need to have some control that depends on the toggle control all together on the screen. It's not as simple as having "some" control from the other screen on the "calling" screen.
uggg...this is going to bite me!!
But, I still protest...this is changed in the player now and it would seem any discrepency between behavior in design time and run/play time is a bug.
@Mr-Dang-MSFT it's true that this effects only a few people use this Pattern. But in my case there is no problem here, cause another pattern I use is to basically build only one screen apps.
@RandyHayes I understand your point, but I also think this is not so bad as a design. Basically, it means that not all the screens have to be initialized when they are not visible. So faster loading of the app in this case. This behaviour is also not changed recently, I already had the issue almost a year ago.
I'm not so concerned about the fact that this issue exists (and how I've not seen this before baffles me - although looking over the apps and situations, I can see how it would only have been a coincidence that would have brought it to my attention sooner).
The only factor that concerns me is that the behavior in design time is different than run time. Those are the type of things that cause someone to design around the behavior that is in front of them (design time) and then find out that run time doesn't work that way...meaning that perhaps a lot of time is wasted designing something that will not play.
That said, I believe that this should fail to work in design time or work the same in play.
@Mr-Dang-MSFT I realize that my initial responses after your first in this thread...I totally missed your last sentend point about the referenced control on the screen. Got it now...but the above concerns still exist.