Un peu de mon expérience dans le monde .NET
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 29 | 30 | 31 | 1 | 2 | 3 | 4 | | 5 | 6 | 7 | 8 | 9 | 10 | 11 | | 12 | 13 | 14 | 15 | 16 | 17 | 18 | | 19 | 20 | 21 | 22 | 23 | 24 | 25 | | 26 | 27 | 28 | 29 | 30 | 1 | 2 | | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
Search
Navigation
Categories
Blogroll
|

Monday, September 07, 2009
Gesture API Code Managé
Windows Mobile 6.5 introduit une nouvelle API prenant en compte le gestion des gestes. Les exemples fournis dans le SDK ne sont malheureusement disponible qu'en C++.
De nombreux exemples et codes open-source étaient disponible (notemment sous www.codeplex.com) pour géré ces gestes. L'API de Microsoft est désormais disponible pour le code managé, grâce à Alex Yakhnin et Ron Buckton qui ont crée un Wrapper, disponible sur le MSDN : http://code.msdn.microsoft.com/gestureswm.
Il est désormais possible de générer une nouvelle expérience utilisateur de manière "relativement" simple.
Monday, September 07, 2009 3:47:17 PM (GMT Daylight Time, UTC+01:00)
C# | Windows Mobile

Wednesday, July 16, 2008
Microsoft Shell Controls And Automation
Un collègue m’a soumis un problème intéressant :
Comment récupérer, depuis une application .NET, les informations inscrites dans les propriétés d’un fichier (bouton droit de la souris, menu propriété). Je précise bien, les propriétés système de fichier d’un fichier, et non pas les propriétés applicatives du fichier (propriétés d’un document Word, Excel ou PDF).
Un rapide coup d’œil sur le namespace System.IO montre que le Framework n’a rien pour gérer celaL. J’étends mes recherches et trouve rapidement que la clé se trouve dans l’objet COM Microsoft Shell Controls And Automation.
Je développe la solution, la test et peux la libellé « Work on my machine ». Test suivant : un poste utilisateur. Et là, malheur, problème d’interop sous .NET, la journée va être longue.
Après troubleshooting, le problème à été rapidement résolut :
Le poste de test ne reconnaissait pas l’interface IShellDispatch5, alors que le poste de développement oui ??? Le Shell n’estt donc pas identique sous XP que sous Vista L, alors que la Shell32.dll fait la même taille.
L’application .Net faisant référence à un objet COM, un wrapper est automatiquement crée par VS : Interop.Shell32.dll. J’ai crée cet Interop sur un poste XP et l’ai mis dans le répertoir de l’application .Net et celle-ci fonctionne comme une fleur autant sous XP que sous Vista !
Reste quelques questions sans réponses :
- Pourquoi cette erreur apparaît, même lorsque je force l’interface (cast) à IShellDispatch4 ?
- Lors de la création dynamique de l’objet COM (Activator.CreateInstance(…)), je ne peux pas invoquer les membres de l’objet (MethodInfo.invokMember(…))
Finalement, voici un exemple de code afin de récupérer la propriété Auteur :
IShellDispatch4 shellDispatch = (IShellDispatch4)new Shell32.ShellClass();
Folder folder = ((IShellDispatch4) shellDispatch).NameSpace(Path.GetDirectoryName(@"c:\\toto.txt"));
FolderItem folderItem = folder.ParseName(Path.GetFileName(@"c:\\toto.txt"));
// 0= le nom
// 1= La taille
// ...
// 9= l'auteur
// 11= objet
// 12= catégorie
return folder.GetDetailsOf(folderItem, 9);
Wednesday, July 16, 2008 3:02:10 PM (GMT Daylight Time, UTC+01:00)
C#

