Delphi وFireMonkey وAll-Access وغيرها من المفاجآت السارة. قرد النار

تأثير ثلاثيفئة لإنشاء تأثير يطبق تموجات موجية على نسيج الكائنات المرئية.

يتم تحديد مركز التموج في الخاصية مركز. يمكن تخصيص جوانب أخرى من التموج باستخدام الخصائص السعة(السعة)، ابعاد متزنة، و مرحلة(مرحلة). يتم تحديد عدد الموجات المموجة بواسطة الخاصية تكرار(تكرار).

ويبين الجدول التالي نتائج التأثير تأثير ثلاثيإلى صورة PNG موضوعة في النموذج (باستخدام ملف ). يقع مركز التموج في منتصف الصورة. خصائص أخرى تأثير ثلاثيتستخدم مع قيمها الافتراضية ( السعة = 0,1, ابعاد متزنة = 1,5, تكرار = 70, مرحلة = 0).

ستستخدم في هذا البرنامج التعليمي بعض تأثيرات الصور الأساسية في تطبيق FireMonkey.

الخطوة 1: تطبيق التأثير على الصورة.

في FireMonkey، يعد تطبيق تأثير الصورة على الصورة عملية بسيطة. ما عليك سوى إنشاء مكون يمكن أن يحتوي على صورة ثم تطبيق أحد تأثيرات الصورة.

إنشاء تطبيق FireMonkey جديد ( ملف > جديد > تطبيق FireMonkey لسطح المكتب > تطبيق HD FireMonkey).

ضع المكون في النموذج.

حدد المكون في شريط الأدوات.

ضع TImage على النموذج في المصمم.

يمكنك أن ترى أن المكون لم يتم وضعه في وسط مصمم النموذج. كما هو موضح في الشكل، تريد أن يكون حجم مساحة الصورة كبيرًا قدر الإمكان. للقيام بذلك، حدد المكون في نموذج التصميم، ثم قم بتغيير الخصائص محاذاةالخامس alClientفي Object Inspector بحيث يصبح حجم المكون هو نفس حجم العميل في منطقة النموذج.

حدد الصورة التي تريد تطبيق التأثير عليها. يقوم المكون بتخزين الصورة في الخاصية الصورة النقطية. اختر خاصية الصورة النقطيةفي مفتش الكائن، واستخدام يحرر...لتحديد صورة.

1. الآن يمكنك اختيار تأثير للصورة. من لوحة الأدوات، حدد تأثير ثلاثي.

الآن أثرمضاعفالمعروضة في النافذة بناء.

لتطبيق تأثير، يجب تعريفه على أنه تابع لمكون آخر. في هذه الحالة، تأثير تموج1يجب تعريفه كطفل الصورة1. للقيام بذلك، اسحب تأثير تموج1ووضعه على الصورة1في لوحة الهيكل.

1. الآن يمكنك أن ترى ذلك أثرمضاعفيعمل بالفعل على مصمم النماذج.

1. تغيير الخاصية تكرارعلى 20 .

الخطوة 2: تطبيق تأثير الرسوم المتحركة على RippleEffect.

تسليط الضوء أثرمضاعفعلى اللوحة بناء.

اختر خاصية مرحلةفي Object Inspector وقم بتشغيل الأمر إنشاء TFloatAnimation جديدمن القائمة المنسدلة.

تأكد من أن تعويم الرسوم المتحركة1تم تعريفه كعنصر فرعي تأثير تموج1.

تغيير الخصائص تعويم الرسوم المتحركة1على النحو التالي:

وأخيرًا، دعونا نضيف إجراء حدث OnMouseMoveل .

FireMonkey هي التقنية الأساسية لـ "New Delphi". من فضلك أخبرنا عن أهدافك وفرصك و الجوانب الفنيةأجهزة هذه المكتبة الجديدة بشكل أساسي. بعد فترة من الوقت، بالنظر إلى الوراء، ما مدى صعوبة ومبرر رفضك مواصلة تطوير VCL ذو الشعبية الكبيرة؟

