WeAreSync.net

Quoi de plus agréable, au petit matin, de découvrir le plaisant petit mot que me laisse Visual Studio après 10 minutes de compilation ! J'apprécie tout particulièrement la clarté avec laquelle tu t'exprimes parfois, dans le soucis constant de me faire gagner du temps et de me rendre la vie plus facile...

Error 37 error LNK2019: unresolved external symbol "private: static void __cdecl CImport::GetChannelsForThisMaterial(class daeSmartRef,class std::list > &)" (?GetChannelsForThisMaterial@CImport@@CAXV?$daeSmartRef@VdomMaterial@@@@AAV?$list@HV?$allocator@H@std@@@std@@@Z) referenced in function "private: static void __cdecl CImport::ReadMaterial(class C3DScene *,class daeSmartRef,class stdext::hash_map,class std::allocator >,unsigned int,class stdext::hash_compare,class std::allocator >,struct std::less,class std::allocator > > >,class std::allocator,class std::allocator > const ,unsigned int> > > &,class stdext::hash_map,class std::allocator >,unsigned int,class stdext::hash_compare,class std::allocator >,struct std::less,class std::allocator > > >,class std::allocator,class std::allocator > const ,unsigned int> > > &)" (?ReadMaterial@CImport@@CAXPAVC3DScene@@V?$daeSmartRef@VdomBind_material@@@@AAV?$hash_map@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IV?$hash_compare@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@U?$less@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@stdext@@V?$allocator@U?$pair@$$CBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@I@std@@@2@@stdext@@2@Z) import.obj collada

Allez, on décrypte maintenant :-)

---

Il y a plusieurs façons de définir la source d'un binding. Le plus simple consiste à faire appel au contenu de la propriété DataContext. Cette propriété à une particularité intéressante : lorsque sa valeur est définie pour un contrôle, elle est aussi transmise par default à tous ses fils. Ainsi, en affectant un objet au DataContext d'une Window, tout les contrôles de votre Window seront associés par défaut à cet objet. Bien sûr, vous pouvez redéfinir le DataContext de chaque contrôle à n'importe quel moment.

• Binding sur le DataContext :

     <ListBox ItemsSource="{Binding}" />

• Binding sur un autre élément :

     <Slider Name="_mySlider"/>
     <TextBlock Text="{Binding ElementName=_mySlider,Path=Value}"/>

• Binding sur soi-même :

     <TextBlock Name="_selfName"
                Text="{Binding Name, RelativeSource={RelativeSource Self}}" />

• Binding vers un parent :

     <Canvas Name="_canvas">
         <TextBlock Text="{Binding Path=Name, 
                                   RelativeSource=
      {RelativeSource FindAncestor, AncestorType={x:Type Canvas}}}" />
     </Canvas>

• Binding vers le template parent :

     <ControlTemplate x:Key="_template">
         <TextBlock Background="{TemplateBinding Background}"/>
     </ControlTemplate>

• Binding vers le data item précédent :

     <TextBlock Text="{Binding RelativeSource={RelativeSource PreviousData}}" />

• Binding d'une propriété statique :

     <TextBlock Text="{x:Static local:Window1.AStaticProperty}"/>

• Binding d'une ressource statique :

     <TextBlock Background="{StaticResource _blackBrush}"/>

• Binding d'une ressource dynamique :

     <TextBlock Background="{DynamicResource _blackBrush}"/>

• Binding sur un enum :

Là, les choses sont un peu plus complexes. Il existe deux méthodes à ma connaissance. Une qui utilise un ObjectDataProvider et une autre qui utilise les Markup Extensions. La deuxième solution me semble beaucoup plus efficace :

using System;
using System.Windows.Markup;
 
namespace EnumValuesMarkupExtensions
{
    [MarkupExtensionReturnType(typeof(Array))]
    public class EnumValuesExtension : MarkupExtension
    {
        public EnumValuesExtension()
        {
        }
 
        public EnumValuesExtension(Type enumType)
        {
            this.EnumType = enumType;
        }
 
        [ConstructorArgument("enumType")]
        public Type EnumType { get; set; }
 
        public override object ProvideValue(IServiceProvider serviceProvider)
        {
            return Enum.GetValues(EnumType);
        }
    }
}

Et en Xaml, il ne reste plus qu'à définir la propriété ItemsSource d'un ComboBox de cette façon :

<Window x:Class="EnumValuesMarkupExtension.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:my="clr-namespace:EnumValuesMarkupExtension"
        xmlns:sys="clr-namespace:System;assembly=mscorlib"
        Title="Window1" Height="300" Width="300">
    <Grid>
        <ComboBox ItemsSource="{my:EnumValues sys:DayOfWeek}" SelectedIndex="0" />
    </Grid>
</Window>

Voir aussi :

