public ObservableCollection<String> FrameImages { get; }
public NomDeTaClasse()
{
this.FrameImages = new ObservableCollection<String>();
}
private void clickFolder(object sender, RoutedEventArgs e)
{
var folders = FolderBrowserLib.FolderBrowserLib.Instance.GetFolders();
this.FrameImages.Clear();
foreach (var fold in folders)
{
if (fold.Name == "Folder 1")
{
var listFiles = fold.GetFiles();
foreach (var file in listFiles)
{
this.FrameImages.Add(file);
}
}
}
}
<GroupBox Grid.Column="1" Grid.Row="1">
<!-- S'assurer que DataContext = Contrôle en cours, puisque la property FrameImages est définie sur le contrôle lui même-->
<ScrollViewer VerticalScrollBarVisibility="Auto" HorizontalScrollBarVisibility="Disabled">
<ListBox IsSynchronizedWithCurrentItem="True"
Name="PhotosListBox"
ItemsSource="{Binding FrameImages, Mode=OneTime}"
Style="{StaticResource PhotoListBoxStyle}"
Margin="5"
SelectionMode="Extended"
SelectedIndex="0"
MouseDoubleClick="OnPhotoClick">
<ListBox.ItemTemplate>
<DataTemplate>
<Image Source="{Binding ., Mode=OneTime}"/>
</DataTemplate>
</ListBox.ItemTemplate>
<ListBox.ContextMenu>
<ContextMenu>
<MenuItem Header="Edit" Click="editPhoto"/>
</ContextMenu>
</ListBox.ContextMenu>
</ListBox>
</ScrollViewer>
</GroupBox>
A moins que tu n'ai de solide raison pour processer toi même, à la main, les images et leurs décodage, laisse plutôt faire WPF.
Edit : Note aussi que tu utilise "var", donc je n'ai aucune idée des types de sortie de ton API bizarre. Ca me donne une raison de plus de détester ce mot clé : En plus de ne pas être compréhensible au 1er coup d'oeil, c'est compliqué de copier-coller le code sur un forum et de se faire facilement comprendre de tous.
Faut pas en vouloir au mot clé, c'est comme tout outil, comment on s'en sert. Les guidelines préconisent de ne l'utiliser que lorsque le type de l'expression assignée est claire (cas classiques, éviter une répétition lors d'une instanciation ou l'assignation d'un literal)
Censément, quelqu'un de sensé est censé s'exprimer sensément.
Oui oui, j'ai tendance à exagérer . Pour l'histoire, cette "haine" a démarré quand, dans un contexte pro, j'avais demandé des clarifications à un collègue auteur d'un bout de code qu'il me fallait corriger et que même lui ne savait pas reconnaitre les types de retours de son propre code, à cause justement de ce "var" et de l'usage de LINQ saupoudré d'inférence à tout étage. Quant on en arrive à des extrêmes pareil, j'estime qu'un discours extrême en défaveur de tout ça n'est pas spécialement disproportionné .
...Même si je reconnais que, du coup, ça permet de rédiger beaucoup plus vite et dans certains cas, c'est incontournable (types anonymes, notamment avec LINQ). Fondamentalement et comme tu le précise : var ou pas var, je m'en fiche un peu, tant "qu'on" (du moins, quelqu'un d'autre que l'auteur d'origine du code) comprend sans avoir la nécessité absolue de réfléchir 3h ou de devoir sortir un Visual Studio juste pour connaitre un type.
A noter aussi que dans la remarque en fin de ma réponse, c'était juste pour préciser que dans l'exemple de code joint, j'ai utilisé "ObservableCollection<String>" et que j'ai "bêtement" ajouté le retour de "fold.GetFiles()", quand bien même je n'ai, en réalité, aucune idée de si il s'agit d'un type [énumérable de] String ou d'autre chose. Ca sous-entendait donc que mon code pouvait ne pas compiler si il était simplement copié/collé. Et l'usage de String "à l'aveugle" est justifié également pour montrer que WPF "sait faire un peu de magie", comme décoder une image (détecter le type d'image, construire le bon décodeur et la bonne source d'image, sans avoir à le faire manuellement), juste en lui donnant à manger un chemin de fichier contenu dans un String.
Pensez a mettre +1 aux messages qui vous ont aidé et mettre résolu quand cela l'est.