تم اختياره باعتباره الاتجاه الرئيسي لتطوير تقنية دلفي لتحقيق هدف محدد - تطوير متعدد المنصات من بيئة واحدة، بناءً على قاعدة كود مصدر واحدة، دون الحاجة إلى إعادة تدريب جذرية للمطورين. في إطار VCL الكلاسيكي الذي يحظى الآن بشعبية كبيرة، كان هذا مستحيلًا؛ كان ارتباطه بـ WinAPI وثيقًا جدًا، "على المستوى الجيني".

لم تحتوي مكونات VCL على طبقة "مجردة" بين المستوى الوظيفي من حيث الواجهة وآليات عرضها. المستوى الوظيفي- كيف يتصرف كعنصر تحكم، وما هي الأحداث التي يتفاعل معها، ونوع تفاعل المستخدم الذي يوفره. عرض- استدعاء أساليب التصور الموجهة نحو النظام الأساسي كصورة معينة مكونة من كائنات نقطية وأوليات متجهة. نفذ FireMonkey في البداية مبدأ التقسيم الصارم للتحكم إلى عنصرين: "السلوكية" و"المرئية".

فسيفولود ليونوف، إمباركاديرو تكنولوجيز

الأول لن يكرر عمومًا حتى أساسيات VCL، بل جوهر البرمجة الموجهة للكائنات. المكون عبارة عن فئة؛ وتشكل فئات المكونات تسلسلًا هرميًا حيث يمكن التمييز بين العائلات والوحدات النمطية. ترتبط فئة المكون بشكل فضفاض بكيفية تقديمه.

يتم تشكيل "الصورة" المرئية بشكل ديناميكي، ولا تتم كتابتها بشكل صارم في فئة المكونات. يتم تحميل الصورة أو "النمط" في FireMonkey إلى المكون عند بدء تشغيل التطبيق. لدينا نوع من الإطار الوظيفي للمكون، ويمكن تغيير "الجلد" أو "الكسوة"، ولكن لماذا؟ وذلك بحيث تبدو تطبيقات FireMonkey أصلية على أي نظام أساسي - Windows 7 وWindows 8 وMac OS وiOS وفي المستقبل القريب Android. وهذا شيء لا يمكن للبنية الطبقية التقليدية المتجانسة لـ VCL توفيره.

هنا دور خاصتلعب تكنولوجيا النهج دورًا. من حيث المبدأ، يمكنك أخذ مكتبة VCL و"ملؤها" بـ WinAPI وجميع استدعاءات النظام الأساسي الممكنة الأخرى. لا يزال من الممكن القيام بذلك على مجموعة فرعية محدودة جدًا من المكونات، لكن VCL يحتوي على عدة مئات من المكونات، لذلك يمكن لهذا الأسلوب ببساطة "قتل" VCL. تقرر عدم لمس VCL، ولكن تطوير إمكانيات جديدة على منصة جديدة - FireMonkey. هذه التكنولوجياحتى أنها تتمتع بأناقة فنية معينة - في وقت تجميع المشروع لمنصة معينة بيئة دلفييقوم IDE بتوصيل المترجم المطلوب، وتتلقى مكونات الواجهة نمط النظام الأساسي.

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

عندما أصبح من الواضح أنه سيتم تقديم FireMonkey كمنصة جديدة منفصلة، ​​كان لا بد من اختيار استراتيجية التعايش الصحيحة: لم ترغب Embarcadero في التأثير سلبًا على مستخدمي VCL بأي شكل من الأشكال. لذلك، اخترنا الخطة التالية: يظل VCL مستقرًا فكريًا ومعماريًا لضمان أعلى توافق ممكن، مما يسهل ترحيل المشاريع إلى الإصدارات الحديثة. سوف يتبع تطوير FireMonkey مسارًا طبيعيًا ومتوازيًا، بغض النظر عن VCL.

نقطة الضعف في هذا الحل هي الترحيل الإشكالي من VCL إلى FireMonkey داخل نفس المشروع. ولكن بالنسبة لمشروع جديد، يمكن للمطور اختيار FireMonkey لضمان طبيعة النظام الأساسي المتعدد للتطبيق الناتج. بعد إصدار XE4 مع دعم iOS، يمكننا بالفعل التحدث عن المزايا التنافسية المشرقة لدلفي كبداية تطوير المحمولفي بيئة الشركة، والتي سيتم زيادتها بعد تنفيذ دعم Android المخطط له.

