C++Builder içinde HotPDF bileşenini dinamik oluşturma ve serbest bırakma

Çoğu HotPDF örneği, bir bileşeni design time sırasında forma yerleştirir. Bu demolar için kullanışlıdır, ancak üretim kodu bazen PDF bileşenini yalnızca belirli bir export işlemi için oluşturmak ister. Dinamik oluşturma; servis modülleri, rapor yardımcıları, batch işler ve bileşenin formun tüm ömrü boyunca yaşamasının gerekmediği formlar için yararlıdır.

Temel C++Builder deseni, bir THotPDF örneği ayırmak, çıktı dosyasını ve belge seçeneklerini yapılandırmak, PDF'yi üretmek ve işlem tamamlandığında bileşeni serbest bırakmaktır. Aşağıdaki örnek, bir button handler içinde en küçük workflow'u gösterir.

#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();

}

Sahiplik ve cleanup

Constructor this değerini owner olarak alır; böylece bileşen canlı kalırsa form onu temizleyebilir. Bu kısa örnekte nesne EndDoc sonrasında açıkça serbest bırakılır. Gerçek kodda cleanup yolunu exception-safe tutun: PDF üretimi başarısız olabiliyorsa, işi bir try/__finally bloğuna alın veya Free() yine çalışsın diye küçük bir RAII yardımcısı kullanın.

Free() sonrasında bileşen üzerinde metot çağırmayın ve formun başka bir bölümü bileşen yaşam döngüsüne gerçekten sahip değilse pointer'ı daha geniş bir scope içinde saklamaktan kaçının. Tek seferlik PDF export işlemleri için yerel değişken genellikle en basit seçimdir.

Proje kurulum notları

Proje HotPDF header'larını, kütüphanelerini ve design/runtime package'larını bulabilmelidir. HotPDF include dizinini C++ include yoluna, library dizinini de linker arama yoluna ekleyin. Proje HPDFDoc bağlıyorsa, package ve unit adlarını değiştirmeyin ki C++Builder üretilen header'ları çözebilsin.

Yayınlamadan önce

Demo klasörü dışında dosya üretirken mutlak veya doğrulanmış bir çıktı yolu kullanın.
BeginDoc ve EndDoc çağrılarını dengeli çiftler halinde yapın.
Oluşturulan PDF'yi yalnızca AutoLaunch ile değil, en az bir harici viewer içinde açın.
Support ekibinin yol, izin, font ve PDF rendering sorunlarını ayırt edebilmesi için üretim hatalarını loglayın.

Exception-safe yapı

Örnek kodu kompakt tutar, ancak gerçek bir export rutini allocation ile cleanup arasındaki exception'ları ele almalıdır. PDF üretimi; çıktı klasörü salt okunur olduğu, bir font çözülemediği, bir stream çok erken kapandığı veya kullanıcı verisi beklenmeyen bir değer içerdiği için başarısız olabilir. Cleanup yolu her çizim çağrısının başarılı olmasına bağlı olmamalıdır.

Pratik bir yaklaşım, bileşeni export işleminden hemen önce oluşturmak ve ardından garantili bir cleanup bloğunda serbest bırakmaktır. Bu, bileşenin yaşam süresini tek bir PDF işiyle sınırlar. Uygulama art arda çok sayıda belge üretiyorsa, bu desen bir belgedeki durumun sonrakine sızma olasılığını da azaltır.

Design-time ve runtime bileşenler

Bir form tek ve öngörülebilir bir export workflow'una sahipse design-time bileşen daha kolaydır. Uygulama birden çok geçici exporter'a ihtiyaç duyuyorsa, ayarları dinamik seçiyorsa veya export kodunu form yerine bir yardımcı sınıftan çalıştırıyorsa runtime bileşen daha iyidir. API çağrıları aynıdır; fark yalnızca nesneye kimin sahip olduğu ve ne kadar yaşadığıdır.

Sunucu tarzı veya batch kodda AutoLaunch kullanımına bel bağlamayın. Dosyayı üretin, var olduğunu kontrol edin, çıktı yolunu kaydedin ve viewer açılıp açılmayacağına çağıran workflow karar versin.