Contrôle d'accès à des propriétés d'une autre classe en C# WPF
Je suis dans un désordre de la visibilité entre les classes. S'il vous plaît, m'aider avec cette question de newbie.
J'ai deux contrôles (DatePickers de défaut WPF boîte à outils) qui sont dans des fenêtres différentes, dans les différentes classes. Je peux facilement accéder à ces contrôles propriétés comme datePicker1.Text
de l'intérieur de sa classe native, c'est à dire dans sa fenêtre native, mais quand j'essaie d'atteindre datePicker1.Text
à partir d'une autre fenêtre, je ne reçois rien.
J'essaie d'accorder de la valeur d'un datePicker à l'autre, à l'aide de la référence à la fenêtre de mon code:
string testStr;
...
AnotherWindow aw = new AnotherWindow();
testStr = aw.datePicker2.Text;
datePicker1.Text = testStr;
et il ne fonctionne pas
aussi j'ai essayé de le faire par le biais de la propriété publique d'une classe, comme:
public partial class AnotherWindow : Window
{
....
public string dateNearest
{
get { return datePicker2.Text; }
set { datePicker2.Text = value; }
}
....
et ensuite l'utiliser dans une autre fenêtre:
string testStr;
...
AnotherWindow aw = new AnotherWindow();
testStr = aw.dateNearest;
mais aussi pas de valeur assignée.
S'il vous plaît, aidez-moi à comprendre cette question fondamentale. Je sais qu'il y a d'autres manières d'accéder à valeurs dans WPF comme la liaison de données, mais je voudrais comprendre les bases en premier.
Je dirais que je suis plutôt novice en C# et même à l'ensemble de la programmation orientée objet. J'ai une solide expérience de l'automatisation industrielle et les langages procéduraux. Oui, mes premières tentatives en C# ont été en WinForms
OriginalL'auteur rem | 2009-12-30
Vous devez vous connecter pour publier un commentaire.
Je suis en utilisant visual studio 2010 beta 2 droit maintenant et qui plante régulièrement faire le plus simple WPF codage, comme tentent de le dupliquer une question de code 🙂 : mais pensez-y :
Est-il possible que l'utilisation de cette syntaxe "do the right thing" :
Edit 1 : Ok, j'ai un WPF réplication de votre code qui ne tombe pas en panne : à l'aide de la syntaxe ci-dessus, je peux à la fois d'obtenir et de définir la propriété dans les "autres fenêtre."
Edit 2 : Le code fonctionne également à l'aide de votre code d'origine 🙂 ce Qui me semblait être "la bonne" la première fois que je l'ai lu. Êtes-vous définissez cette propriété avant de vous le lire ? : à ma connaissance un DateTimePicker du Texte de la propriété sera une chaîne vide par défaut lors de la première création.
Edit 3 : en réponse à la Rem de la demande :
la fenêtre principale a un bouton button1 : les tests de réglage et d'obtenir les Biens Publics DTContent défini dans le cas de la deuxième Fenêtre nommée : 'WindowAdded : voici le" gestionnaire d'événements Click pour le bouton dans la fenêtre principale du code :
Edit 4 : une meilleure "monde réel". exemple : la plupart des cas, vous allez vouloir créer une instance d'une autre fenêtre, et gardez-la, pour la ré-utilisation: à mon humble avis : pas ont-il exister que dans le cadre de l'événement Click d'un bouton. Considérez donc, s'il vous plaît :
Quelque part dans le champ d'application de la fenêtre principale du code de définir un "titulaire" de la fenêtre(s), vous permettra d'ajouter : privé WindowAdded wa;
Dans le cas vous sélectionnez comme le plus approprié pour la création de l'instance de la fenêtre : créer l'instance, et de l'affecter à votre "titulaire" de la variable : puis de le ré-utiliser comme nécessaire. En WinForms j'ai le plus souvent nécessaire de créer des fenêtres secondaires que j'ai besoin de ré-utiliser des références à des instances d'accéder à quelque chose sur eux dans le load du formulaire principal ou montré les événements.
Discussion : bien sûr, si votre intention est de créer des "temporaire" de windows, et vous n'avez pas besoin de ré-utiliser que la référence à la nouvelle fenêtre de l'instance de nouveau, puis la création dans le champ d'application d'une certaine fonction est fine.
Et, si la seule chose que vous avez besoin d'accéder à votre deuxième Fenêtre est le DateTimePicker, puis vous utilisez la même technique proposée ci-dessus, mais de créer et de tenir à une référence à l'instance de la DateTimePicker seulement.
Concernant votre Edit 2, s'il vous plaît, pourriez-vous montrer dans le code vous permet d'accéder datePicker2.Le texte dans une autre fenêtre?
Cette solution permettra de résoudre votre problème @rem. La propriété Text de la DatePicker dans la fenêtre 1 est visible uniquement dans le cadre de la fenêtre 1. De l'exposer comme une propriété publique dans la classe de fenêtre permettent d'affichage et de manipulation de la fenêtre 2.
Je vais l'appeler Window1 la fenêtre principale, et Window2 le "secondaire" de la fenêtre qui est créé par le code dans Window1 : dans ce cas, nous comptons sur le fait que Window1, en vertu de son être le "créateur" de Window2, a accès à une référence à l'instance de Window2, et son public "quoi que ce soit." Mon exemple, en montrant la nouvelle Fenêtre en cours de création dans un événement de Clic de bouton, est, à certains égards, un mauvais exemple de "monde réel" code de l'puisque la référence à l'instance de Window2 existe uniquement dans la portée de l'événement click du bouton sur Window1. Je vais devoir faire quelque chose à ce sujet ! merci,
s'il vous plaît, par tous les moyens, de montrer l'OP la meilleure façon ! L'aider à voir pourquoi c'est mieux. Et OP, Rem, quand vous voyez une meilleure façon démontré ici, s'il vous plaît accepter cette réponse que votre réponse. Mon impression est que le programmeur est libre de choisir la mesure à laquelle il ou elle travaille en C# vs XAML. J'ai répondu à la discussion de la question qui a été tout à fait spécifiques.
OriginalL'auteur BillW
Malheureusement, les bases de WPF sont des liaisons de données. Faire d'une autre manière est de "contre-courant", est une mauvaise pratique, et est généralement ordres de grandeur plus complexe à coder et à comprendre.
À votre question, si vous avez des données à partager entre les points de vue (et même si c'est seulement un vue), créer un modèle de vue classe qui contient des propriétés pour représenter les données, et de lier les propriétés de votre vue(s).
Dans votre code, seulement gérer votre modèle de vue de classe, et ne pas toucher le réel avec ses contrôles visuels et de la composition visuelle.
Mon expérience a été que si vous essayez de "transition" la pire des WinForms techniques de conception en WPF, vos développeurs finissent par avoir un mauvais dessins depuis des années sur la fin. Vous pouvez même finir par avoir à les remplacer par d'autres développeurs pour obtenir décent code WPF. D'autre part, si vous au lieu de leur montrer comment ils peuvent faire leur tâche beaucoup plus facile en utilisant WPF et MVVM, ils ne seront jamais aller dans le mauvais chemin, et les choses seront beaucoup mieux pour eux dans le long terme.
Je suis d'accord avec les deux opinions contradictoires. Les meilleures pratiques sont les "must" pour les programmeurs professionnels, mais "doux approche de transition" est parfois vital pour les apprenants. Il est très important d'obtenir quelque chose de travail, même dans de sales et forme brute (certains "Hello world"), puis d'aller de l'avant sans de la frustration.
pour moi "liaison de données" ne se chevauchent pas avec les concepts de "l'injection de dépendance," ou CIO, l'art, l'artisanat, et de la science, de OO développement ainsi que les références nécessaires et les interactions entre les objets sont mis en œuvre de manière efficace, et maintainably. Pour moi, la présence de tous ces "cadres" (l'Unité, d'un Château, et ainsi de suite) qui sont fleurissent un peu partout pour vous permettre de mettre en œuvre MVC ou MVVM, ou quelle que soit la saveur de l'année de la philosophie de design, suggèrent un défaut fondamental dans la conception de WPF et de l'IDE lui-même. De travail dans le code XAML, à mon humble avis, est un retour à l'âge de pierre 🙂
MVVM n'est pas la saveur de l'année, c'est le modèle fondamental WPF a été conçu pour. Vous pouvez laisser tout aller, mais si vous n'utilisez pas MVVM, vous vous dirigez dans un marais.
OriginalL'auteur Aviad P.
Que les autres ont déjà souligné, ce n'est probablement pas la voie à suivre, mais vous pouvez utiliser:
Pour définir l'objet public.
Voir msdn pour plus d'info.
OriginalL'auteur Olle