لذلك، لا يوجد "رفض" واضح لتطوير VCL على هذا النحو. في الإصدارات الجديدة، تم تطوير جزء VCL من دلفي أيضًا. يتضمن ذلك دعم 64 بت، وإدخال التصميم للمكونات المرئية، وتنفيذ آلية للاتصالات الديناميكية المرنة أو "الربط"، وإدراج مكتبة FireDAC للعمل مع قواعد البيانات في مشاريع VCL. إنه فقط أنه بالمقارنة مع القفزة النوعية العملاقة التي حققتها FireMonkey، فإن التقدم في VCL يبدو باهتًا إلى حد ما. ولكن مهما كان الأمر، فإن VCL جزء لا يتجزأ من دلفي وسيظل كذلك لسنوات عديدة قادمة. على الرغم من تطور المنصات والوضع الحالي في مجال أنظمة التشغيل لأنظمة سطح المكتب و أجهزة محمولةبحيث يكون المستقبل بالتأكيد لـ FireMonkey.

لقد ناقشنا في المقابلة دعم نظام التشغيل iOS، فلنخبر قرائنا عن دعم الآخرين أحدث التقنياتمن أحدث RAD Studio XE4، على سبيل المثال، مثل Windows 8 وWinRT وأنظمة 64 بت وMacOS وما إلى ذلك. هل يمكنك سرد ما يمكنك تقديمه للمبرمج الحديث الذي أفسدته الابتكارات؟

على الأرجح، لا "يفسد" المبرمج الحديث الابتكارات. ل المشاريع الكبرىغالبًا ما يؤدي أي "ابتكار" إلى قدر هائل من العمل.

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

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

أحد هذه الإنجازات "الإشكالية" كان إصدار Windows 8. شخصيًا، كمستخدم للكمبيوتر الشخصي ومجرد متخصص حديث في تكنولوجيا المعلومات، أنا سعيد بنظام Windows 8. لكن بالنسبة للمطورين الذين تم إرسال مجموعة من أجهزة الكمبيوتر التي تعمل بنظام التشغيل Windows 8 مع مواصفات التطوير لنظام التشغيل الجديد كحمل، فهذا يعني بعض الصعوبات.

لقد حاولنا تقديم الدعم التطويري بأكثر الطرق الممكنة راحةً وأقل ألمًا. واجهة جديدةنظام التشغيل هذا. لذلك، تم تقديم أنماط خاصة لكل من VCL وFireMonkey، ويمكن للمبرمج إما إعادة بناء واجهة التطبيق أو إنشاء تطبيق جديد لا يمكن تمييزه عن التطبيق "الأصلي" لنظام التشغيل Windows 8 في المظهر. وبطبيعة الحال، هناك حاجة إلى "وطني" دعم ويندوز 8 بسبب WinRT. ولكن هنا يأتي دور تحديد أولويات الأهداف في الظروف الحديثة. Mac OS و iOS و Android في المستقبل القريب لا يسمح لنا بالحديث عنه دعم كامل WinRT في المستقبل القريب.

الهدف الاستراتيجي لـ Embarcadero، بالطبع، هو تعدد المنصات. كان إصدار RAD Studio XE4 أمرًا أساسيًا، ويرجع ذلك أساسًا إلى دعمه لنظام التشغيل iOS. يمكن للمبرمج الحالي الذي يستخدم VCL البدء في التطوير لنظام iOS في غضون ساعات. حتى تطبيق الهاتف المحمول البسيط يمكن تحويله على الفور إلى مشروع قوي يعمل ضمن البنية التحتية الحالية. لا تعتقد أن هذا مجرد مترجم جديد لـ FireMonkey ونمط جديد يناسب واجهة iOS.

