0

我试图弄清楚这些 LayoutAwarePage 是如何实际改变页面状态的。

当方向改变时，会调用以下处理程序：

           this.InvalidateVisualState()

我试图了解调用如何映射到 XAML 中的正确视图状态？IE

<!– Visual states reflect the application’s view state –&gt; 
<VisualStateGroup x:Name="ApplicationViewStates"> 

    <VisualState x:Name="FullScreenLandscape"> 
        .
        .
        .             
    </VisualState> 

    <VisualState x:Name="Filled"> 
        .
        .
        .      
    </VisualState> 

    <!– The entire page respects the narrower 100-pixel margin convention for portrait –&gt; 
    <VisualState x:Name="FullScreenPortrait"> 
        .
        .
        .      
     </VisualState> 

    <!– The back button and title have different styles when snapped –&gt; 
    <VisualState x:Name="Snapped"> 
        .
        .
        .      
     </VisualState> 
</VisualStateGroup>

无论它在做什么显然都能够解析在 VisualStateManager 中声明的正确视觉状态。

另外，为什么它使视觉状态无效，而不是仅仅调用 VisualStateManager.GoToState(this,"Filled",false)例如？InvalidateVisualState 还有什么作用？

4

1 回答 1

1

我认为原因是 VisualStateManager 直接与 Windows“事件”通信。

VisualState 名称“Filled”、“Snapped”等是常量。每当用户捕捉 Metro 应用程序时，都会应用“捕捉”视觉状态。

因此，当引发一个 windows 事件以指示用户转动他的平板电脑或捕捉应用程序时，对 InvalidateVisualState 的调用只是告诉 VisualStateManager 它的当前状态可能是错误的，需要重新计算/刷新。新状态被确定（即，当前的 Metro 应用状态是什么？），当这个状态被确定时，匹配的 VisualState 被应用。

这就是为什么在调用自定义视觉状态时只需要 VisualStateManager.GoToState(this,"Custom",false) 的原因，即不是内置的。

我不保证这实际上是它的工作方式，但它是我理解 VisualStateManager 行为的方式。至少对于 Metro 应用程序而言。

于 2013-06-25T09:17:43.557 回答