Tuesday, July 15, 2008
Extraire les utilisateurs d'un groupe dans Active Directory
Voici un exemple de code afin d'accèder aux membres d'un groupe dans l'AD ...
String ADFullPath = LDAP://NomDeLAD;
DirectoryEntry Ldap = new DirectoryEntry(ADFullPath);
DirectorySearcher searcher = new DirectorySearcher(Ldap);
searcher.Filter = "(&(objectClass=group)(cn=" + GroupName + "))";
SearchResult results = searcher.FindOne();
if (results != null)
{
DirectoryEntry AdGroup = new DirectoryEntry(results.Path);
System.DirectoryServices.PropertyCollection pcoll = AdGroup.Properties;
int n = pcoll["member"].Count;
for (int l = 0; l < n; l++)
{
DirectoryEntry AdUser = new DirectoryEntry(ADFullPath + "/" + pcoll["member"][l].ToString());
TreeNode tn = new TreeNode(AdUser.Properties["name"].Value.ToString());
tvwMembres.Nodes.Add(tn);
TreeNode tn1 = new TreeNode(AdUser.Properties["description"].Value.ToString());
tn1.ImageIndex = 2;
tn1.SelectedImageIndex = tn1.ImageIndex;
tn1.ToolTipText = "description";
tn.Nodes.Add(tn1);
TreeNode tn2 = new TreeNode(AdUser.Properties["sAMAccountName"].Value.ToString());
tn2.ImageIndex = 1;
tn2.SelectedImageIndex = tn2.ImageIndex;
tn2.ToolTipText = "Account Name";
tn.Nodes.Add(tn2);
TreeNode tn3 = new TreeNode(AdUser.Properties["mail"].Value.ToString());
tn3.ImageIndex = 3;
tn3.SelectedImageIndex = tn3.ImageIndex;
tn3.ToolTipText = "Mail";
tn.Nodes.Add(tn3);
TreeNode tn4 = new TreeNode(AdUser.Properties["physicalDeliveryOfficeName"].Value.ToString());
tn4.ImageIndex = 4;
tn4.SelectedImageIndex = tn4.ImageIndex;
tn4.ToolTipText = "Office Name";
tn.Nodes.Add(tn4);
AdUser.Close();
}
Ldap.Close();
AdGroup.Close();
Tuesday, July 15, 2008 2:22:19 PM (GMT Daylight Time, UTC+01:00)
C# | Active Directory

Tuesday, January 15, 2008

Tuesday, October 16, 2007
Rendre une méthode obsolète …
J’ai cherché comment rendre une méthode obsolète en .NET. En effet, j’ai crée une nouvelle méthode lors de l’évolution d’un projet, mais ne pouvais pas supprimer (ou remplacer) l’ancienne méthode.
La solution est simple : il suffit d’ajouter l’attribut [Obsolete]
Trois signature s’offrent à nous :
[Obsolete]
void Methode() {}
Qui indiquera simplement, via intellisense, que la méthode est obsolète
[Obsolete(« Cette méthode à été remplacée par XXX » )]
void Methode() {}
Qui indiquera simplement, via intellisense, que la méthode est obsolète en indiquant la raison.
[Obsolete(« Cette méthode à été remplacée par XXX », true )]
void Methode() {}
Générera en plus une erreur lors de la compilation.
Tuesday, October 16, 2007 12:14:50 PM (GMT Daylight Time, UTC+01:00)
C# | Tips

Monday, October 01, 2007
Récupérer le nom de la méthode en cours d’exécution
On a toujours voulu récupérer le nom de la méthode en cours d’exécution, quelque soit le langage, afin de tracer les erreurs d’exécution. En VB4,5 et 6, chacun a développer sa propre technique car rien de bien sérieux n’existait.
En .NET, nous avons les NameSpace System.Diagnostics & System.Reflection pour résoudre ce problème :
StackFrame stackFrame1 = new StackFrame();
MethodBase methodBase1 = stackFrame1.GetMethod();
Permet de récupérer le nom de la méthode en cours d’exécution.
StackTrace stackTrace = new StackTrace();
StackFrame stackFrame = stackTrace.GetFrame(1);
MethodBase methodBase = stackFrame.GetMethod();
Permet de récupérer le nom de la méthode qui a appelé la méthode en cours d’exécution.
Très utile afin de tracer les exceptions…
Monday, October 01, 2007 11:28:56 AM (GMT Daylight Time, UTC+01:00)
C# | Log