يتضمن ذلك مصممًا مرئيًا جديدًا ودعمًا مدمجًا لعوامل الشكل المختلفة ومكتبات الوصول إلى البيانات، بما في ذلك تقنية FireDAC الجديدة وتقنية LiveBindings للربط المرن والديناميكي مع بيانات الشركة. تصل كل هذه الابتكارات في وقت واحد - لنظام التشغيل Windows، وMac OS، وiOS. غرفة العمليات نظام ماكنظام التشغيل لا يتطور بهذه السرعة، لذلك لا توجد مشاكل مثل الانتقال من Windows 7 إلى Windows 8. ولكن ظهرت شاشات شبكية العين، وهذا يتطلب اهتماما خاصا. الآن يتضمن أي تطبيق MacOS تم إنشاؤه في Delphi XE4 نمطين تلقائيًا - "عادي" و"عالي الوضوح".

الذي - التي. يمكن أن يتمتع نفس التطبيق بنفس الواجهة "الأصلية" عالية الجودة على أي تطبيق كمبيوتر سطح المكتبمن أبل.

لا تريد شركة Embarcadero "مفاجأة" المطورين أو "إدهشتهم" أو حتى "ترفيههم" بإصداراتها المبتكرة الجديدة. بل على العكس من ذلك، فإن مجال تكنولوجيا المعلومات مليء بالفعل بالمفاجآت المختلفة: أجهزة جديدة، ومنصات جديدة، ومستخدمين جدد، واحتياجاتهم الجديدة، وسيناريوهات التفاعل الجديدة. أضف إلى ذلك تقنيات تطوير برمجيات جديدة، ولن يكون لدى المبرمجين الوقت الكافي لإنشاء أنظمة جديدة وأنظمة حالية - كل ما سيفعلونه هو الانتقال من بيئة إلى أخرى، من مكتبة قديمة إلى مكتبة جديدة، من لغة إلى أخرى.

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

ستجد معنا دائمًا التطوير المرئي، واللغات الكلاسيكية، والرموز "الأصلية"، وستجعل الأنظمة الأساسية المستهدفة لتطبيقاتك، التي تم إنشاؤها بنفس الطريقة الكلاسيكية المثبتة، جديدة.

03/06/2013 الساعة 12:46 مساءً

لقد عانيت كثيرًا بسبب عدم وجود مكون المتصفح في FireMonkey. لا يزال مشروع Delphi Chromium Embedded الشهير يتضمن دعم FMX في الإصدار الأخير. ولكن على الرغم من مرور الكثير من الوقت، فإن المؤلف ليس في عجلة من أمره لإضافة دعم لـ FMX2. في النهاية، كان عليّ أن أتولى الأمر بنفسي.

يعمل مكون TChromiumFMX من التجميع الرسمي بشكل جيد في FireMonkey (في XE2)، ولكنه لا يتم تجميعه حتى في FMX2. كان علي أن أعرف قليلاً كيف يعمل وأصلحه. ولحسن الحظ، لم تكن هناك حاجة إلى تغييرات كبيرة.

في FMX2، تم تغيير شيئين يحتاجهما المكون.

أولاً، لم يعد TBitmap يحتوي على خصائص ScanLine وStartLine. تمت إعادة تصميم الوصول المباشر إلى محتويات TBitmap (أتساءل لماذا؟) وهو متاح الآن من خلال فئة TBitmapData، التي تُرجع طريقة TBitmap.Map.

حسنًا، الخيار الثاني الأكثر شهرة - Platform .* لم يعد موجودًا، والآن تحتاج إلى الحصول على الواجهة المطلوبة عبر TPlatformServices.GetPlatformService . كل شيء هنا واضح ومباشر ولا توجد مشاكل.

لم أختبره بشكل إبداعي بشكل خاص، ولكن المكون مناسب تمامًا لأغراضي - يمكنك عرض مواقع الويب من خلاله. تنزيله. ربما سأرسل أيضًا تعديلاتي إلى المؤلف، الذي قد يرى أنه من الضروري إضافتها إلى النسخة الرسمية.

30/07/2012 الساعة 2:43 صباحًا

يقترح جيسون ساوثويل تطوير مجموعة من أغلفة FireMonkey لعناصر تحكم Windows/OSX الأصلية ويقوم بجمع الأموال من أجل ذلك. في البداية، يخطط لجمع 20 ألف دولار.

