locked
Value converter xaml that worked with Blend 3 won't render in Blend 4 & other things broken after upgrade. RRS feed

  • Question

  • I upgraded my enterprise app to Silverlight 4 and Blend 4 not long ago.  The app compiles and runs just fine.  However, there are a number of things that don't render in Blend 4 that used to render fine in Blend 3 and it is making it darn near impossible to work with the xaml on these controls at all.

    Is there some "new" way of writing these, or is this just a Bug and if it is a Bug when can we expect a patch?

    Example 1:

    <Button x:Name="btnRemoveWord" Visibility="{Binding Path=IsSelected,Mode=OneWay,ConverterParameter=false,Converter={StaticResource boolToVis}}" Height="20" Width="20" Content="X" Style="{StaticResource ButtonGreyStyle}" Click="btnRemoveWord_Click"/>
    

    Gives an invalid xaml error with no detail/empty stack trace.  If I remove the Converter={StaticResource boolToVis} it renders. Obviously I need the converter though because I'm converting a boolean property value to a visibility. (boolToVis is defined at the global level and exists in the code, so this is not a missing reference issue).

     

    Example 2:

    All of my custom canvas controls fail to render as well.

    Basically I will define a user control that is just a canvas with graphical elements on it, it doesn't actually do anything - just basically to represent an "icon" that will be used on other elements.

    So I will use it in say a button template like so:

    <ControlTemplate x:Key="DomainBtnSmTemplate" TargetType="Button"><br/>
       	<Canvas x:Name="New_Domain" Width="50" Height="71.318" Canvas.Left="-0.0628815" Canvas.Top="-0.586914"><br/>
       		<strong><eqd:DomainIconCanvas x:Name="canvasDomainIcon" Width="63.25"></eqd:DomainIconCanvas><br/>
    </strong>
       		<TextBlock Height="19.584" Width="50.187" Canvas.Top="53.416" Text="{TemplateBinding Content}" TextAlignment="Center" FontSize="9" TextWrapping="NoWrap" FontFamily="./Fonts/Fonts.zip#Segoe UI"/><br/>
       	</Canvas><br/>
    </ControlTemplate>
    
    The control template will also generate an invalid xaml error with an empty stack trace.  It does this with every single user control that I have sitting on another user control (the namespace "eqd" is defined properly).  If I go to the DomainIconCanvas itself and open it in blend, it does not have any errors and renders properly (as I said, it's just a bunch of visual elements with no functionality).

    My application is huge and I'd really rather not have to go back and rework everything in it to get it to play nicely with Blend 4, but I will if I have to.  So I am seeking either reasonable workarounds and/or acknowledgment that they are bugs that will be fixed.  Any help is appreciated.

    As I mentioned before all these things work at execution time -- just not in Blend 4.

    Thanks in advance,

    Anye

    Tuesday, August 10, 2010 9:48 PM

Answers

  • It took me awhile to get back to this - when I was putting together the repro project, I didn't have the issue, so I started digging deeper and eventually isolated that it was the same problem for both issues.

     

    Basically, in Blend 4, namespaces are resolved purely based on folder structure, NOT by what namespace they are actually in.  Blend 3 resolved based on the actual namespace.

    When we first started working on this project we didn't have the same level of organization that we eventually came up with.  We made a Common folder for some class files (including the ValueConverters) and an Images folder for our xaml image canvases and then moved the files into these folders from the root where they had been originally created.  We did not change the namespace when we did this.

     

    Thus, in Blend 3, which resolved namespaces based on reality, there was no problem locating the files.  In Blend 4, which relies on the folder structure -- the files could not be found because it was insisting that if the file was in the Root/Common folder it MUST be in the Root.Common namespace.  When I changed the namespace of the file to match the folder structure and changed the references in Blend to point to the new namespace, the files were resolved and the Blend errors went away.

     

    People creating new projects in a pre-determined folder structure won't have this issue because when you create the file in the Root.Common folder it automatically puts it in the Root.Common namespace -- but this is a big gotcha for people reorganizing existing projects. And, since the code actually works fine when you compile and run it -- it's not immediately apparent until you try to use Blend that you've created a problem just by moving the file to a subfolder.

    Thanks for the offer to help, Harry.

    • Marked as answer by anyeone Thursday, September 23, 2010 4:18 PM
    Thursday, September 23, 2010 4:18 PM

All replies

  • bump...

    also, one of my devs isolated that the ValueConverter issue only occurs when the converter IS a valid reference.

    If you type a nonsense name in the Converter={StaticResource garbageName} part of the node, blend will still render.

    (Of course if you use a nonsense name, the code-behind will complain... and the converter won't actually work)

    Thursday, August 12, 2010 11:11 PM
  • Hi,
    I was trying to re-produce the error you got but couldn't make it. Is it possible for you to share the partial code that generated the xaml error to harryh at microsoft dot com? Please remove any intellectual property in your shared code.

     


    Thanks, Harry [MSFT]
    Friday, August 13, 2010 12:11 AM
  • It took me awhile to get back to this - when I was putting together the repro project, I didn't have the issue, so I started digging deeper and eventually isolated that it was the same problem for both issues.

     

    Basically, in Blend 4, namespaces are resolved purely based on folder structure, NOT by what namespace they are actually in.  Blend 3 resolved based on the actual namespace.

    When we first started working on this project we didn't have the same level of organization that we eventually came up with.  We made a Common folder for some class files (including the ValueConverters) and an Images folder for our xaml image canvases and then moved the files into these folders from the root where they had been originally created.  We did not change the namespace when we did this.

     

    Thus, in Blend 3, which resolved namespaces based on reality, there was no problem locating the files.  In Blend 4, which relies on the folder structure -- the files could not be found because it was insisting that if the file was in the Root/Common folder it MUST be in the Root.Common namespace.  When I changed the namespace of the file to match the folder structure and changed the references in Blend to point to the new namespace, the files were resolved and the Blend errors went away.

     

    People creating new projects in a pre-determined folder structure won't have this issue because when you create the file in the Root.Common folder it automatically puts it in the Root.Common namespace -- but this is a big gotcha for people reorganizing existing projects. And, since the code actually works fine when you compile and run it -- it's not immediately apparent until you try to use Blend that you've created a problem just by moving the file to a subfolder.

    Thanks for the offer to help, Harry.

    • Marked as answer by anyeone Thursday, September 23, 2010 4:18 PM
    Thursday, September 23, 2010 4:18 PM