Est-il possible d'utiliser StaticResource dans un contrôle WPF bibliothèque et être en mesure d'afficher au moment de la conception?

J'ai un Contrôle WPF Bibliothèque qui est ajoutée à une application windows forms. Nous voulons permettre les contrôles pour être localisable, mais je ne suis pas sûr de la façon de l'accomplir PLEINEMENT ce sans duplication de code. C'est ce que je fais maintenant.

Pour l'essentiel, dans l'application windows forms, avant l'application principale débute, je suis de l'instanciation de l'Application.xaml qui vivent dans les formes de l'app (contenant mes liens vers mes ressources qui vivent également dans les formes de l'app). Cela fonctionne parfaitement pour l'exécution.

Cependant, mon utilisateur, les contrôles ont tous Content="{StaticResource SomeVariableName}", qui finissent par être vide. Je peux résoudre ce problème en ayant une application.xaml et appropriée des ressources dictionnaires dans ma bibliothèque de contrôle qui correspondent à ceux de mon application windows forms. Cependant, c'est le code dupliqué.

Choses que j'ai déjà essayé en vain:

• Instancier l'Application.xaml qui vit dans le contrôle de l'utilisateur de la bibliothèque de l'intérieur les formulaires de mon application. Cela ne fonctionne pas parce que l'Uri de mes ressources est à la recherche d'une ressource incorporée, pas mon local dictionnaire de ressources (je pourrais ensuite il suffit de copier les fichiers de ressources à partir du contrôle à un endroit approprié dans les formulaires de mon application sur le build). Pourrais-je tirer parti de DeferrableContent ici? Il n'y a pas beaucoup en ligne autant que j'ai pu trouver sur cet attribut, et comment il doit être utilisé, cependant.
• Je voudrais utiliser post construit pour les App et les dictionnaires, cependant, l'Application de l'instanciation est une référence statique à la compilation d'un App.xaml pour autant que je peux dire. Donc, App.xaml doit vivre à l'intérieur de la forme au moins
  • J'ai essayé d'avoir un double App.xaml avec un post-construction de déplacer le resourcedictionary.xaml. J'ai pensé qu'un double app.xaml est ok, puisque c'est la force motrice et vous pourriez ne pas vouloir dépendre d'un seul à partir du contrôle de toute façon (ce qui ramène et vous fait vous demander si vous devriez alors avoir l'Application.xaml dans le contrôle à tous? Sauf si vous voulez permettre à un défaut qui utilise des ressources intégrées....) Qui n'a pas pu en disant qu'il ne pouvait pas trouver la ressource, même si elle a été placée là où l'URI doit avoir été pointant vers. Le code décompilé points de Uri resourceLocater = new Uri("/WindowsFormsApplication3;component/app.xaml", UriKind.Relative);

Donc, Est-il un moyen pour permettre de travailler ET d'avoir le temps de conception de la visualisation de l'élément par défaut ET éviter les doubles emplois? Ou, est la duplication OK dans ce cas? Si ma 2ème puce sous-élément semble ok (double App.xaml avec construire copié resourcedictionaries), comment dois-je faire de ce pas chercher un composant de niveau élément, mais à la place un fichier d'un niveau?

Dernière question (et je peux poster séparément si nécessaire) que je viens de payer attention. Mon Application.xaml est en cours de construction dans le code, de sorte que ne me permet pas de créer de nouveaux ResourceDictionaries à la volée de toute façon. Est-il possible de faire cela?

Option finale...peut-être le meilleur?
- J'ai l'intention sur l'utilisation de André van Heerwaarde du code de toute façon, donc si je viens de vérifier l'existence d'un fichier et l'ajouter comme une fusion de ressources à la volée? En gros, avoir une Application.xaml dans mon de contrôle de l'utilisateur qui est lié à un défaut intégré ResourceDictionary. Et, alors le code pour le des ressources localisées à la volée, ce qui peut être relatif chemins d'accès aux fichiers? Le seul inconvénient que je vois ici, c'est que le défaut ne peut pas être changée à la volée...qui je pourrais probablement même l'avoir regarder dans un lieu déterminé (à l'aide d'une sorte de convention) et qui ont préféré au cours de la intégré dans un?

Oh, et ma raison pour ne pas vouloir les ressources intégrées est de sorte que les utilisateurs peuvent ajouter/modifier des nouvelles ressources localisées après la construction, est déployé.

Je peux ajouter le code si il va vous aider à visualiser ce mieux, faites le moi savoir.

Mise à JOUR

Je suis maintenant confronté à un autre problème avec style et pas seulement de la localisation.

Voici un exemple de l'un des boutons internes sur l'une des commandes:

<Button Style="{StaticResource GrayButton}"

Des choses un peu plus, j'ai essayé/pensée:

• Je ne peux pas créer une application.xaml (qui ne serait jamais utilisé) avec ResourceDictionary mis en place comme ApplicationDefinitions ne sont pas autorisés dans la bibliothèque de projets. J'ai pu intégrer ceci dans le contrôle des ressources, mais alors ce serait toujours la priorité sur toutes les applications de niveau de ressources et je perds la capacité de personnalisation.

Voici un connectez cas qui sonne comme ce que je recherche, mais il n'apporte aucune réelle solution à ce

La solution (au-delà du top..ce qui ne fonctionne pas) que je pense, c'est peut-être (et n'ai pas encore essayer) semble aussi que beaucoup de travail pour quelque chose qui je pense devrait être simple. Mais, je pourrais être capable de créer des propriétés de dépendance dans le contrôle que je peux Lier, puis permettre à ceux d'être écrasé par le projet, qui va être à l'aide de la commande. Comme je l'ai dit, cela ressemble à beaucoup de travail pour un assez simple demande :). Serait-ce le même travail? Et, plus important encore, est-il une meilleure solution, plus simple, que je suis absent?