الفكرة واضحة. يتم تقديم مكونات FireMonkey الحالية باستخدام دلفي تقريبًا من الصفر، والتي، من ناحية، تضمن إلى حد كبير وظائفها عبر الأنظمة الأساسية، ولكن من ناحية أخرى، نتيجة لذلك، نحصل على مكونات لا تبدو طبيعية تمامًا في كل من أنظمة التشغيل المدعومة حاليًا . وهذا ليس سيئا للغاية - بالإضافة إلى المظهر، عليك تطوير منطق هذه المكونات بشكل مستقل. على سبيل المثال، يعد RichEdit أمرًا معقدًا للغاية؛ فتكرار منطقه بنفسك داخل FireMonkey ليس بالمهمة السهلة. لم يقوم كل من VCL وCLX بإعادة اختراع العجلة، بل استخدما عجلة جاهزة.

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

المساعدة صامتة، ولم أجد أي شيء في الكود أيضًا. هل هناك حقا أي وسيلة؟ وهذا من شأنه أن يكون غير سارة للغاية.

ما هو فايرمونكي؟

FireMonkey (FMX) هو إطار عمل للتطوير عبر الأنظمة الأساسية لكل من أنظمة سطح المكتب (Windows وMac OS + ومن المقرر دعم الخادم على Linux في المستقبل القريب) والهواتف المحمولة (iOS وAndroid) باستخدام لغة Delphi/C++.

الخصائص:

• قاعدة رموز واحدة لجميع المنصات؛

• أي عنصر تحكم (مكون مرئي) يمكن أن يكون حاوية (أصل) للمكونات الأخرى؛

• وجود ترتيب نسبي متقدم جدًا (20 نوعًا) للمكونات في النموذج؛

• يتيح لك LiveBinding توصيل أي نوع من البيانات أو المعلومات بأي واجهة مستخدم أو كائنات رسومية؛

• وجود أنماط النموذج/المكونات؛

• تسمح لك ميزة Multi-Device Preview بتخصيص العرض التقديمي المرئي لكل نظام أساسي؛

• FireUI Live Preview - يعرض مظهر التطبيق على الأجهزة الحقيقية في الوقت الفعلي.

الاحتمالات:

• استخدام واجهة برمجة التطبيقات الأصلية لكل نظام أساسي، بالإضافة إلى القدرة على الاتصال بالمكتبات الأصلية التابعة لجهات خارجية؛

• التفاعل مع جميع أجهزة الاستشعار (GPS، ومقياس التسارع، والبوصلة، والبلوتوث (بما في ذلك LE) وغيرها)؛

• ودعم إشعارات الدفع وإنترنت الأشياء؛

• دعم طلبات HTTP غير المتزامنة؛

• دعم معظم قواعد البيانات (MsSQL، MySql، Oracle، PostgreSQL، MongoDB، وما إلى ذلك)؛

• العمل مع الخدمة السحابية (Amazon، وAzure)؛

• دعم خدمة أندرويد.

سلبيات (حاليا):

• نقص الدعم لتخصيص الطبقات الأصلية؛

• تنفيذ أشياء محددة إما مستحيل (الأدوات، الامتدادات (iOS)، وما إلى ذلك) أو مطلوب رقصة مع الدف (خدمة الخلفية، رسالة البث، وما إلى ذلك)؛

• تخصيص شاشة Splash (الشاشة الأولية) غير موجود، بعبارة ملطفة؛

• تستخدم عناصر تحكم FMX العرض الخاص بها (التصور، الرسم)، والذي يشبه بصريًا تمامًا العرض الأصلي؛

• استخدام الضوابط الأصلية ينطوي على حركات الجسم الكبيرة؛

• عندما يكون هناك الكثير من التداخل بين المكونات، تحدث أشياء لا تصدق: يتعطل التطبيق في أماكن مختلفة، ويفقد التركيز، ويتجمد، وما إلى ذلك؛

• محتوى المعلومات الخاص بتصحيح أخطاء أحد التطبيقات على الأنظمة الأساسية للجوال هو صفر؛

