Blog professionnel et technique de Adrien FROISSART

Développement C#

Fil des billets - Fil des commentaires

Jeudi, avril 15 2010

Telerik Reporting et problèmes associés

Un petit post de passage pour exprimer le désespoir rencontré dans l'utilisation d'un composant Telerik : Telerik Reporting en Winforms. 

Les versions concernées sont la Q1 2010 ainsi que la Q3 2009 (SP1) à savoir les deux dernières versions !

Mes griefs sont simples : Le système de sous-rapport n'est pas franchement ce que l'on peut appeler au point , il en va de même concernant les liaisons de données.

- Les sous-rapports :

Parfois il se révèle nécessaire d'utiliser ceux-ci comme dans mon cas pour faire intervenir des statistiques. Seul problème , j'ai deux champs (un id et un intitulé) ces deux champs ont besoin d'être répartis en colonnes puisque les résultats sont trop nombreux.

Après moultes tentatives, les colonnes s'affichent mais à chaque fois avec une colonne d'écart, entendez par là colonne 1 remplie, colonne 2 vide, colonne 3 remplie colonne 4 vide, etc. Sachant que du coté des données il s'agit d'un simple dataset lié avec un dataAdapter, qui gère lui même la répétition des champs dans les colonnes.

Non, ce n'est pas tout : lorsque les données sont (apparemment) réparties sur 3 colonnes (6 ou 12 dans la réalité en comptant les colonnes vides) la colonne centrale (la seconde remplie) décide tout à coup de ne mettre que 9 enregistrements et non pas 10 comme dans les autres. En tout et pour tout cette péripétie à pris une journée de travail soit une journée de perdue pour (excusez moi d'avance) une foutue connerie de sous rapport. Moralité Crystal Report © le fait tout aussi bien. (Je ne rentre pas dans le débat de Reporting Services © qui est une solution dépendant en partie de Crystal Report ©, enfin tout du moins de ce que j'en sais.)

On pourrait se dire, ce n'est qu'un problème mineur (ce qui est le cas à la base), le rapport fini enfin par être comme on le souhaite (enfin à peu près), mais non lors de l'intégration de ce sous rapport dans le rapport parent, on perd toute la mise en forme retour à l'affichage sur une unique colonne sans autre moyen de négocier. 

- L'accès au données :

Comme beaucoup de monde je suppose, j'utilise des procédures stockées pour toutes mes requêtes, cela permet de ne pas afficher la requête dans le code et surtout de gagner du temps dans le cas ou une procédure va en exécuter d'autres pour vérifier ceci ou cela...

Première constatation : Telerik Reporting ne gère pas les procédure stockées.

Ainsi soit-il je ne suis pas fan des assistants, j'essaye donc relier mes données à mon rapport via ma couche d'accès aux données. Seul petit problème : j'ai de multiples paramètres à transmettre à ma procédure stockée. Résultat :  isNull ! Les paramètres même bien configurés ne passent pas, enfin n'arrivent pas à destination. A partir de ce point j'arrête tout développement sur Telerik Reporting.

Bilan de cette (Mes)aventure : Énervé, Une journée de travail perdue voir même deux plus celles d'avant pour construire les différents rapports soit une bonne semaine, une mauvaise opinion sur Telerik Reporting. Le reste des composants Telerik reste cependant tout à fait satisfaisant.

Samedi, août 9 2008

C# (Sharp) la présentation

A la demande de Microsoft, "Anders Hejlsberg" a mis au point un système pour rendre le développement d'application Windows et Web beaucoup plus aisé. Une nouvelle architecture est née suivit d'un langage qui devient aussitôt la référence et le principal langage pour Microsoft: le C# prononcé C Sharp.
Le c# est dérivé du c++, on y retrouve aussi plusieurs caractéristiques des langages relativement récent à savoir par exemple le java.Il participe aussi pleinement à la création des pages Web dynamiques côté serveur et des services Web. Puisque le c# s'inscrit dans la lignée c c++, nous allons en premier présenter les caractéristiques de c# par rapport au c++ et en second étudier les instructions de base de C#.

Les Caractéristiques du C# par rapport au C++

  1. orientation objet prononcé tout doit être incorporé dans les classes.
  2. code unicode nouvelle solution pour faire face à la lourdeur de l'interfaçage avec la lourdeur des modules unicodes.
  3. libération automatique des objets
  4. disparition des pointeurs
  5. remplacement des pointeurs par des références.
  6. disparition du passage d'argument par adresse au profit du passage par référence.
  7. nouvelles manipulations des tableaux.
  8. passage de tableaux en arguments
  9. nouvelles manières d'écrire les boucles.
  10. disparition de l'héritage multiple mais possibilité d'implémenter plusieurs interfaces dans une classe.

Lire la suite »