Créer et libérer dynamiquement un composant HotPDF dans C++Builder

La plupart des exemples HotPDF placent un composant sur un formulaire au moment de la conception. C’est pratique pour les démonstrations, mais le code de production doit parfois créer le composant PDF seulement pour une opération d’export précise. La création dynamique est utile dans les modules de service, assistants de rapports, traitements par lots et formulaires où le composant ne doit pas vivre pendant toute la durée de vie du formulaire.

Le modèle C++Builder de base consiste à allouer une instance THotPDF, configurer le fichier de sortie et les options du document, générer le PDF puis libérer le composant lorsque l’opération est terminée. L’exemple ci-dessous montre le flux minimal dans un gestionnaire de bouton.

#include

#pragma hdrstop

#include "Unit1.h"

#pragma package(smart_init)

#pragma link "HPDFDoc"

#pragma resource "*.dfm"

TForm1 *Form1;

__fastcall TForm1::TForm1(TComponent* Owner)

: TForm(Owner)

{

}

void __fastcall TForm1::Button1Click(TObject *Sender)

{

THotPDF* HotPDF1 = new THotPDF(this);

HotPDF1->FileName = "HelloWorld.pdf";

HotPDF1->AutoLaunch = true;

HotPDF1->BeginDoc(false);

HotPDF1->CurrentPage->PrintText( 10, 10, 0, "Hello World!" );

HotPDF1->EndDoc();

HotPDF1->Free();

}

Propriété et nettoyage

Le constructeur reçoit this comme propriétaire, le formulaire peut donc nettoyer le composant s’il reste en vie. Dans ce court exemple, l’objet est aussi libéré explicitement après EndDoc. En code réel, gardez le chemin de nettoyage sûr face aux exceptions: si la génération PDF peut échouer, encadrez le travail dans un bloc try/__finally ou utilisez un petit helper RAII pour que Free() s’exécute tout de même.

N’appelez pas de méthodes sur le composant après Free() et évitez de stocker le pointeur dans une portée plus large sauf si une autre partie du formulaire possède réellement son cycle de vie. Une variable locale est généralement le choix le plus simple pour les exports PDF ponctuels.

Notes de configuration du projet

Le projet doit pouvoir trouver les en-têtes, bibliothèques et packages design/runtime de HotPDF. Ajoutez le répertoire include de HotPDF au chemin include C++ et le répertoire des bibliothèques au chemin de recherche de l’éditeur de liens. Si le projet lie HPDFDoc, gardez les noms de package et d’unité inchangés afin que C++Builder résolve les en-têtes générés.

Avant la livraison

Utilisez un chemin de sortie absolu ou validé lors de la génération de fichiers hors d’un dossier de démonstration.
Appelez BeginDoc et EndDoc par paires équilibrées.
Ouvrez le PDF généré dans au moins un lecteur externe, pas seulement avec AutoLaunch.
Journalisez les erreurs de génération afin que le support distingue les problèmes de chemin, permission, police et rendu PDF.

Structure sûre face aux exceptions

L’exemple garde le code compact, mais une vraie routine d’export doit gérer les exceptions entre l’allocation et le nettoyage. La génération PDF peut échouer parce que le dossier de sortie est en lecture seule, qu’une police est introuvable, qu’un stream est fermé trop tôt ou que des données utilisateur contiennent une valeur inattendue. Le chemin de nettoyage ne doit pas dépendre de la réussite de chaque appel de dessin.

Une approche pratique consiste à créer le composant juste avant l’export, puis à le libérer dans un bloc de nettoyage garanti. La durée de vie du composant reste ainsi liée à un seul travail PDF. Si l’application génère beaucoup de documents à la suite, ce modèle réduit aussi le risque qu’un état d’un document se propage au suivant.

Composants de conception et composants d’exécution

Un composant de conception est plus simple lorsqu’un formulaire possède un flux d’export prévisible. Un composant d’exécution est préférable lorsque l’application a besoin de plusieurs exporteurs temporaires, choisit les réglages dynamiquement ou exécute le code d’export depuis une classe d’aide plutôt que depuis un formulaire. Les appels d’API sont les mêmes; seule la propriété de l’objet et sa durée de vie changent.

Pour du code serveur ou par lots, évitez de dépendre de AutoLaunch. Générez le fichier, vérifiez son existence, consignez le chemin de sortie et laissez le flux appelant décider si un lecteur doit être ouvert.