L’exemple présenté dans cet article utilise une application Windows Form afin d’héberger le contrôle ReportViewer. Sur le formulaire, vous avez besoin d’ajouter un contrôle ReportViewer pour afficher le rapport. Il faut aussi un intitulé (Label) et une zone de liste à cocher (Checked ListBox) (pour inviter l’utilisateur à spécifier un
Procédé de rendu d’un rapport local
![Procédé de rendu d’un rapport local Procédé de rendu d’un rapport local](https://www.itpro.fr/wp-content/uploads/2015/04/0ee2db6e4ce658301e3a6c3f1a987f1f.jpg)
ou plusieurs types de tâches) et un bouton (utilisable par l’utilisateur en vue du rendu du rapport après la sélection des types de tâches). Pour activer ces éléments, il faut ajouter le code nécessaire.
Ajout du code servant à charger l’intitulé et la zone de liste à cocher. Pour que ces deux éléments fonctionnent, vous devez ajouter le code du listing 1 à l’événement load du formulaire. Ce code extrait des informations sur les paramètres du rapport à partir de la définition de rapport, et les utilise pour charger l’intitulé et la zone de liste à cocher. Comme ces informations sont déjà présentes dans la définition du rapport, il est judicieux d’employer ces métadonnées au lieu de les coder une nouvelle fois en dur dans l’application.
Comme le montre le bloc A du listing 1, le code définit le traitement local pour la propriété ProcessingMode du contrôle ReportViewer et spécifie le fichier EmployeeTime. rdl pour la propriété ReportPath du rapport local. Ce code part du principe que le fichier .rdl réside dans le même dossier que l’exécutable, de telle sorte qu’aucun chemin de dossier n’est nécessaire. (Vous pouvez tout aussi bien charger le contenu du fichier .rdl du rapport dans un flux ou un lecteur de texte et employer la méthode LoadReportDefinition du rapport local pour charger le flux ou la chaîne de texte en question.) Après avoir spécifié la définition du rapport dans la propriété ReportPath du rapport local, vous pouvez récupérer les informations de cette définition.
Dans ce cas, vous devez extraire les informations sur l’invite et la liste de types de tâches des paramètres du rapport. Pour cela, vous devez examiner la collection d’informations de paramètres incorporée dans la définition du rapport. Le contrôle ReportViewer n’accède à aucune base de données. La collection ValidValues des paramètres contient les données car celles-ci sont codées en dur dans la définition du rapport. Si celle-ci avait employé un dataset pour remplir la liste de types de tâches, ces valeurs ne seraient pas visibles dans le contrôle ReportViewer.
Au lieu de cela, la collection Valid- Values aurait pris la valeur Nothing et vous auriez dû dupliquer le dataset dans l’application. Comme noté précédemment, le code du listing 1 applique un certain nombre de postulats sur le rapport faisant l’objet du rendu et les paramètres dont il a besoin. Néanmoins, avec un peu de créativité et du code supplémentaire, il est possible de créer une application plus générique. Par exemple, vous pouvez écrire du code qui pointe vers n’importe quel fichier RDL, puis déterminer le nombre de paramètres requis et leurs types de données.
Avec ces informations, votre application peut créer le type approprié de contrôle de saisie de données pour chaque paramètre de rapport. Ajout de l’événement click pour le bouton. Le listing 2 affiche le code d’événement click du bouton Render Report à charger sur le formulaire. Comme le montre le bloc A du listing 2, le code commence par réinitialiser le contrôle ReportViewer. Cela permet aux utilisateurs de modifier les types de tâches et de cliquer à plusieurs reprises sur le bouton Render Report afin d’obtenir différents rapports sans avoir à quitter l’application. Néanmoins, comme vous réinitialisez le contrôle ReportViewer, vous devez définir de nouveau le mode de traitement et la propriété ReportPath du rapport local, comme l’illustre le bloc B du listing 2. Ensuite, le code adopte les valeurs sélectionnées dans la zone de liste à cocher et les passe au rapport local. Cela peut sembler quelque peu étrange si l’on considère que le contrôle ReportViewer ne crée pas le dataset et que la majorité des paramètres du rapport servent exclusivement dans la clause WHERE de la requête de dataset. Toutefois, certains paramètres sont employés dans la définition du rapport proprement dite, et ils sont donc nécessaires au contrôle Report- Viewer pour le rendu. Le contrôle ReportViewer n’essaie pas de déterminer les paramètres de rapport employés dans la requête de dataset et ceux utilisés dans la définition du rapport.
Au lieu de cela, il a besoin qu’une valeur soit fournie pour chaque paramètre défini dans le rapport. Comme l’illustre le bloc C du listing 2, le code fournit les valeurs de paramètres du rapport en créant un tableau d’objets ReportParameter. Chaque objet a des propriétés pour le nom de paramètre et une collection de valeurs. Le nom de paramètre de rapport est fourni dans l’instruction New pour l’objet ReportParameter. Le code boucle sur les valeurs sélectionnées dans la zone de liste à cocher et les ajoute à la collection de valeurs de l’objet ReportParameter. Dans le même temps, le code crée aussi une liste des valeurs sélectionnées en utilisant la virgule comme séparateur.
Le code du bloc D utilise les objets SqlConnection et SqlCommand afin de créer un ensemble de résultats pour le rapport. La liste séparée par des virgules nouvellement créée est passée en tant que paramètre à la procédure stockée SQL, laquelle interroge au final les tables de la base de données. L’ensemble de résultats renvoyé par la procédure stockée est assigné à la collection de sources de données utilisée par le rapport local. Pour que le rapport utilise correctement le dataset, le nom de ce dernier doit correspondre au nom figurant dans la définition du rapport.
Dans ce cas, le nom est EmployeeTimeDS. Enfin, le code utilise la méthode RefreshReport afin de provoquer le rendu du rapport par le contrôle ReportViewer. Bien que le rapport soit prêt pour le rendu, ce n’est pas le cas du sousrapport. Pour que ce dernier fonctionne correctement, il vous faut encore un peu de code.
Téléchargez cette ressource
![Guide inmac wstore pour l’équipement IT de l’entreprise](https://www.itpro.fr/wp-content/uploads/2024/04/Guide-inmac-wstore-Juillet-2024.jpg)
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez les dernières tendances et solutions IT autour des univers de Poste de travail, Affichage et Collaboration, Impression et Infrastructure, et notre nouveau dossier thématique sur l’éco-conception et les bonnes pratiques à adopter pour réduire votre impact environnemental.