Passage de Java à C#

Citation:

---

Envoyé par Flaburgan

et je ne comprends pas cette ligne dans l'utilisation : SqlDbType leType = SqlDbType.Int;

---

Il s'agit d'une énumération (enum).

Il existe l'équivalent en Java depuis java 5.0.

Citation:

---

Envoyé par Flaburgan

Autre chose, j'ai croisé des paramètres out en C#, je connais à peu près le concept car j'ai fait de l'ADA, l'implémentation est la même en C# ? Un paramètre sans rien d'indiqué par défaut est de type in ? ou in out ?

---

Le mieux est de lire la doc: http://msdn.microsoft.com/fr-fr/libr...(v=VS.90).aspx

J'ai compris ce qu'étaient les délégués, et je commence à assimiler l'utilisation de Linq. Merci à tous.
Des dizaines de questions se précipitent cependant à chaque nouvelle manipulation ^^^^
J'applique RTFM régulièrement, mais pas forcément facile de se retrouver dans le site MSDN
Deux petites pour ce coup-ci donc :
Est-il possible d'importer d'un seul coup plusieurs namespace ?
en java, on peut faire par exemple

Code:

---

import java.util.*

---

pour avoir toutes les classes de java util. Là, j'ai un début de programme qui ressemble déjà à ça

Code:

---

1 2 3 4 5 6 7 8 9 10

