مصمم نافذة API الأصلية

Question

لماذا لا يوجد مصمم لنماذج API الأصلية في Visual Studio؟ مماثلة ل دلفي؟ إذا كان هناك بعض البرامج والأدوات وغيرها، يرجى الاستحقحات.

ما هو أفضل نهج لتصميم النوافذ المعقدة في API النقي؟

Answer 1

ربما لم تكن هناك طريقة قياسية للقيام بتخطيطات التحكم في Winapi، عليك إدارة ذلك بنفسك. لا توجد فئة "تحكم" قاعدة في Winapi - كل شيء نافذة من نوع ما، لذلك لا توجد طريقة لدعم خلافاتها مع محرر / مصمم تخطيط مشترك.

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

أو التكيف screenlib. إلى احتياجات سطح المكتب الخاص بك.

Answer 2

هناك محرر Ressource Dialogs، ثم يوجد رمز. لم أفتقد أبدا بعض أداة التصميم المرئي، على الرغم من أن بعض الدعم الأفضل من عناصر التحكم أنفسهم سيكون لطيفا.

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

تم تصميم WinForms من الألف إلى الياء مع دعم المصمم في الاعتبار، ويظهر ذلك. كان مخاوف التصميم الرئيسي لضوابط WIN32 بصمة الذاكرة من التعليمات البرمجية والبيانات.

حتى MFC (التي لا تزال تظهر العديد من علامات ندرة الذاكرة) لا يتمجرد هذه الشذوذ بعيدا بما يكفي لتبرير مصمم نماذج لائقة.

جميع البيئات التي تأتي مع محرر نماذج لائقة (أتذكر Watch ++ / Optima، والزنك، والبعض الآخر قد نسيت أسماء) تأتي أيضا مع مكتبة أشكال كريمة مع مستوى تجريد مرتفع.

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

---

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

Answer 3

انها بسبب مايكروسوفت. لقد انتقلوا بالفعل نحو dotnet و c #. يحتوي Visual Studio 2005 على محرر GUI لطيف لأولئك. لماذا تحتاج إلى استخدام API النقي؟