serious business or what ?
Pierre Belin
Cette utilisateur n'a partagé aucune information biographique
Accueil: http://www.ree7.fr
Article par Pierre Belin
[SL/WP7] Snippet nprop
12/08/10
Avouez-le, vous en avez plein vos DataContext, des propriétés bêtes et méchantes qui font appel à une fonction NotifyPropertyChanged. [ Pour ceux du fond près du radiateur, dans une UI Silverlight, l'objet contexte de la page, s'il implémente INotifyPropertyChanged, possède un event PropertyChanged qui permet de signifier à Silverlight que de la valeur d'une propriété à changé et qu'il est temps de mettre à jour les éléments de l'UI attachés à cette propriété. ]
Nativement, dans Visual Studio nous avons à notre disposition prop et propdp, bien utiles dans la vie de tous les jours du développeur Silverlight pour créer propriétés et DependencyProperties sans trop avoir à taper du code purement répétitif. Par contre rien pour les propriétés déclenchant l’évènement PropertyChanged - sans doute car l’implémentation concrète d’INotifyPropertyChanged est laissée au développeur… bien que l’on fasse quasiement tous pareil.
Pour palier à ce manque je vous propose nprop, un snippet venant s’ajouter à votre IDE et qui vous permettra du temps dans vos développements 
Elle s’utilise comme n’importe quel autre snippet, tapez juste nprop puis TAB et le code apparaitra en vous invitant à remplir les trous.
- Fichier d’installation automatique .vsi
- Fichier snippet nu à placer dans votre dossier %Documents%\Visual Studio 20xx\Code Snippets\Visual C#\My Code Snippets au cas où le fichier précédent poserait problème
Popularity: 4% [?]
[WP7] Missing CheckAccess()
10/05/10
Une petite note technique pour ceux qui se demandaient où était passée Dispatcher.CheckAccess() dans les CTP de Windows Phone 7.
Cette primitive permet de savoir si le code courant tourne dans le thread d’UI ou pas, et donc si un BeginInvoke() est nécessaire ou pas.
Exemple, pour récupérer un setting de l’IsolatedStorage depuis n’importe quel thread :
public void GetSetting(string key, out object value)
{
if (Deployment.Current.Dispatcher.CheckAccess())
{
value = IsolatedStorageSettings.ApplicationSettings[key];
}
else
{
using (ManualResetEvent sync = new ManualResetEvent(false))
{
object _value = null;
Deployment.Current.Dispatcher.BeginInvoke(() =>
{
_value = IsolatedStorageSettings.ApplicationSettings[key];
sync.Set();
});
sync.WaitOne();
value = _value;
}
}
}
Et bien CheckAccess() est toujours bien là dans la classe Dispatcher, même si l’Intellisense de Visual Studio ne vous la propose pas.
Rappel : Pour les débutants en multi-threading sous Silverlight, le seul Dispatcher auquel vous avez accès depuis un autre thread que l’UI est Deployment.Current.Dispatcher. Si vous essayez de taper directement dans le Dispatcher d’un FrameworkElement vous irez tout droit à la CrossThreadException 
.
Source : Forums MSDN
Popularity: 12% [?]
Ready-made usual flavour HttpWebRequest for Windows Phone 7
19/04/10
Si vous effectuez des portages d’applications .NET vers Silverlight ou Windows Phone 7, cette classe pourrait bien vous être utile.
En effet, dans Silverlight, les WebRequests sont asynchrones (c’est très bien !), seulement ce changement d’API peut causer de nombreuses modifications de code. C’est dans cette optique que j’ai crée cette classe C# : HttpWebRequestSync qui propose une interface au plus proche de ce qui existait avant.
Attention, pour le coup vous perdrez l’avantage des requêtes asynchrones et votre thread appelant sera bloqué pendant le déroulement de la requête, comme au bon vieux temps !
Tout retour de bug ou message de remerciement est le bienvenu, ce code est disponible sous licence LGPL.
If you’re looking forward to port .NET applications to Silverlight/Windows Phone 7, the following might interest you.
In Silverlight, the WebRequests are asynchronous (and that’s a good thing), but this change in the API can cause numerous changes in your code. That’s what lead me to write this C# class : HttpWebRequestSync featuring an interface as close as possible as what was there before.
Note that you’ll lose the advantage of asynchronous requests and that you’re thread will be locked waiting for the request to complete, ol’school style.
If you find any bug or just want to leave a ‘thank you’ not you’re welcome. This code is available under the LGPL license.
Popularity: 100% [?]
Faire discuter C# et C/C++ (et d’autres)
10/04/09
Cette exception m’a donné un peu de fil à retordre, je vais donc partager ma solution avec vous.
Dans le cadre d’un projet C#, il arrive qu’on ait besoin d’utiliser des libraires (.DLL) non managées. Pour l’impétrant ce n’est pas forcément une balade de santé… même en demandant à Google.
La documentation MSDN est un peu fouillis et on clique de lien en lien sans vraiment trouver de quoi se dépêtrer.
Je ne prétends pas que la solution que je vais vous proposer est la meilleure (si des experts veulent réagir, vous êtes les bienvenus), mais elle à le mérite de fonctionner.
Ma problématique était la suivante : « J’ai trouvé un source C++ génial sur le net qui fait exactement ce que je veux, et j’aimerais l’utiliser dans mon application C#. »
Ceci dit cet article peut vous aider si vous cherchez simplement à utiliser une DLL quelconque en C# (sautez à l’étape deux).
Popularity: 66% [?]
Attention au compilateur C-+ de Visual Studio 2008
5/02/09
Je ne suis pas un grand expert C/C++ mais j’ai eu affaire à une chose étrange aujourd’hui, qui m’aura couté (et à d’autres) de longues heures.
Erreur de l’éditeur de lien : error LNK2019: unresolved external symbol « short __cdecl ga_population_seed(struct population_t *) »
Le contexte, une solution C/C++ principalement écrite en C, dont deux des projets sont une librairies (sortie en .lib) C (GAUL : Genetic Algorithm Utility Library pour ne pas la citer).
La compilation se passe sans heurts (ceci dit, nous avons du modifier un petit peu la version soit disant Windows de GAUL pour qu’elle fonctionne sous VS2008 – soucis de #define, etc… assez triviaux dans l’ensemble). Mais le linking est une catastrophe, impossible pour VS de trouver les fonctions définies dans le header de notre librairie. Diantre !
Et bien le souci vient de la configuration du projet par défaut sous Visual Studio. En effet celui ci nous propose de choisir entre un compilateur C, et un compilateur C++, mais son choix par défaut semble être un étrange et indigeste mix des deux !
Tentative d’explication :
- Le compilateur par défaut (qui accepte de compiler sans broncher) doit déclarer nos fonctions (dans les .obj) d’une maniere differente de celle attendue par le linker ( __cdecl blah-blah-blah)
La solution :
- Forcer le compilateur a utiliser le compilateur C++ (ou C suivant votre convenance)
- Corriger les erreurs levées par le compilateur (et ca peut etre long, dans notre cas GAUL utilise moult attributions de pointeurs sans cast, déclare des fonctions s’appelant new ou delete, … – environ 300 erreurs au total chez nous).
Et voila, ça devrait linker correctement maintenant !
On remercie Ben pour avoir trouvé la solution !
Popularity: 37% [?]