إنشاء مكون HotPDF وتحريره ديناميكيا في C++Builder

تضع معظم أمثلة HotPDF مكونا على النموذج وقت التصميم. هذا مناسب للعروض التوضيحية، لكن كود الإنتاج قد يحتاج أحيانا إلى إنشاء مكون PDF لعملية تصدير محددة فقط. الإنشاء الديناميكي مفيد في وحدات الخدمة، ومساعدات التقارير، والمهام الدفعية، والنماذج التي لا ينبغي أن يبقى فيها المكون طوال عمر النموذج.

نمط C++Builder الأساسي هو تخصيص مثيل THotPDF وتهيئة ملف الإخراج وخيارات المستند، ثم إنشاء PDF وتحرير المكون عند اكتمال العملية. يوضح المثال أدناه أقل سير عمل داخل معالج زر.

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

}

الملكية والتنظيف

يتلقى المنشئ this كمالك، لذلك يستطيع النموذج تنظيف المكون إذا بقي حيا. في هذا المثال القصير يتم أيضا تحرير الكائن صراحة بعد EndDoc. في الكود الحقيقي، اجعل مسار التنظيف آمنا مع الاستثناءات: إذا كان إنشاء PDF قد يفشل، فلف العمل في كتلة try/__finally أو استخدم مساعد RAII صغيرا حتى يبقى Free() قيد التنفيذ.

لا تستدع طرائق المكون بعد Free()وتجنب تخزين المؤشر في نطاق أوسع إلا إذا كان جزء آخر من النموذج يملك فعلا دورة حياة المكون. غالبا ما يكون المتغير المحلي أبسط خيار لتصدير PDF مرة واحدة.

ملاحظات إعداد المشروع

يجب أن يستطيع المشروع العثور على رؤوس HotPDF ومكتباته وحزم التصميم/التشغيل. أضف مجلد include الخاص بـ HotPDF إلى مسار include في C++، وأضف مجلد المكتبة إلى مسار بحث الرابط. إذا كان المشروع يربط HPDFDocفأبق أسماء الحزمة والوحدات كما هي حتى يستطيع C++Builder حل الرؤوس المولدة.

قبل التسليم

استخدم مسار إخراج مطلقا أو متحققا منه عند إنشاء ملفات خارج مجلد تجريبي.
استدع BeginDoc و EndDoc في أزواج متوازنة.
افتح ملف PDF الناتج في عارض خارجي واحد على الأقل، وليس فقط باستخدام AutoLaunch.
سجل أخطاء الإنشاء حتى يستطيع الدعم تمييز مشكلات المسار، والصلاحيات، والخطوط، ورسم PDF.

بنية آمنة مع الاستثناءات

يبقي المثال الكود مختصرا، لكن روتين التصدير الحقيقي يجب أن يتعامل مع الاستثناءات بين التخصيص والتنظيف. قد يفشل إنشاء PDF لأن مجلد الإخراج للقراءة فقط، أو لأن خطا لا يمكن حله، أو لأن stream أغلق مبكرا جدا، أو لأن بيانات المستخدم تحتوي قيمة غير متوقعة. يجب ألا يعتمد مسار التنظيف على نجاح كل استدعاء رسم.

إحدى الطرق العملية هي إنشاء المكون مباشرة قبل التصدير، ثم تحريره في كتلة تنظيف مضمونة. هذا يربط عمر المكون بمهمة PDF واحدة. وإذا كان التطبيق ينشئ مستندات كثيرة بالتتابع، فإن هذا النمط يقلل أيضا احتمال تسرب حالة مستند إلى المستند التالي.

مكونات وقت التصميم مقابل مكونات وقت التشغيل

يكون مكون وقت التصميم أسهل عندما يملك نموذج واحد سير تصدير واحدا متوقعا. ويكون مكون وقت التشغيل أفضل عندما يحتاج التطبيق إلى عدة مصدرين مؤقتين، أو يختار الإعدادات ديناميكيا، أو يشغل كود التصدير من فئة مساعدة بدلا من نموذج. استدعاءات API هي نفسها؛ الفرق فقط في من يملك الكائن ومدة حياته.

في كود الخادم أو الدفعات، تجنب الاعتماد على AutoLaunch. أنشئ الملف، وتحقق من وجوده، وسجل مسار الإخراج، ودع سير العمل المستدعي يقرر هل يجب فتح عارض أم لا.