2009-09-02 3 views
1

Je travaille sur un rapport Excel dans CrystalReports, dans VS2005. J'ai un champ dans la section Détails qui peut avoir jusqu'à 255 caractères de texte, et je veux que la hauteur de la ligne dans Excel se développe de sorte que le texte entier puisse être vu initialement quand le rapport est généré.Le champ excel de CrystalReports est coupé lors de l'utilisation de CanGrow = True

J'ai défini CanGrow = True dans les propriétés du champ et le champ semble croître; le champ n'est qu'une ligne (hauteur = 159), mais la plupart des lignes affichent plusieurs lignes de texte encapsulées. Certaines lignes ont par intermittence la moitié inférieure de la dernière ligne de texte coupée; l'utilisateur doit élargir la rangée un peu pour le voir. Il ne semble pas y avoir une longueur de champ particulière qui provoque cela - dans un cas, il a quatre lignes au total dans la sortie, et dans un autre cas, il n'en a que trois. Quelqu'un peut-il suggérer ce qui pourrait être la cause de cela ou comment je pourrais contourner ce problème?

Merci d'avance pour toute aide que vous pouvez offrir. [Edit: Je ne travaille plus sur ce projet, donc je n'ai jamais découvert ce qu'il est advenu de ce paramètre. Très probablement, il n'a pas été corrigé, car ce n'est pas un problème critique.]

+0

Mise à jour: J'ai remarqué un fil de discussion qui semble pertinente: http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/9592c64c-8345-44f3-964e-6f7892b21b54/ Il semble suggérer que la seule solution est de assurez-vous qu'il n'y a pas d'autres éléments dans le même espace vertical. Ce changement au format de rapport ne correspond probablement pas bien aux exigences, donc je cherche une alternative. – RMorrisey

+0

Un autre fil qui est pertinent; mais je ne vois aucun moyen d'éliminer les fusions de cellules avec ma conception de rapport actuelle ... à moins qu'il y ait un moyen de faire en sorte que tous les champs du détail s'étendent à la hauteur de la section développée? http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/1f15b52d-1070-4d90-b14f-e5ec80f97459/ – RMorrisey

Répondre

0

Une solution à ce problème que j'ai trouvé dans le passé est d'avoir deux rapports distincts. Un pour l'affichage et l'exportation vers pdfor rtf et un autre rapport pour l'exportation vers Excel.

Je sais en général que ce n'est pas une bonne approche car il est possible que les données soient différentes à l'export que dans le rapport d'affichage, mais si cela fonctionne, cela fonctionne bien.

Je suis dans une situation où un client a besoin de données imprimées dans un format spécifique sur un rapport, mais il y a beaucoup de données à intégrer physiquement sur une page. Nous avons élaboré une solution que je cours une "version d'affichage" du rapport qui correspond à la plupart des données, mais le reste des données nécessaires pour le client est ajouté seulement à la "version Excel" du rapport. Pour ce faire, je charge simplement le "rapport d'affichage" sur le visualiseur de rapports comme d'habitude, mais lorsque vous exportez le rapport, je charge le "rapport Excel" avec les mêmes paramètres que le "rapport d'affichage" et appelez le code pour exporter les données vers Excel. En utilisant cette méthode, le "rapport d'affichage" peut être formaté de toutes les manières nécessaires sans avoir à se soucier de déconnecter l'export vers Excel. Les champs du rapport Excel peuvent alors être plus petits que ce qui est requis par le rapport d'affichage car les données doivent être exportées même si la taille du champ est différente. Cela vous permet de placer plus de données dans le rapport d'exportation Excel. Comme les deux rapports utilisent la même source de données, vous aurez un problème si vous effectuez une modification dont vous devez vous souvenir pour vérifier la base de données de chaque rapport pour voir les modifications de la nouvelle base de données, mais cette méthode vous permet d'inclure plus de données et dans un format différent de la version d'affichage du rapport.

Espérons que cela aide.

+0

@Dusty: Merci pour la réponse! Nous utilisons des modèles de rapport distincts, un pour la sortie PDF/Word et un pour Excel. Ce problème se produit uniquement sur la version Excel du rapport. Ils veulent voir la hauteur de la rangée étendue dans l'Excel pour qu'ils puissent lire le tout. – RMorrisey

+0

Je m'excuse. J'ai mal lu la question. Je ne suis pas au courant d'un moyen d'avoir le rapport Excel exporter à la hauteur correcte sans redimensionnement. Je vais réfléchir un peu et je vais supprimer ce commentaire et modifier ma réponse si je viens avec quelque chose. – Dusty

+0

Pas de problème! Au moins, je sais que quelqu'un d'autre l'a lu et y réfléchit =) C'est une bonne suggestion mais nous l'avons déjà posée. J'ai demandé au responsable du projet de changer le format, afin que le problème puisse devenir théorique; mais gardant mes yeux ouverts pour une solution. – RMorrisey

0

Bien que ce ne soit pas une solution pour Crystal (je n'en connais pas), en tant que membre de l'équipe de reporting de GrapeCity-Data Dynamics, nous avons travaillé sur des problèmes similaires. . Dans notre produit Data Dynamics Reports, nous avons trouvé une toute nouvelle façon de résoudre le problème de l'exportation de rapports vers Excel.

Nous vous permettons de créer un modèle pour la sortie du rapport. Le modèle est un fichier Excel de base avec des espaces réservés pour les différentes zones de texte (ou autres contrôles) et les régions (tables, listes, etc.) du rapport.Vous pouvez ouvrir ce modèle dans Excel et modifier les propriétés des cellules et des lignes. Dans le scénario que vous décrivez, vous pouvez exporter un "modèle" à partir de Data Dynamics Reports, puis modifier la propriété autosize de la ligne dans le modèle contenant l'espace réservé pour la zone de texte avec laquelle vous rencontrez des difficultés. Lorsque vous exportez le rapport pour exceler la prochaine fois, spécifiez simplement le modèle dans Data Dynamics Reports (ce qui peut être fait par programme et de manière transparente pour l'utilisateur final) et Data Dynamics Reports respectera tous les paramètres spécifiés dans le modèle.

Il est difficile d'expliquer si il y a un ~ 2 minutes screencast qui montre cette fonctionnalité sur notre site Web à l'emplacement suivant: http://www.datadynamics.com/Products/DDRPT/ScreencastViewer.aspx?ID=XLS01

Pour plus d'informations sur le produit et pour une visite de téléchargement d'essai gratuit: http://www.datadynamics.com/DataDynamicsReports

Scott Willeke 
GrapeCity - Data Dynamics 
+0

Scott - merci pour vos commentaires, mais je ne cherchais pas à changer les outils de reporting. J'espère que ceux qui liront cela trouveront l'information utile. Voir ma modification ci-dessus. – RMorrisey

Questions connexes