• يتم تقليل أوصاف الأخطاء على الأنظمة الأساسية المحمولة إلى "خطأ 0x00000X" عديم الفائدة؛

• وقت التجميع يريد أن يكون الأفضل للمشاريع المتوسطة والكبيرة؛

• الحاجة إلى استخدام ملف لتلميع تطبيقات الهاتف المحمول لكل منصة؛

• لا يوجد دعم لهندسة Intel Atom؛

• سعر غير مناسب مقارنة بالمنافسين.

الايجابيات:

• التطوير النشط للغاية لكل من المنتج والمجتمع مؤخرًا، ودعم المزيد والمزيد من التقنيات الجديدة؛

• وجود عدد كبير من المكونات الحرة والتجارية؛

• سرعة التطبيق قريبة جدًا من السرعة الأصلية؛

• محرر مرئي وبيئة متقدمة جدًا بشكل عام، ووجود الأنماط؛

• القدرة على اختبار التطبيق على نظام Win، وبعد ذلك فقط نشره على الأجهزة، مما يؤدي إلى تسريع عملية التطوير بشكل كبير؛

• تغيير الوضع/المنصة بنقرة من المعصم؛

• يوفر PAServer تفاعلاً سهلاً مع أنظمة MacOs عند التطوير لنظام التشغيل Apple OS؛

• دعم الرسومات ثلاثية الأبعاد خارج الصندوق.

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

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

ومع ذلك، نشأت مشكلة. لسبب ما، قررت أنني بحاجة فقط إلى تنفيذ مشروع عمل غير معقد للغاية.

لشرح سبب كون هذا يمثل مشكلة بالنسبة لي، ستكون هناك حاجة إلى بعض الاستطراد (أشعر برغبة في الكتابة والغنائية). رحلة إلى الماضي كمطور. شرح بعض آرائي حول البرمجة باستخدام دلفي.

يجب أن أقول إنني بدأت استخدام دلفي على نظام التشغيل Windows 3.1، أي من الإصدار الأول. ومنذ ذلك الحين وأنا أدرس VCL. لقد درستها في الأصل، إذا جاز التعبير. لقد بحثت، ودخلت، وتتبعت المصادر. مرة بعد مرة.

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

ولكن بعد ذلك تأتي اللحظة وأسمع أن VCL هي تقنية عفا عليها الزمن. التكنولوجيا التي يجب أن تترك في الماضي. يجب على المطورين تنفيذ جميع مشاريعهم الجديدة على FireMonkey، أما المشاريع القديمة... فسيكون من الجيد نقلها إلى مسارات جديدة. FireMonkey موجود في كل مكان وفي أي وقت. وأنا أسمع هذا من مصادر مختلفة. وبإصرار تام. لا، لا أحد يقتل VCL. يبقى معنا. لكنه لم يعد رقم واحد. يجب أن يصبح نسخة احتياطية. على الأقل هذه هي الطريقة التي أفهم بها ما يقال عن مستقبل المنتج.

من حيث المبدأ، وأنا أفهم هذا الوضع. لقد وضعنا مسارًا لمنصات متعددة، والأهم من ذلك، عبر الأنظمة الأساسية. بعد كل شيء، ما هو VCL؟ مكتبة المكونات المرئية. مكتبة المكونات البصرية. قد لا توافق على هذا. على سبيل المثال، لقد اعتبرت دائمًا العديد من المكونات غير المرئية، وليس المكونات، ولكن ببساطة الفئات، جزءًا لا يتجزأ من VCL، وعددًا كبيرًا من فئات ومكونات الطرف الثالث استمرارًا وامتدادًا لـ VCL. حسنًا، لا يمكنني التفكير في ورثة TDataset كجزء من VCL. على الرغم من أن مصطلح مكتبة DBExpress، على سبيل المثال، يشير إلى أن هذا ليس VCL. على ما يبدو، يقسم Embarcadero بالفعل المتجانسة، من وجهة نظري، VCL، إلى عدد من المكتبات المنفصلة. لا، بالطبع، ليس منفصلا تماما، ولكن مع ذلك. وإذا قبلنا وجهة النظر هذه، فإن FireMonkey يهدف إلى استبدال الجزء المرئي من VCL بدقة (كيف يمكنني تسمية المكتبة الكاملة للفئات والمكونات، ربما مكتبة Borland Component Library؟).

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