• Définir la source d'un binding
• Petite révision sur le Binding
• Binding en Silverlight 2.0

---

Le Binding est certainement l'une des fonctionnalités de .Net que j'affectionne le plus parce qu'elle est élégante et peut faire gagner pas mal de temps lorsqu'on la maitrise bien. Pourquoi élégante ? Parce qu'elle permet de faire une séparation très nette entre le code et l'interface. C'est pour cette raison qu'il s'agit d'un des principes clef des frameworks tels que MVVM.

Comme rien ne vaut mieux qu'un exemple pour comprendre les choses, imaginons les classes suivantes :

public class Produit
{
  public string Nom { get; set; }
  public double Prix { get; set; }
}
 
public class Magasin
{
  private readonly List<Produit> _produits = new List<Produit>();
  public List<Produit> Produits
  { 
    get
    {
      return _produits;
    }
  }
}
 

Si on souhaite afficher les produits de notre magasin, il suffit de créer en Xaml :

 
<ListBox x:Name="MonMagasin" ItemsSource="{Binding Produits}">
  <ListBox.ItemTemplate>
    <StackPanel Orientation="Horizontal">
      <TextBlock Text="{Binding Nom}" Margin="0,0,5,0" />
      <TextBlock Text="{Binding Prix}" />
    </StackPanel >
  </ListBox.ItemTemplate>
</ListBox>
 

Il ne reste plus qu'a affecter notre magasin au DataContext de la listbox pour lier le contrôle à nos données et le tour est joué :

Magasin magasin = new Magasin();
magasin.Produits.Add(new Produit { Nom = "Tomates", Prix = 10});
magasin.Produits.Add(new Produit { Nom = "Pommes", Prix = 12});
magasin.Produits.Add(new Produit { Nom = "Orange", Prix = 8});
MonMagasin.DataContext = magasin;
 

On obtient une listbox qui affiche les produits de notre magasin. Mais à ce stade, que ce passe t'il si quelque part dans le code, on modifie le prix d'un des produits ? Rien du tout. L'interface ne reflète pas les changements de notre propriété. Nous allons voir dans un prochain article comment y remédier.

Voir aussi :

• Définir la source d'un binding
• Petite révision sur le Binding
• Binding en Silverlight 2.0

---

Je profite du dernier post de Cyril Durand pour finaliser un petit article que j'avais entamé sans jamais vraiment le finir. Il concerne le problème du binding des services WFC sur un IIS qui gère plusieurs identités pour le même site web :

 This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Parameter name: item

où pour les francophones :

Cette collection contient déjà une adresse avec le schéma http. Une adresse tout au plus par schéma est possible dans cette collection.
Nom du paramètre : item

Voici ce qui se passe lorsque vous avez un site web configuré avec plusieurs identités ( ex: www.siteweb.com et siteweb.com ) lorsque vous tentez d'accéder au fichier Service.svc de votre service WCF.

Pourquoi ? WCF ne supporte pas les identités multiples sur le même site. Comment faire dès lors pour résoudre cette épineuse situation ?

De nombreux blogs proposent des solutions, qui si elles ne résolvent pas réellement le problème, ont le mérite d'aider à comprendre comment tout cela fonctionne :

Sur developpez.net, un premier échanges m'a permit d'identifier que le problème venait effectivement des identités multiples. Les serveurs mutualisés qui n'y font pas attention sont les premiers touchés.

Une première solution est donnée par Rob Reynolds : Il faut dériver la classe ServiceHostFactory comme suit :

 
using System.ServiceModel;
using System.ServiceModel.Activation;
 
public class CustomServiceFactory : ServiceHostFactory
{
 
 private int baseAddressIndex = 0;
 
 protected override ServiceHost CreateServiceHost(System.Type serviceType,
   System.Uri[] baseAddresses)
 {
    return new ServiceHost(serviceType, baseAddresses[baseAddressIndex]);
 }
}
 

Puis, dans le fichier *.svc :

 
<%@ ServiceHost Language="VB" Debug="true"
Service="Organization.Services.TempService"
Factory="Organization.Services.CustomServiceFactory" %>
 

Premier problème, comment connaitre l'indice de l'adresse qu'on souhaite utiliser ?
Deuxième problème, que se passe t'il si notre service WPF est instancié pour le nom de domaine www.siteweb.com une première fois (là ça marche) et qu'on tente d'y accéder ensuite via siteweb.com (là, ça marche plus).

L'idée n'était pourtant pas si mal et venait d'ici à l'origine.

Deux autres échanges ici et là m'ont finalement menés à une solution qui semblait prometteuse. Mais voila, la solution du filtre permet en pratique de faire fonctionner WCF avec une seule identité. Or, je ne souhaite pas choisir en www.siteweb.com et siteweb.com, je veux que la solution marche dans tout les cas !

---