خوب جناب کیانی اگه اجازه ایراد متنتون رو بگم با اجازه;)

1/ 1 فلسفه وجودی WPF در یه جمله خلاصه میشه
Designer And Developer Work With Together
در مدلها قبلی WinApp چیزی که طراح میخواست با چیزی که برنامه نویس پیاده سازی میکرد زمین تا اسمون فرق داشت ولی با ظهور WPF و XAML این تفاوت به صفر میرسه

2/WPF چیزه جدیدی بشما ارائه میده سیستم نمایشی Vector Base هست یعنی همه چیز رو یه Vector میبینه برای همین شما هر چقدر هم رو کنترلها و تصاویز Zoom داشته باشید افت کیفیت رو مشاهده نمیکنید

3/ من این رو قبول ندارم
WPF از تمامی قدرت DirectX جهت ایجاد گرافیک های 2 بعد، 3 بعدی، ایجاد انیمیشن ها، استفاده می کند.
اگه قرار بود این باشه در SP1 دات نت 3.5 WPF با DirectX یکپارچه نمیشد

4/
یک برنامه نویس WPF حرفه ای حتی المقدور از خواص Width و Height اشیاء برای چیدمان آن ها استفاده نخواهد کرد. یقینا برایتان غیر قابل تصور است. به این دلیل که تا الان هر عنصری که در برنامه خود استفاده کرده اید، پس از نامگذاری آن اقدام به ایجاد سایز مناسب آن نمده اید. اما در نمونه برنامه ها و بخش های آتی خواهید دید، که کمترین استفاده را از این دو خاصیت خواهیم کرد. این موضوع به دلیل ماهیت WPF و غیر وابسته بودن به رزولوشن صفحه نمایش می باشد که در قسمت بعدی بیشتر به شرح آن خواهم پرداخت.
در همه جا سازگار نیست مثال در یه Canvas شما یه Button بدون تعیین سایز بده ببین چی بهت نشون میده

5/
طراحی واسط های کاربری در مدل های برنامه نویسی قبل از WPF (برنامه های ویندوزی ) همیشه با بخش کد و منطق برنامه درگیر بوده است. در بهترین حالت، در دات نت فریم ورک 2.0، هر فرم که به عنوان بالاترین آبجکت و به عنوان پدر تمامی آبجکت ها در برنامه های استفاده می شد، دراای دو کلاس مجزا بود.(هست) یکی از این کلاس ها که دارای متدی به نام InitializedComponents بود، (هست). این متد وظیفه طراحی فرم و آبجکت های درون آن را بر عهده داشت. به محض قرار گیری آبجکتی مانند Button بر روی فرم، کدهایی درون متد مذکور به صورت اتوماتیک و توسط خود محیط برنامه نویسی ویژوال استودیو نوشته می شد. این کد ها مربوط به نحوه قرار گیری آبجکت مورد نطر بر روی فرم بود.(هست). و کلاس دیگر معمولا برای کد نویسی و ایجاد منطق برنامه و مشخص کردن عملکرد فم مربوطه و آبجکت های مربوطه به کار می رفت.(می رود). این مسئله ممکن است هیچ ایرادی در یک نگاه سطحی به همراه نداشته باشد. اما در گروه های برنامه نویسی، این یک معضل می باشد. به این دلیل که همیشه طراح با کد نویس درگیر است. این مشکل زمانی بیشتر خود را نشان می دهد که طراح برنامه، ( منظور از طراح، گرافیست برنامه می باشد) از کد نویسی و منطق های برنامه نویسی اطلاعات چندانی نداشته باشد
.
این موضوع با ورود ASP.NET 2.0 و به وجود آمدن مبحث Code Behind که منطق برنامه را از طراحی آن جدا می کرد، تا حدی مرتفع گردید. البته کماکان برای برنامه های ویندوزی هیچ راه حل مناسبی وجود نداشت.
این رو رد میکنم در WPF هم باز InitializeComponent وجود داره و دقیقا" کاری شبیه WinApp ها داره برای اطلاع بیشتر توصیه میکنم کتاب Application = Code + Markup رو مطالعه کنید و بحث طراحی در جای دیگه وجود داره اون هم بحث Resource ها و Style ها رو میطلبه اینکه چه جوری یه طراح و برنامه نویس باهم کار میکنن رو بعد از مطالعه دو بحث فوق خواهید یافت

6/XAML هم فکر کنم بشه با گفتن یه جمله ساده به خواننده فهماند
XAML is Supper HTML
XAML یه زبانه نشانه کذاری هست و در حالت عادی Parse میشه ولی ایا همین برای برنامه نویس WPF کافیه؟
خیر در XAML شما امکان کد نویسی رو هم دارید ان یکی از امکانات جالب XAML است
برای اطلاعات بیشتر رجوع شود به XAML in Nutshell

7/
سعی کنید، عادت به استفاده از روش دوم ( روش د ) در تنظیم خواص آبجکت ها کنید. البته این موضوع بیشتر برای زمانی استفاده می شود که بخواهید از خواص پیچیده و ترکیبی برای یک آبجکت استفاده کنید.( این موضوع را کمی جلوتر خواهید دید). ولی به عنوان نمونه برای مثال فوق، بهتر است که از روش ( ج ) به جای روش ( د) استفاده گردد.
این عادت رو باید بهتر کرد اون هم با Resource ها

8/ جای Markup Extension ها خالیه واقعا" کمبود اونها احساس میشه

منتظر بقیه مطالبتون هستیم با تشکر WinFx