ScatterViewItem using CanScale attribute: XamlParseException

Mar 5, 2011 at 4:08 PM

Hallo,

I have a question about the use of the ScatterViewItem of the Surface Toolkit. In the TestApplication.Common you are using Viewbox instead of ScatterViewItem:

            <s:ScatterView Name="scatter" Background="Green" Width="700">
                <Viewbox>
                    <Rectangle Width="200"
                               Height="200"
                               Fill="Red" />
                </Viewbox>
            </s:ScatterView>

That works fine, but the problem is, that a Viewbox can't have manipulation restrictions. As I want to disable the scaling of my items (CanScale="false"), I tried to use the ScatterViewItem in my source code:

<s:ScatterView Height="{Binding ElementName=theScreen,Path=Height}" Width="{Binding ElementName=theScreen,Path=Width}"
                       HorizontalAlignment="Left" Margin="0,0,0,0" x:Name="theScatterView" VerticalAlignment="Top">          
            <s:ScatterViewItem CanScale="False">
                <Rectangle Width="100" Height="100" Fill="Green" />
            </s:ScatterViewItem>
</s:ScatterView>

Sadly I get a XamlParseException saying "The method or operation is not implemented" when I run my application. When I remove the CanScale attributes, the exception disappears.

Seems that the ScatterViewItem of Surface Toolkit Touch 1.5 does not support the CanScale attribute. Did anyone else get this exception? Does someone know a work around for this?

Regards,
HeBu

Coordinator
Mar 8, 2011 at 3:16 AM

CanScale works fine with ScatterViewItems from Surface Toolkit.

Are you sure you don't have any Surface SDK v1.0 references in your application? If you run a Surface v1 application compiled as Any CPU on a 64-bit processor it will crash with not implemented exceptions. Maybe you have Microsoft.Surface.dll v1.0 referenced?

By the way, ScatterView (like ListBox) automatically wraps children in the ItemContainer. For ScatterView the ItemContainer is an ScatterViewItem, and ListBox a ListBoxItem. If the child is already an SVI or LBI, it uses the child as its own ItemContainer. (See ItemsControl.IsItemItsOwnContainerOverride() and ItemsControl.PrepareContainerForItemOverride().)


Mar 8, 2011 at 6:19 PM
joshb wrote: Are you sure you don't have any Surface SDK v1.0 references in your application? If you run a Surface v1 application compiled as Any CPU on a 64-bit processor it will crash with not implemented exceptions. Maybe you have Microsoft.Surface.dll v1.0 referenced?

I just found out, it's the other way around. I referenced the Surface SDK v1.5 where it should be the SDK v1.0!

Here's my project architecture and what I found out:

I have a project TestApplication.Surface (which is the startup project) containing a SurfaceWindow, referencing Microsoft.Surface, Microsoft.Surface.Presentation and Microsoft.Surface.Presentation.Generic from the SDK v1.0

The SurfaceWindows contains a WPF UserControl from another project called TestApplicationViews (like your TestApplication.Common). This project references Microsoft.Surface.Presentation from the SDK v1.5 and it contains a WPF UserControl from a project called Prototype, which also references Microsoft.Surface.Presentation from the SDK v1.5

I have seen that your TestApplication.Common project references the SDK v1.0. When I change it to SDK v1.5 it also will crash when applying the CanScale attribute to the ScatterViewItems. So, are you sure the v1.5 does support the CanScale attribute?

I can't change the SDK to v1.0 in my user controls, because I want to use the TouchUp, Move and Down events and the easier manipulation and intertia handling.

Coordinator
Mar 8, 2011 at 6:26 PM

You can't mix them like that. Fortunately there is a solution. Directly after you build, look for a warning about dependency versions. Double clicking that will add some code to your app.config. For an example, look at the app.config in my TestApplication.Surface:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Surface.Presentation" publicKeyToken="31BF3856AD364E35" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-1.5.0.0" newVersion="1.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

You can redirect the version numbers so they are appropriate. For real Surface applications, redirect to 1.0. For Surface Toolkit, redirect to 1.5.

I also talk about this in more detail on this blog: http://nui.joshland.org/2010/07/sharing-binaries-between-surface-and.html