هذا هو بالضبط ما يحاول FireMonkey القيام به. إنهم يحاولون إنشاء بنية تحتية تعتمد على الآليات الأساسية المدعومة في أنظمة التشغيل المختلفة، قادرة على استبدال الخدمة التي تقدمها أنظمة التشغيل نفسها.

يتذكر الكثير من الناس المحاولةعبر الأنظمة الأساسية ليس فقط المكتبة، ولكن أيضًا دلفي نفسها. بالتوازي مع دلفي 6، تم إصدار منتج Kylix ومكتبة CLX. تم كل هذا حتى تتمكن من التطوير لنظام التشغيل Linux. ومع ذلك، لا يحتوي Linux على العديد من المفاهيم الأساسية فيما يتعلق بواجهة النافذة الرسومية التي يمتلكها Windows. واجهة النافذة لنظام التشغيل Linux ليست ظاهرة أصلية بشكل عام. هذا تطبيق اختياري. وكان علي أن أكتب نوعًا من المكتبة الاصطناعية. بمساعدتها كان من الممكن كتابة برنامج لكل من Windows و Linux. ومع ذلك، ما زلت أتذكر الشعور ليس بخيبة الأمل، بل بالإزعاج المزعج الذي شعرت به عندما حاولت استخدام المكونات المرئية التناظرية من CLX. بدأت أفتقد الكثير من الأشياء. ما اعتدت فعله دون تفكير عند التطوير باستخدام VCL تبين أنه صعب أو مختلف تمامًا أو ببساطة من المستحيل القيام به باستخدام CLX.

شعرت بنفس الطريقة تقريبًا عند التبديل من BDE إلى DBExpress. قديم، مألوف من الاختبار الميداني BDE (كان بورلاند يستخدمه بالفعل في Quattro Pro لنظام التشغيل Windows وParadox لنظام التشغيل Windows، وكان يسمى ODAPI، ثم IDAPI، وكان الرأس والكتفين أعلاه، في رأيي، Microsoft ODBC) تم الإعلان عنه التكنولوجيا القديمة التي يجب أن تفسح المجال لمكتبة جديدة في المشاريع الجديدة. كنت دائمًا أفتقر إلى شيء ما في DBExpress في البداية، وخاصة المعرفة.

في الوقت نفسه، لا أريد بأي حال من الأحوال تأنيب أو انتقاد المكتبات المذكورة أعلاه، أو القرارات التي أدت إلى ظهورها. إنه على وشكفقط عن انطباعاتي، وأحيانًا الانطباعات الأولى.

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

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

حسنا، فارق بسيط آخر مهم. ما نوع المشاريع التي يتعين عليك القيام بها عادةً في العمل، إذا لم يكن (العمل) مرتبطًا بكتابة المترجمين أو أنظمة النمذجة أو أي شيء آخر علمي للغاية؟ أعتقد أن الأمر بالنسبة لمعظم الناس هو تطوير شيء يتضمن استخدام قواعد البيانات. علاوة على ذلك، يمكن لشيء علمي للغاية أيضًا استخدام الخدمات التي يقدمها نظام إدارة قواعد البيانات (DBMS).

وهنا كان ينتظرني كمين آخر. لسبب ما، عندما تصادف حقيقة أن FireMonkey لا يحتوي على عناصر تركز على العمل مع البيانات المخزنة في قاعدة البيانات، تجد نفسك غير مستعد تمامًا لذلك (بعبارة ملطفة). على الرغم من أنني قرأت عن هذا عدة مرات بالفعل وأعرف (نظريًا) ما يجب استخدامه. نحن نتحدث عن الارتباطات الحية.

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

هذا هو المكان الذي أريد أن أختم فيه رسالتي حول الانطباعات الأولى. التالي هو قصص حول ما تم التغلب عليه وكيف تم التغلب عليه أثناء العمل في المشروع.