using System; using System.Text; using System.Collections.Generic; using System.Linq; using System.Xml.Linq;   using modelisation;   namespace parseur {

---

Alors que je n'ai pratiquement rien écrit. Je n'ose imaginer d'ici quelques semaines le résultat...

En fait, y a-t-il un moyen de régler IntelliSense ou je ne sais quoi pour qu'il nous fasse les imports qu'il faut ??! Je ne supporte plus ce "The type or namespace name 'blablabla' could not be found (are you missing a using directive or an assembly reference?)" argh ! Mais importe le moi ce fichier dont tu as besoin !



Deuxième question, quand on travaille sur des fichiers, où ceux-ci doivent-ils être placés ? Dans le dossier du projet, de la solution... ?
Edit, j'ai trouvé, dans bin puis débug...

Pas d'import en large comme java de type System.*, mais ce n'est guère gênant. Si tu écris un élément non identifié, raccourci alt+maj+F10 sous VS ou cliquer sur le nom de l'objet inconnu permettra de référencer vite fait le namespace, faut pas avoir peur quoi... Les using ça va assez vite au début, mais on ne dépasse pas la douzaine, ou alors la classe fait vraiment fourre-tout... Exception pour ce qui est Winform/WPF, ou tu dépasse assez vite les 20 using, mais ça grossit pas plus que ça. A la longue les using tu n'y feras plus gaffe...

En général dans le projet pour les documents, ça peut être dans des sous-répertoires attachés au projet, tout dépend de comment tu t'organises :)
Tu peux dire que tel fichier peut être intégré dans la dll ou copié vers le répertoire de compilation...

Merci bien!!
Et on continue avec les petites questions, déjà, gros doute, y a-t-il des destructeurs ? Ou un garbage collector, comme en java ? Comment tout cela fonctionne-t-il ?

Ensuite, je suis tombé dans la doc sur des trucs du genre "accepte int, int?, long, long?". Kesecé que ces noms de type avec un ? derrière ? hein ? hein ? hein ?

(curieuuuuuuuux!)

On a le garbage collector, il est possible de créer des destructeurs (technique peu usitée). Par contre les objets devant être nettoyés par le développeur implémente IDisposable (Comme les classes de Stream par exemple), il faut donc appeler Dispose quand tu n'as plus besoin de l'objet (ou le déclarer dans un blog using(){} qui appelle Dispose automatiquement, à ne pas confondre avec le using qui importe un namespace).

Une des principales fuites de mémoire en .net, c'est abonner une méthode à un événement, que l'objet soit détruit sans retirer l'abonnement (donc pour chaque Add(+=), programme de suite le remove (-=)

un ? signifie que la valeur peut être nulle, cela correspond à la classe Nullable<T>. On manipule ces membres avec les propriétés HasValue et Value. Cela ne s'applique aux types valeurs et non aux types références (définies comme étant un struct et non une classe. Exemple : bool, int, double, DateTime...)

Et on retrouve nos deux questions quotidiennes.

Niveau bonnes pratiques, est-ce que déclarer une classe en dehors d'un namespace est quel que chose de mal vue ou normale ?
Dans quel namespace déclarez vous la classe "Application", celle qui contient le main ?

Et niveau sauvegarde, comment sauvegarder vous le contexte d'utilisation du programme lors de sa fermeture ? Quelles sont les méthodes les plus rapides pour une solution du type sérialisation des objets et écriture dans un fichier ?

Je te conseille de regarder les vidéos faites par Pascal Belaud (Microsoft): http://www.microsoft.com/france/visi...lt.aspx?chap=1

Et de revenir avec des questions après. Sinon dans 3 ans on y est encore :mrgreen:

Déclarer une classe en dehors d'un espace de nom, ouai c'est mal vu :aie:
Pour la classe Application, je ne sais pas si beaucoup de gens modifient le namespace créé par défaut quand on crée un nouveau projet avec Visual Studio.

Pour la sauvegarde du contexte, ça dépend. Si c'est des données du type, préférences de l'utilisateur concernant l'application (les options en gros). Tu peux utiliser les settings (une des vidéos précédentes en explique le fonctionnement).
S'il s'agit plus de données métiers, cela peut être une base de données ou un fichier XML par exemple.

Euh, merci pour ton lien, mais quand je clique dessus, il me demande mon nom d'utilisateur et mon mot de passe... ??

Edit : quand je l'ouvre dans un nouvel onglet, je peux quand même y accéder.

Salut à tous,
Tout d'abord, bonne année :)

Ensuite, et bien, j'ai déjà parcouru beaucoup de chemin depuis que j'ai créé ce topic :p

J'ai découvert le MVVM et j'ai ainsi la joie de réussir à structurer mon appli pratiquement comme j'avais l'habitude de le faire en MVC tout en étant compatible WPF (et mine de rien, c'était pas une mince affaire, à la base).

Seulement, d'après MVVM, il ne faut pas de code dans le code-behind. C'est aussi ce qui me semble le plus propre, mais je suis heurté à un problème, comment gérer les clics des utilisateurs facilement ?
Avant, quand j'avais

Code:

---

<MenuItem Header="Quitter" Click="fileExitMenuItem_Click"/>

---

Il me suffisait d'écrire dans le code behind une méthode

Code:

---

1 2	void fileExitMenuItem_Click(object sender, RoutedEventArgs e) {

---

Mais si je veux déplacer cette méthode dans le ViewModel, oulala catastrophe, refus obstiné du compilateur...

Il faut utiliser le concept de commandes (implémentation du pattern Command inclus dans WPF). Dans la classe MenuItem tu as une propriété Command que tu lie (bind) à une priopriété de type ICommand sur le ViewModel.

On en parle ici: http://japf.developpez.com/tutoriels...stables/#LVI-D et sur le net (recherche sur Bing).

Merci beaucoup ! Je ne suis pas encore très à l'aise avec les lambdas utilisés dans l'exemple, mais j'ai compris comment cela fonctionnait.

Autre question, où traiter les erreurs de manière propre ? Par exemple, dans l'équivalent de mon controleur, j'ai une FileNotFoundException. Je fais une messagebox directement dedans, ou bien dois-je faire remonter cela jusqu'à la vue ? Ou bien créer une classe static spécifiquement pour ce genre de cas, avec une message box pour les erreurs, une pour les avertissements, une pour les aides...

Et une dernière pour la route, j'aime poser mes questions par paire, j'ai vu qu'il était facile d'utiliser ObservableCollection<valeur>, mais j'aurais aimé avec une collection sous forme de dictionnaire, donc avec <clé,valeur>, je n'ai pas trouvé l'équivalent sur le msdn, quelqu'un sait si ça existe ou s'il faut que je réimplémente une collection de dictionnaire qui hériterait de INotifyCollectionChanged, INotifyPropertyChanged...
(j'ai regardé ObservableCollection et aucune méthode n'a de corps, s'il suffit de rajouter les events et l'héritage, ce serait plus rapide que de parcourir le web à la recherche du graal..)

Edit : J'ai trouvé quelqu'un qui avait déjà fait le boulot à ma place, et qui balance la source de son ObservableDictionnary, je vais tester ça.

Citation:

---

Envoyé par Flaburgan

Merci beaucoup ! Je ne suis pas encore très à l'aise avec les lambdas utilisés dans l'exemple, mais j'ai compris comment cela fonctionnait.

Autre question, où traiter les erreurs de manière propre ? Par exemple, dans l'équivalent de mon controleur, j'ai une FileNotFoundException. Je fais une messagebox directement dedans, ou bien dois-je faire remonter cela jusqu'à la vue ? Ou bien créer une classe static spécifiquement pour ce genre de cas, avec une message box pour les erreurs, une pour les avertissements, une pour les aides...

Et une dernière pour la route, j'aime poser mes questions par paire, j'ai vu qu'il était facile d'utiliser ObservableCollection<valeur>, mais j'aurais aimé avec une collection sous forme de dictionnaire, donc avec <clé,valeur>, je n'ai pas trouvé l'équivalent sur le msdn, quelqu'un sait si ça existe ou s'il faut que je réimplémente une collection de dictionnaire qui hériterait de INotifyCollectionChanged, INotifyPropertyChanged...
(j'ai regardé ObservableCollection et aucune méthode n'a de corps, s'il suffit de rajouter les events et l'héritage, ce serait plus rapide que de parcourir le web à la recherche du graal..)

Edit : J'ai trouvé quelqu'un qui avait déjà fait le boulot à ma place, et qui balance la source de son ObservableDictionnary, je vais tester ça.

---

Tu peux utiliser sinon le ObservableCollection<Tuple<T1,T2>>, sauf qu'il n'y a pas unicité des clefs.

J'ai pris la classe créée ObservableDictionnary.
Le problème est que quand je l'affiche dans ma treeview, je me retrouve avec des couples clés valeurs sous cette forme : [maClé.ToString(), value.ToString()], c'est aussi ce que je récupére (enfin je crois, vu que je suis obligé de faire un toString) quand je fais SelectItem sur ma treeview. Or moi je voudrais juste récupérer (et afficher) value. Je suppose donc que mon ObservableDictionary ne sert à rien, et que je n'ai qu'à avoir un dictionnaire en interne que je convertis (je ne sais comment) en ObservableCollection, et c'est elle que je donne à la treeview ?

Citation:

---

Envoyé par Flaburgan

J'ai pris la classe créée ObservableDictionnary.
Le problème est que quand je l'affiche dans ma treeview, je me retrouve avec des couples clés valeurs sous cette forme : [maClé.ToString(), value.ToString()], c'est aussi ce que je récupére (enfin je crois, vu que je suis obligé de faire un toString) quand je fais SelectItem sur ma treeview. Or moi je voudrais juste récupérer (et afficher) value. Je suppose donc que mon ObservableDictionary ne sert à rien, et que je n'ai qu'à avoir un dictionnaire en interne que je convertis (je ne sais comment) en ObservableCollection, et c'est elle que je donne à la treeview ?

---

Il faut plutot modifier le ItemTemplate du treeview pour qu'il affiche le bon champs!

Je ne sais pas faire ça :? Je vais essayer de regarder

Edit : Du coup, j'ai fait une liste simple, enfin j'me suis débrouillé quoi ^^
Et pour les messages d'erreur alors ?

J'ajouterai un petit truc sur les using si la place qu'ils prennent te gène :

Code:

---

1 2 3 4 5 6 7

#region Références using System; using System.Data; using System.Data.SqlClient; .... #endregion

---

Ca construit une région repliable histoire d'organiser un peu plus ton code.

C'est une syntaxe proche du préprocesseur de C/C++ (mais attention, c'est pas parce que ca y ressemble qu'il s'agit vraiment d'un préprocesseur C/C++).

Il faut savoir que le .Net et le C# en particulier sont fortement liés à Visual Studio.
Le code que tu tapes peut influer directement sur l'IDE.

Par exemple, tu peux poser des attributs sur tes classes et propriétés :

Code:

---

1 2 3 4 5 6 7 8

public class MonControl : System.Windows.Forms.UserControl { public string UnePropriete { get; set;}   [Browsable(false)] public string UneAutrePropriete { get; set; } }

---

Avec ce code, la propriété "UnePropriete" sera visible et affectable dans le Designer de Visual Studio.
Par contre, la propriété "UneAutrePropriete" n'apparaitra pas dans la grille de propriétés du Designer. Son comportement en terme de programmation reste inchangé.

je n'avais pas pensé à enfermer les using dans une région effectivement ! Merci bien !