سئوالات و مباحث WPF

the_king

مدیرکل انجمن
خیلی ممنون استاد :rose:
خوب اگه رندر در نخ مجزایی انجام میشه ، پس چرا مشکل با ایجاد کردنِ کنترل در نخ مجزا را داره؟
چون thread safe بودن ربطی به تقسیم وظایف بین نخ ها نداره. thread safe به این معنا است که بشه از هر نخی به اون شیء دسترسی داشت و فرضا کنترل جدید بسازید یا مشخصه های کنترل رو تغییر بدهید.
کنترل ها نه در Windows Forms و نه در WPF معماری thread safe ندارند.
در WPF صرفا رندر و نمایش به نخ دیگری واگذار شده. اون نخی که صاحب کنترل ئه همچنان تنها نخ مجاز به مدیریت کنترل ئه، thread safe نیست که شما از یک نخ دیگه هم به کنترل دسترسی پیدا کنید.
مجزا شدن رندر و نمایش هم همینطور، یک نخ مسئولیت اینکار رو برعهده داره و thread safe نیست که از نخ های دیگه ای هم بخواهید رندر کنید.
رندر در نخ مجزا به این معنی نیست که از هر نخی که دلتون خواست بتوانید کنترل بسازید یا به کنترل ها دسترسی داشته باشید یا رندر کنید و ...

چون اگه اشتباه نکنم ، عاملی که باعث میشه با کنترل ها در نخ مجزا مشکل پیدا کنه ، رسم و رندر کنترل هست دیگه ؟
نه. مساله دسترسی به کنترل ئه، حتی اگه در ظاهر و نمایش کنترل بی تاثیر باشه. اجرا کردن کد var hwnd = textBox1.Handle که تاثیری در ظاهر و رندر نداره، منجر به نمایش یا رندر که نمیشه، صرفا دسترسی ئه، همین دسترسی در نخ مجزا منجر به بروز خطا میشه.

وگرنه برای ایجاد اغلب قریب به اتفاقِ اشیاهای دیگه بجز کنترل ها و اشیاء های گرافیکی ، در نخ های دیگه که مشکلی نیست .
بحث هر نوع داده ای که نیست، اینکه کنترل های ویندوز thread safe نیستند که ربطی به موارد دیگه نداره.

این ، یکی از مهم ترین قابلیت های WPF به شمار میره که باعث میشه نیاز به استفاده از کنترل ها و کمپوننت های شرکت های دیگه (مثل Telerik و ...) نشه یا بصورت چشمگیری کم بشه .
چرا یکی از مهمترین قابلیت های WPF به شمار میره؟ چطوری قابلیت های WPF رو امتیاز بندی کرده اید که این شده جزو مهمترین قابلیت هاش؟
مگه در Windows Forms غیر از این بوده؟ شما وقتی در OnPaint ظاهر یک کنترل Windows Forms رو تغییر می دهید منطق کنترل تحت تاثیر قرار میگیره؟
بعد چطور از این نتیجه میگیرید که نیاز به کنترل ها و کمپوننت های شرکت های دیگه نمیشه یا کم میشه؟ توضیحش چیه؟
مثلا دیگه کاربر نیازی به RadialMenu و TimeBar و PanelBar پیدا نمی کنه و خودش همه رو میسازه؟ این قابلیت های برنامه نویس یهو چطوری شکوفا میشن؟

6) سرعت بیشتر و صرف زمان کمتر برای طراحی ظاهر کاربری دلخواه
این مورد جای بحث داره، WPF در طراحی ظاهر کاربری دلخواه قابلیت های زیادی داره اما مدت زمان لازم برای طراحیش میتونه برعکس زمانبر باشه.

2) کندی اجرای کدها
این مساله موردی است، نمی توانید حکم کلی بدید. در هر مثال میتونه شرایط متفاوت باشه، نمی توانید کلی بگید اجرای کد ها کندتر ئه یا سریعتر.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
چون thread safe بودن ربطی به تقسیم وظایف بین نخ ها نداره. thread safe به این معنا است که بشه از هر نخی به اون شیء دسترسی داشت و فرضا کنترل جدید بسازید یا مشخصه های کنترل رو تغییر بدهید.
کنترل ها نه در Windows Forms و نه در WPF معماری thread safe ندارند.
در WPF صرفا رندر و نمایش به نخ دیگری واگذار شده. اون نخی که صاحب کنترل ئه همچنان تنها نخ مجاز به مدیریت کنترل ئه، thread safe نیست که شما از یک نخ دیگه هم به کنترل دسترسی پیدا کنید.
مجزا شدن رندر و نمایش هم همینطور، یک نخ مسئولیت اینکار رو برعهده داره و thread safe نیست که از نخ های دیگه ای هم بخواهید رندر کنید.
رندر در نخ مجزا به این معنی نیست که از هر نخی که دلتون خواست بتوانید کنترل بسازید یا به کنترل ها دسترسی داشته باشید یا رندر کنید و ...


نه. مساله دسترسی به کنترل ئه، حتی اگه در ظاهر و نمایش کنترل بی تاثیر باشه. اجرا کردن کد var hwnd = textBox1.Handle که تاثیری در ظاهر و رندر نداره، منجر به نمایش یا رندر که نمیشه، صرفا دسترسی ئه، همین دسترسی در نخ مجزا منجر به بروز خطا میشه.


بحث هر نوع داده ای که نیست، اینکه کنترل های ویندوز thread safe نیستند که ربطی به موارد دیگه نداره.

خیلی ممنون استاد .
پس نخ Thread Safe باعث میشه ، هر نخِ Thread Safe ئه دیگه ای به اشیاء (کنترل و هر شی دیگه) همدیگه دسترسی داشته باشن اما نقطه ی مقابلش که Single Thread Apartment هست باعث میشه اون شی ، فقط در همین نوع نخ ای که ایجاد شد ، در دسترس باشه؟ درسته؟
اگه آره ، پس چرا نخی که STA هست ، فقط با دسترسی به اشیاء کنترل ها مشکل داره و با اشیاء های دیگه (که اغلب غیر کنترل و غیر گرافیکی هستن) ، مشکلی نداره؟

چرا یکی از مهمترین قابلیت های WPF به شمار میره؟ چطوری قابلیت های WPF رو امتیاز بندی کرده اید که این شده جزو مهمترین قابلیت هاش؟
مگه در Windows Forms غیر از این بوده؟ شما وقتی در OnPaint ظاهر یک کنترل Windows Forms رو تغییر می دهید منطق کنترل تحت تاثیر قرار میگیره؟
بعد چطور از این نتیجه میگیرید که نیاز به کنترل ها و کمپوننت های شرکت های دیگه نمیشه یا کم میشه؟ توضیحش چیه؟
مثلا دیگه کاربر نیازی به RadialMenu و TimeBar و PanelBar پیدا نمی کنه و خودش همه رو میسازه؟ این قابلیت های برنامه نویس یهو چطوری شکوفا میشن؟


این مورد جای بحث داره، WPF در طراحی ظاهر کاربری دلخواه قابلیت های زیادی داره اما مدت زمان لازم برای طراحیش میتونه برعکس زمانبر باشه.


این مساله موردی است، نمی توانید حکم کلی بدید. در هر مثال میتونه شرایط متفاوت باشه، نمی توانید کلی بگید اجرای کد ها کندتر ئه یا سریعتر.

استاد ، من چی کار کنم دیگه؟ اینها که بازتاب صحبت های شما بود (اگه درست متوجه شده باشم) :green:
بحث هم کنیم ، طولانی میشه . متن آموزش یه قسمت ، یه هفته داره طول میکشه .:green:

درباره ی سرعت بیشتر طراحی و توسعه که خودتون در پست 271 گفته بودین .
برای کندی اجرای کدها ، بنویسم "بعضی از کدها ، کندتر اجرا میشوند" خوبه یا کلا حذف کنم؟
خودتون اون پروژه را داده بودین و زمان اجرای کدهای wpf خیلی کمتر بود .

درباره ی اون قضیه ی template هم بحث کنم ، میدونم بحث طولانی میشه . من هم از هدفم که ارائه ی متن درست هست ، دور میشم . حالا یا اون تیکه که گفتین را ویرایش میکنم یا حذف میکنم .
تشکر :rose:
 

the_king

مدیرکل انجمن
خیلی ممنون استاد .
پس نخ Thread Safe باعث میشه ، هر نخِ Thread Safe ئه دیگه ای به اشیاء (کنترل و هر شی دیگه) همدیگه دسترسی داشته باشن اما نقطه ی مقابلش که Single Thread Apartment هست باعث میشه اون شی ، فقط در همین نوع نخ ای که ایجاد شد ، در دسترس باشه؟ درسته؟
Single Thread Apartment ربطی به این مورد نداره، Single Thread Apartment یک مدل ئه.
Thread Safe صرفا یک ویژگی مثبت ئه که با پیاده سازی یک اصولی در طراحی اجرا میشه که اگه باشه خوبه، اگه نباشه معنی اش Thread Unsafe بودنه ولی ویژگی خاصی به نام Thread Unsafe نداریم.
همانطور که Waterproof رو به عنوان مقاوم در برابر آب داریم ولی برعکسش Non Waterproof میشه، یعنی نامقاوم در برابر آب ولی معمولا در توصیف چیزی ویژگی منفی نمیگن.

اگه آره ، پس چرا نخی که STA هست ، فقط با دسترسی به اشیاء کنترل ها مشکل داره و با اشیاء های دیگه (که اغلب غیر کنترل و غیر گرافیکی هستن) ، مشکلی نداره؟
نه، ربطی به این قضیه نداره، در ضمن قبلا هم بهتون گفتم که STA و MTA برای ارتباط COM ئه، روی سایر موارد تاثیری نداره.

استاد ، من چی کار کنم دیگه؟ اینها که بازتاب صحبت های شما بود (اگه درست متوجه شده باشم) :green:
بحث هم کنیم ، طولانی میشه . متن آموزش یه قسمت ، یه هفته داره طول میکشه .:green:
چی رو چیکار کنید؟ بحث لازم نیست، سوال هایی که کردم رو جواب بدید مساله حل میشه.
دنبال این نباشید که تعداد آیتم ها رو بیشتر کنید، ارزش مطلب به بار محتوی اونه، نه طولش. دو آیتم قاطعانه و مستدل که مو لای درزش نره می ارزه به بیست تا آیتم که نشه ازشون دفاع کرد.

درباره ی سرعت بیشتر طراحی و توسعه که خودتون در پست 271 گفته بودین .
بله، ولی چیزی که شما نوشتید سرعت طراحی و توسعه نیست، "طراحی ظاهر کاربری دلخواه" فرق می کنه با "طراحی و توسعه برنامه". خودتون که دیدید در پست 279 از معایب WPF یک ایراد کلی رو در همین مورد گفتم :
ولی یکسری معایب کلی داره که در اغلب منابع بهش اشاره شده، سنگین تر ئه و منابع بیشتری مصرف می کنه، چون عمر کمتری داره طبعا تعداد منابع آموزشی و نمونه کد ها و تنوع کنترل ها و متخصصین کمتری داره، هنوز Designer اش تمام عیار و خیلی کاربر پسند نیست و باگ های آزار دهنده داره، یادگیری اش زمان بیشتری لازم داره، طراحی ظاهر واسط کاربری اش وقت بیشتری میگیره و ...

برای کندی اجرای کدها ، بنویسم "بعضی از کدها ، کندتر اجرا میشوند" خوبه یا کلا حذف کنم؟
ویرایش کردنش کمکی نمی کنه چون هدف باید از بیان یک مورد این باشه که مخاطب با خوندنش ارزیابی مفیدی بکنه. باید حذف بشه چون ازش نمیشه نتیجه گیری کرد.
اینکه برخی موارد فلان باشه نه ویژگی منحصر بفردی است و نه مزیت و نه عیب. کسی هم نمیتونه از روی این "بعضی کد ها" ارزیابی مفیدی داشته باشه، نمیدونه بعضی کد ها یعنی چه کدهایی. هر تصوری بکنه گمراه شده.

خودتون اون پروژه را داده بودین و زمان اجرای کدهای wpf خیلی کمتر بود .
بله، ولی اگه اون پست همراهش رو خونده باشید در همون پست هم توضیح دادم که مبادا کسی از روی مثالی که زدم قضاوت کلی نکنه که پس WPF خوبه یا نیست.
قرار نیست از روی یک مثال قضاوت بشه که WPF سریعتره یا کندتر. اگه صد تا مثال هم مانند این دیدید نمیتوانید نتیجه کلی بگیرید. با مثال جزئی فرض کلی اثبات نمیشه.
فقط این مثال کمک می کرد که تصور نشه که چون WPF از DirectX استفاده میکنه و DirectX هم از +GDI مجهزتر و سریعتر ئه پس WPF همواره رسم سریعتری داره.
این تصور اشتباه رو همون یک مثال میتونه نقض کنه، کارکردش همینه. در اون تاپیک هم من اون مثال رو صرفا برای نقض کردن اون تصور اشتباه نوشتم.
اما برعکسش رو هم نباید بپذیریم. نمی توانیم نتیجه بگیریم که WPF از Windows Forms کند تر ئه چون ما یک مثال داشتیم که کند تر بود. از مثال ها نتیجه کلی نمیشه گرفت.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
Single Thread Apartment ربطی به این مورد نداره، Single Thread Apartment یک مدل ئه.
Thread Safe صرفا یک ویژگی مثبت ئه که با پیاده سازی یک اصولی در طراحی اجرا میشه که اگه باشه خوبه، اگه نباشه معنی اش Thread Unsafe بودنه ولی ویژگی خاصی به نام Thread Unsafe نداریم.
همانطور که Waterproof رو به عنوان مقاوم در برابر آب داریم ولی برعکسش Non Waterproof میشه، یعنی نامقاوم در برابر آب ولی معمولا در توصیف چیزی ویژگی منفی نمیگن.


نه، ربطی به این قضیه نداره، در ضمن قبلا هم بهتون گفتم که STA و MTA برای ارتباط COM ئه، روی سایر موارد تاثیری نداره.

سلام
خیلی ممنون استاد .
من الان دقیق متوجه نشدم .
الان شما میگید که نخ ای که در wpf رسم را انجام میده ، اولا یک نخ هست و دوما مجزا از نخ های دیگه هست که فقط خود wpf اون را مدیریت میکنه؟
اگه درسته ، خوب این به چه معناست؟ یعنی ما وقتی کدهای مربوط به کنترل را که مجبوریم در نخ اصلی بنویسیم (مثلا وقتی یه کدی مینویسیم که قراره دکمه ای را رسم کنه یا رسم دکمه ای را به روز کنه یا تغییر بده) ، wpf کدهای بخش رسمِ اون دکمه را که در نخ اصلی نوشته بودیم را به نخ ای که خودش برای رسم کارها(ی رسم) را انجام میده ، منقل میکنه و کدهاش را اجرا میکنه؟ آیا به این معناست؟
و اگه چیزی که گفتم ، درسته ، پس آیا این شدنی هه که ما کدمون را در هر نخی که نوشتیم ، بتونیم در نخ دیگه ای اجراش کنیم؟ یعنی مثلا کدمون را در نخِ برنامه های دیگه هم بتونیم اجرا کنیم؟

من فکر میکردم چون رندرِ wpf را میشه در هر نخی انجام داد و بخاطر اتلاف زمان در سوئیچ بین نخ هاست که رسم در wpf ، اون همه از رسم در winform (در مثال و پروژه ای که دادید) کندتر هه .

چی رو چیکار کنید؟ بحث لازم نیست، سوال هایی که کردم رو جواب بدید مساله حل میشه.
دنبال این نباشید که تعداد آیتم ها رو بیشتر کنید، ارزش مطلب به بار محتوی اونه، نه طولش. دو آیتم قاطعانه و مستدل که مو لای درزش نره می ارزه به بیست تا آیتم که نشه ازشون دفاع کرد.


بله، ولی چیزی که شما نوشتید سرعت طراحی و توسعه نیست، "طراحی ظاهر کاربری دلخواه" فرق می کنه با "طراحی و توسعه برنامه". خودتون که دیدید در پست 279 از معایب WPF یک ایراد کلی رو در همین مورد گفتم :

بله استاد . الان که بیشتر فکر میکنم ، میبینم چندان تفاوتی بین رسم دلخواه کنترل ها در winform و wpf نیست .
ولی با اون حال نمیدونم چرا من توی کدنویسی wpf ، حس میکنم خیلی راحت ترم و تغییر ظاهر کنترل ها را خیلی سریعتر میتونم نسبت به winform انجام بدم .

این سئوال تون منو به این واداشت که حتی فکر کنم که آیا الکی روی wpf وقت گذاشتم یاد بگیرم و آیا برای تغییر سریعتر و راحت تر کنترل ها (که هدفم از یادگیری wpf همین بود) ، عملا wpf ، کاربرد چندانی نداره؟
هر چند خصوصیات بیشتری برای کنترل های wpf هست .

ویرایش کردنش کمکی نمی کنه چون هدف باید از بیان یک مورد این باشه که مخاطب با خوندنش ارزیابی مفیدی بکنه. باید حذف بشه چون ازش نمیشه نتیجه گیری کرد.
اینکه برخی موارد فلان باشه نه ویژگی منحصر بفردی است و نه مزیت و نه عیب. کسی هم نمیتونه از روی این "بعضی کد ها" ارزیابی مفیدی داشته باشه، نمیدونه بعضی کد ها یعنی چه کدهایی. هر تصوری بکنه گمراه شده.


بله، ولی اگه اون پست همراهش رو خونده باشید در همون پست هم توضیح دادم که مبادا کسی از روی مثالی که زدم قضاوت کلی نکنه که پس WPF خوبه یا نیست.
قرار نیست از روی یک مثال قضاوت بشه که WPF سریعتره یا کندتر. اگه صد تا مثال هم مانند این دیدید نمیتوانید نتیجه کلی بگیرید. با مثال جزئی فرض کلی اثبات نمیشه.
فقط این مثال کمک می کرد که تصور نشه که چون WPF از DirectX استفاده میکنه و DirectX هم از +GDI مجهزتر و سریعتر ئه پس WPF همواره رسم سریعتری داره.
این تصور اشتباه رو همون یک مثال میتونه نقض کنه، کارکردش همینه. در اون تاپیک هم من اون مثال رو صرفا برای نقض کردن اون تصور اشتباه نوشتم.
اما برعکسش رو هم نباید بپذیریم. نمی توانیم نتیجه بگیریم که WPF از Windows Forms کند تر ئه چون ما یک مثال داشتیم که کند تر بود. از مثال ها نتیجه کلی نمیشه گرفت.

خیلی ممنون استاد .
 

the_king

مدیرکل انجمن
سلام
خیلی ممنون استاد .
من الان دقیق متوجه نشدم .
الان شما میگید که نخ ای که در wpf رسم را انجام میده ، اولا یک نخ هست و دوما مجزا از نخ های دیگه هست که فقط خود wpf اون را مدیریت میکنه؟
در حالت کلی بله، اما اینکه یک نخ بکار ببره یا چند نخ، مربوط به معماری WPF ئه، ربطی برنامه نویس WPF نداره چون دخالتی در رندر نداره. فرض کنید n نخ باشه، اصلا مهم نیست یک نخ یا دو نخ.
اگر در معماری WPF برای افزایش کارایی تغییری در تعداد نخ ها بوجود بیاد همچنان تاثیری در مساله نداره.
اینجور موارد رو می توانید جستجو کنید، لازم نیست از من بپرسید.
Threading Model - WPF
Typically, WPF applications start with two threads: one for handling rendering and another for managing the UI.

اگه درسته ، خوب این به چه معناست؟ یعنی ما وقتی کدهای مربوط به کنترل را که مجبوریم در نخ اصلی بنویسیم (مثلا وقتی یه کدی مینویسیم که قراره دکمه ای را رسم کنه یا رسم دکمه ای را به روز کنه یا تغییر بده) ، wpf کدهای بخش رسمِ اون دکمه را که در نخ اصلی نوشته بودیم را به نخ ای که خودش برای رسم کارها(ی رسم) را انجام میده ، منقل میکنه و کدهاش را اجرا میکنه؟ آیا به این معناست؟
نه. شما کدی نمی نویسید که خودش رسم انجام بده، کدی می نویسید که نهایتا درخواست رسم می کنه. حتی وقتی در Windows Forms می نوشتید Invalidate یا BackColor رو تغییر می دادید رسم انجام می داد؟ نمیداد.
صرفا منجر به ارسال درخواست رسم میشد. در Windows Forms نخی ای که به این درخواست ها رسیدگی میکرد و رسم رو انجام میداد همون نخ اصلی بود، حالا در WPF این نخی که مسئول رسیدگی به رسم و رندر ئه یک نخ مجزا و مستقل ئه، بقیه اش شبیه همونه با این تفاوت که کنترل تون روی اون سیستم رندر و نخ اش خیلی محدود شده. چیزی از کد شما منتقل یا Invoke نمیشه چون کد شما کد رسم نیست، صرفا کد دسترسی به کنترل ئه.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
در حالت کلی بله، اما اینکه یک نخ بکار ببره یا چند نخ، مربوط به معماری WPF ئه، ربطی برنامه نویس WPF نداره چون دخالتی در رندر نداره. فرض کنید n نخ باشه، اصلا مهم نیست یک نخ یا دو نخ.
اگر در معماری WPF برای افزایش کارایی تغییری در تعداد نخ ها بوجود بیاد همچنان تاثیری در مساله نداره.
اینجور موارد رو می توانید جستجو کنید، لازم نیست از من بپرسید.
Threading Model - WPF



نه. شما کدی نمی نویسید که خودش رسم انجام بده، کدی می نویسید که نهایتا درخواست رسم می کنه. حتی وقتی در Windows Forms می نوشتید Invalidate یا BackColor رو تغییر می دادید رسم انجام می داد؟ نمیداد.
صرفا منجر به ارسال درخواست رسم میشد. در Windows Forms نخی ای که به این درخواست ها رسیدگی میکرد و رسم رو انجام میداد همون نخ اصلی بود، حالا در WPF این نخی که مسئول رسیدگی به رسم و رندر ئه یک نخ مجزا و مستقل ئه، بقیه اش شبیه همونه با این تفاوت که کنترل تون روی اون سیستم رندر و نخ اش خیلی محدود شده. چیزی از کد شما منتقل یا Invoke نمیشه چون کد شما کد رسم نیست، صرفا کد دسترسی به کنترل ئه.

ممنون استاد .
آها پس ما فقط درخواست رسم را میکنیم نه اینکه مثلا با فراخونیِ متدی یا پروپرتی یا عضوی که باعث رسم میشه (مثلا پروپرتی BackColor برای کنترل های WinForm که باعث تغییر رنگ میشد) ، این طور نیست که در اون پروپرتی ، کدهای مربوط به رسم نوشته شده باشه . بلکه فقط درخواست رسم را میده و حالا دات نت (یا clr ، نمیدونم) اون رسم را هر وقت که خودش میدونه ، در نخ اصلی (مثل WinForm) یا در نخ مجزای دیگه (مثل wpf) انجام میده . درسته؟
در واقع اون موقعی که قضیه ی "درخواست رسم" را قبلا بهم میگفتید ، الان دارم دقیق تر متوجه میشم که منظورتون چی بود .

-------------------------------

استاد ، درباره ی اون قضیه که در پست قبلی گفتم که الان فکر میکنم ، تفاوت چندانی توی WinForm و wpf نمیبینم ، شما نظرتون را میگید؟
الان با سئوالاتی که ازم پرسیدین ، حتی توی ظاهر و شخصی سازی های wpf ، فرق چندانی توی WinForm و wpf نیست انگار .
تفاوت ها انگار فقط روی سیستم layout کنترل ها (اینکه مثلا یه کنترلی میتونه بچرخه و ...) و سیستم رندرشون (اینکه مثلا یه کنترلی میتونه opacity داشته باشه) هست .اگه موافق با نظرم موافقید ، این تفاوت رو به نظرتون توی آموزش اضافه کنم؟
اما به نظر میاد میشد این دو فرق را کاری کرد که با توسعه ی همون WinForm ، حل بشه و نیاز به ایجاد پلتفرم مجزا نباشه .
پس مایکروسافت چرا اصلا اومد یه پلتفرم مجزای از WinForm ، بنام wpf ایجاد کرد و هدف اصلی اش چی بوده؟

راستی ، قبلا گفتید طراحی و توسعه توی wpf سریعتر انجام میشه ، من فکر کردم منظورتون طراحی و توسعه ی ظاهر کاربری و کنترل ها هست که گفتید نیست . منظورتون از این را هم متوجه نشدم؟
چون اگه ظاهر کاربری و کنترل ها را در نظر نگیریم ، بخش کدنویسیِ wpf با WinForm که فرقی ندارن با هم . هر دو از سی شارپ (یا ویژال بیسیک) و دات نت استفاده میکنن . هیچ چیزِ کمتر یا بیشتری نسبت به هم از این لحاظ ندارن .

تشکر :rose:
 

the_king

مدیرکل انجمن
ممنون استاد .
آها پس ما فقط درخواست رسم را میکنیم نه اینکه مثلا با فراخونیِ متدی یا پروپرتی یا عضوی که باعث رسم میشه (مثلا پروپرتی BackColor برای کنترل های WinForm که باعث تغییر رنگ میشد) ، این طور نیست که در اون پروپرتی ، کدهای مربوط به رسم نوشته شده باشه . بلکه فقط درخواست رسم را میده و حالا دات نت (یا clr ، نمیدونم) اون رسم را هر وقت که خودش میدونه ، در نخ اصلی (مثل WinForm) یا در نخ مجزای دیگه (مثل wpf) انجام میده . درسته؟
بله.

استاد ، درباره ی اون قضیه که در پست قبلی گفتم که الان فکر میکنم ، تفاوت چندانی توی WinForm و wpf نمیبینم ، شما نظرتون را میگید؟
تفاوت ها همیشه خودشون رو در نگاه اول نشون نمیدن.هر چقدر روی جزئیات متمرکز بشید تفاوت ها رو بیشتر می بینید، هر چقدر که کلی تر مقایسه شون کنید شباهت هاشون رو بیشتر می بینید.
مادامی که مثال ها کوچک و ساده باشه (که فرضا یک دکمه باشه که با کلیک رویش Hello World رو نمایش میده) خیلی پلتفرم ها شبیه هم هستند، نه با چالش مواجه می شوید و نه محدودیت ها رو می بینید.
اما هر چقدر که جزئیات کار بیشتر باشه تفاوت ها بهتر خودشون رو نشون میدن.

الان با سئوالاتی که ازم پرسیدین ، حتی توی ظاهر و شخصی سازی های wpf ، فرق چندانی توی WinForm و wpf نیست انگار .
اگه منظورتون نیاز به کد نویسی ئه، بله، در هر پلتفرمی که باشه برای ساختن یک کنترل کد نویسی لازم ئه و صرفا ساختن ظاهر کفایت نمی کنه.

تفاوت ها انگار فقط روی سیستم layout کنترل ها (اینکه مثلا یه کنترلی میتونه بچرخه و ...) و سیستم رندرشون (اینکه مثلا یه کنترلی میتونه opacity داشته باشه) هست .اگه موافق با نظرم موافقید ، این تفاوت رو به نظرتون توی آموزش اضافه کنم؟
طبعا باید در آموزش بهش بپردازید چون اونقدر که به جلوه های بصری در WPF توجه میشه در Windows Forms نمیشه.

اما به نظر میاد میشد این دو فرق را کاری کرد که با توسعه ی همون WinForm ، حل بشه و نیاز به ایجاد پلتفرم مجزا نباشه .
نه. شدنی نیست.

پس مایکروسافت چرا اصلا اومد یه پلتفرم مجزای از WinForm ، بنام wpf ایجاد کرد و هدف اصلی اش چی بوده؟
اولا منافع اقتصادی در بوجود آمدن هر تکنولوژی جدیدی نقش داره، ثانیا WPF دست گرافیست ها رو در طراحی واسط کاربری بازتر کرد.
ثالثا مایکروسافت به یک پلتفرم رایگان و کد باز نیاز داشت که برای توسعه نرم افزار ها به سیستم عامل های دیگه بجز ویندوز هم مناسب باشه، شاید الان چنین نباشه ولی حداقل پتانسیل و قابلیتش رو داره.
رابعا طراحی یک پلتفرم جدید و مدرن راحت تر از ارتقاء و ویرایش یک پلتفرم خیلی قدیمی است که به هر جاش دست بزنید با یکسری کنترل قدیمی ناسازگار میشه.

راستی ، قبلا گفتید طراحی و توسعه توی wpf سریعتر انجام میشه ، من فکر کردم منظورتون طراحی و توسعه ی ظاهر کاربری و کنترل ها هست که گفتید نیست . منظورتون از این را هم متوجه نشدم؟
چون اگه ظاهر کاربری و کنترل ها را در نظر نگیریم ، بخش کدنویسیِ wpf با WinForm که فرقی ندارن با هم . هر دو از سی شارپ (یا ویژال بیسیک) و دات نت استفاده میکنن . هیچ چیزِ کمتر یا بیشتری نسبت به هم از این لحاظ ندارن .
طراحی و توسعه نرم افزار یک روال کلی ئه که کد نویسی و طراحی ظاهر برنامه جزئی از اونه، در مجموع برای توسعه یک نرم افزار در WPF زمان کمتری مورد نیاز ئه.
فرضا به این دلیل که برای یکسری تغییرات ظاهری ساده که در چندین فرم و کنترل تکرار می شوند لازم نیست تک تک مشخصه ها تنظیم بشه، کد نویسی بشه یا کلاس سازی بشه و ...
کار هایی است که Style و Template از پسشون برمیان و به راحتی روی چندین کنترل هم اعمال میشن، Style ها از پروژه های دیگه کپی میشن و ...
اما از اونجایی که فرم های Windows Forms عموما ظاهر ساده تری دارند و کمتر به جزئیات بصری شون پرداخته میشه، معمولا برای طراحی ظاهر Windows Forms وقت کمتری صرف می کنید و در بخش کد نویسی بیشتر مشغول می شوید. طبعا در WPF که برای هر تغییر ظاهری انعطاف پذیری زیادی داره می توانید ساعت ها صرف ویرایش ظاهر یک کنترل بکنید. معنی اش این نیست که حتما اینکار رو می کنید اما عموما اونقدر که در WPF برای ظاهر واسط کاربری وقت صرف می کنید در Windows Forms نمی کنید.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
طراحی و توسعه نرم افزار یک روال کلی ئه که کد نویسی و طراحی ظاهر برنامه جزئی از اونه، در مجموع برای توسعه یک نرم افزار در WPF زمان کمتری مورد نیاز ئه.
فرضا به این دلیل که برای یکسری تغییرات ظاهری ساده که در چندین فرم و کنترل تکرار می شوند لازم نیست تک تک مشخصه ها تنظیم بشه، کد نویسی بشه یا کلاس سازی بشه و ...
کار هایی است که Style و Template از پسشون برمیان و به راحتی روی چندین کنترل هم اعمال میشن، Style ها از پروژه های دیگه کپی میشن و ...
اما از اونجایی که فرم های Windows Forms عموما ظاهر ساده تری دارند و کمتر به جزئیات بصری شون پرداخته میشه، معمولا برای طراحی ظاهر Windows Forms وقت کمتری صرف می کنید و در بخش کد نویسی بیشتر مشغول می شوید. طبعا در WPF که برای هر تغییر ظاهری انعطاف پذیری زیادی داره می توانید ساعت ها صرف ویرایش ظاهر یک کنترل بکنید. معنی اش این نیست که حتما اینکار رو می کنید اما عموما اونقدر که در WPF برای ظاهر واسط کاربری وقت صرف می کنید در Windows Forms نمی کنید.

خیلی ممنون استاد .
پس از این لحاظ میگین طول میکشه که میشه روی طراحی کنترل های wpf وقت بیشتری صرف کرد تا زیباتر اون را ساخت .
من از لحاظی میگم که هر دو کنترل (در winform و wpf) را از لحاظ ظاهری شبیه هم باشن .
پس جمله ی من که گفته بودم "سرعت بیشتر و صرف زمان کمتر برای طراحی ظاهر کاربری دلخواه" ، از این دیدگاه ، درسته دیگه .
 

the_king

مدیرکل انجمن
من از لحاظی میگم که هر دو کنترل (در winform و wpf) را از لحاظ ظاهری شبیه هم باشن .
پس جمله ی من که گفته بودم "سرعت بیشتر و صرف زمان کمتر برای طراحی ظاهر کاربری دلخواه" ، از این دیدگاه ، درسته دیگه .
ظاهر شبیه هم شرایط مختلفی داره. بستگی به این داره که چقدر جزئیات داره، چقدر برای قابلیت های پلتفرم چالش داره، چقدر از حالت پیشفرض ظاهری در اون پلتفرم فاصله داره و ...
ممکنه طراحی اون ظاهر مشابه در WPF مشکل تر باشه یا در Windows Forms. اونقدر پارامتر های تاثیر گذار هست که نمیشه صرفا با مبنا قرار دادن اینکه ظاهرشون شبیه به هم ئه، قضاوت کرد کدوم سریعتر طراحی میشه.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
سلامی مجدد استاد .
خیلی ممنون استاد از جواب های قبلی تون .

استاد ، همونطور که دیشب در جریان اون مطلب زیر و پرسش ای که اون استارتر تاپیک مطرح کردن ، هستین :

اجرای دستورات در ResourceDictoinery

من طبق چیزهایی که شما گفتید ، مراحل را انجام دادم (که پروژه ای که ویرایشاتی که روش انجام دادم را در زیر پیوست میکنم) ، هر چند ارورهاش برطرف شد و بدون خطا اجرا میشه اما اون متدِ WinMove (همون متد SomeAction ای که شما نوشته بودین) ، اجرا نمیشه .
اگه مطالبی که شما گفته بودین را درست متوجه شده باشم ، ظاهرا نباید ویرایشاتی که انجام دادم ، اشکالی داشته باشه . پس مشکل از کجاست؟

این هم بگم که اون شخصی که اون سئوال را در اون انجمن و در اون تاپیک پرسیده بود ، من نیستم (نام ام هم اینجا و اونجا ، همینی هه که اینجا هست) . ولی سئوال اش جالب بود و دیدم کاربردی هه و بعدا هم همچین سئوالی برای من هم میشه ، پیگیرش هستم .

یه کم روش راحت تری برای انجام این کار وجود نداره تا با روش آسون تر این مسلئه را حل کنیم؟
مثلا برای اون border ، یه نام ای در نظر بگیریم و از درون اون کنترل Window ای که استایل را براش بکار میبریم ، یعنی Window ای که کد زیر را براش بکار بردیم :

کد:
<Window x:Class="ProjectList.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:ProjectList"
        mc:Ignorable="d" WindowStartupLocation="CenterScreen"
        Title="MainWindow" Height="450" Width="800" Style="{DynamicResource MainWindow}">
    <Grid>
       
    </Grid>
</Window>

از درون این Window ، بتونیم برای اون border ، رویداد تعریف کنیم (رویدادمون را متصل کنیم) ؟

---------------------------------------

بعد اینکه چجوری میشه برای کنترلی که استایل و تمپلیت خاصی که براش تعریف کردیم ، به همون شکل ای که استایل و تمپلیت ای که براش تعریف کردیم (و شکل اش تغییر کرد) (حالا این استایل و تمپلیت را در یک Resource یا بصورت مستقیم روی خود کنترل بکار برده باشیم) ، اون کنترل را به winform انتقال بدیم جوری که استایل و تمپلیت هایی که برای اون کنترل در wpf اِعمال کرده بودیم ، در winform هم اِعمال بشن؟
راهی داره یا فقط باید یک user control جدیدی در wpf بسازیم و این کارها را انجام بدیم و به winform منتقل کنیم؟
تشکر استاد :rose:
 

پیوست ها

  • ProjectList.rar
    301 کیلوبایت · بازدیدها: 1

the_king

مدیرکل انجمن
اگه مطالبی که شما گفته بودین را درست متوجه شده باشم ، ظاهرا نباید ویرایشاتی که انجام دادم ، اشکالی داشته باشه . پس مشکل از کجاست؟
مشکل از اینجا است که شما روی اون Border که در "Grid.Row="0 قرار داره یک Grid دیگه قرار دادید، طبعا Grid رخداد MouseDown رو مدیریت می کنه و Border با خبر نمیشه.
می توانید برای Grid ئه "IsHitTestVisible="False رو بنویسید تا شفاف عمل کنه و Border رخداد رو دریافت کنه، اما اصولا شما باید برای Grid بالایی رخداد رو مدیریت می کردید، نه در Border زیرش.

یه کم روش راحت تری برای انجام این کار وجود نداره تا با روش آسون تر این مسلئه را حل کنیم؟
مثلا برای اون border ، یه نام ای در نظر بگیریم و از درون اون کنترل Window ای که استایل را براش بکار میبریم ، یعنی Window ای که کد زیر را براش بکار بردیم :

کد:
<Window x:Class="ProjectList.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:ProjectList"
        mc:Ignorable="d" WindowStartupLocation="CenterScreen"
        Title="MainWindow" Height="450" Width="800" Style="{DynamicResource MainWindow}">
    <Grid>
      
    </Grid>
</Window>

از درون این Window ، بتونیم برای اون border ، رویداد تعریف کنیم (رویدادمون را متصل کنیم) ؟
قبلا در مورد یکتا بودن و نبودن اسامی و محدوده ای که اون اسامی قابل استفاده هستند صحبت کرده ایم.

بعد اینکه چجوری میشه برای کنترلی که استایل و تمپلیت خاصی که براش تعریف کردیم ، به همون شکل ای که استایل و تمپلیت ای که براش تعریف کردیم (و شکل اش تغییر کرد) (حالا این استایل و تمپلیت را در یک Resource یا بصورت مستقیم روی خود کنترل بکار برده باشیم) ، اون کنترل را به winform انتقال بدیم جوری که استایل و تمپلیت هایی که برای اون کنترل در wpf اِعمال کرده بودیم ، در winform هم اِعمال بشن؟
راهی داره یا فقط باید یک user control جدیدی در wpf بسازیم و این کارها را انجام بدیم و به winform منتقل کنیم؟
Windows Forms دخالتی در رندر WPF نداره، هر روالی که موقع فراخوانی کنترل در WPF اجرا بشه در میزبان Windows Forms هم اجرا میشه و هر روالی که موقع فراخوانی کنترل در WPF اجرا نشه در میزبان Windows Forms هم اجرا نمیشه.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
مشکل از اینجا است که شما روی اون Border که در "Grid.Row="0 قرار داره یک Grid دیگه قرار دادید، طبعا Grid رخداد MouseDown رو مدیریت می کنه و Border با خبر نمیشه.
می توانید برای Grid ئه "IsHitTestVisible="False رو بنویسید تا شفاف عمل کنه و Border رخداد رو دریافت کنه، اما اصولا شما باید برای Grid بالایی رخداد رو مدیریت می کردید، نه در Border زیرش.


قبلا در مورد یکتا بودن و نبودن اسامی و محدوده ای که اون اسامی قابل استفاده هستند صحبت کرده ایم.


Windows Forms دخالتی در رندر WPF نداره، هر روالی که موقع فراخوانی کنترل در WPF اجرا بشه در میزبان Windows Forms هم اجرا میشه و هر روالی که موقع فراخوانی کنترل در WPF اجرا نشه در میزبان Windows Forms هم اجرا نمیشه.

خیلی ممنون استاد .
استاد ، درست کردم و در پست زیر فرستادم :

اجرای دستورات در ResourceDictoinery

اما الان که تست کردم ، دیدم زمان طراحی ، کنترل ها را نشون نمیده . چرا؟
مثلا وقتی از toolbox ، یه کنترل (مثلا button) را توی فرم اصلی درگ میکنیم ، کدهای xaml اضافه میشه اما خود دکمه را نشون نمیده . چرا؟

-----------------------------

بعد اینکه در پست زیر :

اجرای دستورات در ResourceDictoinery

طرف ، در اون پروژه ای که داد ، کلاس WindowAttach در کجا به پروژه اش معرفی کرد تا ازش استفاده کنه؟ هر چی گشتم نه در کد xaml و نه در سی شارپ اش ، چیزی در این رابطه پیدا نکردم .
همچنین در فایل WindowsStyle.xaml اش ، کد x:Class را با مقدار ProjectList.WindowTemplate تعریف کرد که این کلاس WindowTemplate را من نتونستم در پروژه پیدا کنم .
این قضایا را یه کم توضیح میدین؟
ممنون
 

the_king

مدیرکل انجمن
خیلی ممنون استاد .
استاد ، درست کردم و در پست زیر فرستادم :

اجرای دستورات در ResourceDictoinery

اما الان که تست کردم ، دیدم زمان طراحی ، کنترل ها را نشون نمیده . چرا؟
مثلا وقتی از toolbox ، یه کنترل (مثلا button) را توی فرم اصلی درگ میکنیم ، کدهای xaml اضافه میشه اما خود دکمه را نشون نمیده . چرا؟
من صرفا در این سایت فعالیت مستمر دارم، اون تاپیک هم متعلق به من نیست که بخوام گفتگو هاش رو پیگیری کنم.

بعد اینکه در پست زیر :

اجرای دستورات در ResourceDictoinery

طرف ، در اون پروژه ای که داد ، کلاس WindowAttach در کجا به پروژه اش معرفی کرد تا ازش استفاده کنه؟ هر چی گشتم نه در کد xaml و نه در سی شارپ اش ، چیزی در این رابطه پیدا نکردم .
یک کلاس به نام WindowAttach نوشته که DependencyProperty جدیدی معرفی می کنه با عنوان مشخصه IsDragElement و در Grid اش هم اون مشخصه رو True کرده که این True شدن منجر به فراخوانی OnIsDragElementChanged میشه و برای اون کنترل متد DragElement_MouseLeftButtonDown رو متصل میکنه به MouseLeftButtonDown.
عملا مثل اینه که خودتون MouseLeftButtonDown اون Grid رو وصل کنید به یک متد که DragMove رو فراخوانی کنه.

همچنین در فایل WindowsStyle.xaml اش ، کد x:Class را با مقدار ProjectList.WindowTemplate تعریف کرد که این کلاس WindowTemplate را من نتونستم در پروژه پیدا کنم .
این قضایا را یه کم توضیح میدین؟
ممنون
ازش استفاده ای نشده، برای همینه که کلاسش نیست. در WindowStyles.xaml به هیچ متدی اشاره نشده که بخواد در کلاسی به نام ProjectList.WindowTemplate دنبالش بگرده.
بجای اینکار در Resources درون WindowStyle.cs یک روال اختصاصی برای Grid ای با نام Part_gridTitle اضافه کرده. یعنی وقتی اون WindowStyle میخواد اعمال بشه دنبال Grid ای با نام Part_gridTitle میگرده تا MouseDown اش رو متصل کنه به متدی که DragMove رو فراخوانی می کنه.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
من صرفا در این سایت فعالیت مستمر دارم، اون تاپیک هم متعلق به من نیست که بخوام گفتگو هاش رو پیگیری کنم.

بله . ببخشید استاد .
در زیر ، پروژه را پیوست کردم .

یک کلاس به نام WindowAttach نوشته که DependencyProperty جدیدی معرفی می کنه با عنوان مشخصه IsDragElement و در Grid اش هم اون مشخصه رو True کرده که این True شدن منجر به فراخوانی OnIsDragElementChanged میشه و برای اون کنترل متد DragElement_MouseLeftButtonDown رو متصل میکنه به MouseLeftButtonDown.
عملا مثل اینه که خودتون MouseLeftButtonDown اون Grid رو وصل کنید به یک متد که DragMove رو فراخوانی کنه.


ازش استفاده ای نشده، برای همینه که کلاسش نیست. در WindowStyles.xaml به هیچ متدی اشاره نشده که بخواد در کلاسی به نام ProjectList.WindowTemplate دنبالش بگرده.
بجای اینکار در Resources درون WindowStyle.cs یک روال اختصاصی برای Grid ای با نام Part_gridTitle اضافه کرده. یعنی وقتی اون WindowStyle میخواد اعمال بشه دنبال Grid ای با نام Part_gridTitle میگرده تا MouseDown اش رو متصل کنه به متدی که DragMove رو فراخوانی می کنه.

ممنون استاد .
آها ، یعنی window ای که برای اون طرف ، نام اش MainWindow2.xaml هست؟
یعنی اون نام MainWindow.xaml نیست؟
پس چرا MainWindow.xaml را با اندکی کدهای WindowStyle.xaml را هم تغییر داد!
و مهمتر اینکه در app.xaml ، همون MainWindow.xaml اجرا میشد و تغییری نداد . یعنی ویندوز MainWindow2.xaml که مربوط به کدهاشه را اجرا نکرد و وقتی اجرا کنیم ، ارور میده .
بله ، حالا که اصلا کدهای style و template اش را مستقیما در همون فایل MainWindow2.xaml نوشت ، بجای dependency property ، مستقیما میتونست از رویداد (ی که گفتین) استفاده کنه .
 

پیوست ها

  • ProjectList.rar
    301.6 کیلوبایت · بازدیدها: 0

the_king

مدیرکل انجمن
ممنون استاد .
آها ، یعنی window ای که برای اون طرف ، نام اش MainWindow2.xaml هست؟
دو تا پنجره است دیگه، هر دو شون هم به طریقی DragMove رو فراخوانی می کنند. برای اتصال متد به رخداد هم یکی اش از روتینی که اختصاصا برای Part_gridTitle در WindowStyle نوشته شده استفاده میکنه و اون یکی بجای Part_gridTitle از WindowAttach.IsDragElement استفاده میکنه.
یعنی اون نام MainWindow.xaml نیست؟
کد پروژه رو که دارید، در کد مشخص ئه.
پس چرا MainWindow.xaml را با اندکی کدهای WindowStyle.xaml را هم تغییر داد!
روتینی که برای Part_gridTitle نوشته جدید ئه دیگه. بدون ویرایش که Part_gridTitle اضافه نمیشد و تاثیر نمیذاشت.
و مهمتر اینکه در app.xaml ، همون MainWindow.xaml اجرا میشد و تغییری نداد . یعنی ویندوز MainWindow2.xaml که مربوط به کدهاشه را اجرا نکرد و وقتی اجرا کنیم ، ارور میده .
خطا میده چون در تعریف ControlTemplate اش "TargetType="local:WindowStyle داره در حالی که پنجره اش WindowStyle نیست. اون پنجره MainWindow2 یک تگ <Window> ئه، مثل پنجره MainWindow یک تگ <local:WindowStyle> نیست و باید اون سطر به <"ControlTemplate TargetType="Window> تغییر کنه.
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
خیلی ممنون استاد .
استاد ، درست کردم و در پست زیر فرستادم :

اجرای دستورات در ResourceDictoinery

اما الان که تست کردم ، دیدم زمان طراحی ، کنترل ها را نشون نمیده . چرا؟
مثلا وقتی از toolbox ، یه کنترل (مثلا button) را توی فرم اصلی درگ میکنیم ، کدهای xaml اضافه میشه اما خود دکمه را نشون نمیده . چرا؟

ContentPresenter ، اضافه نشده بود .


دو تا پنجره است دیگه، هر دو شون هم به طریقی DragMove رو فراخوانی می کنند. برای اتصال متد به رخداد هم یکی اش از روتینی که اختصاصا برای Part_gridTitle در WindowStyle نوشته شده استفاده میکنه و اون یکی بجای Part_gridTitle از WindowAttach.IsDragElement استفاده میکنه.

کد پروژه رو که دارید، در کد مشخص ئه.

روتینی که برای Part_gridTitle نوشته جدید ئه دیگه. بدون ویرایش که Part_gridTitle اضافه نمیشد و تاثیر نمیذاشت.

خطا میده چون در تعریف ControlTemplate اش "TargetType="local:WindowStyle داره در حالی که پنجره اش WindowStyle نیست. اون پنجره MainWindow2 یک تگ <Window> ئه، مثل پنجره MainWindow یک تگ <local:WindowStyle> نیست و باید اون سطر به <"ControlTemplate TargetType="Window> تغییر کنه.

آها ممنون استاد .

استاد ، میگم در کدی که دادید ، کلا بجاش نمیشه کاری کرد که مثل پنجره ی اصلی پروژه مون که وقتی نام رویدادها را مینویسیم ، در اینتلیسنس ، راهنمایی میکنه و گزینه ی "New Event Handler" را میاره و وقتی این گزینه را میزنیم ، در کدهای سی شارپ ، هندلرِ این رویداد را اضافه میکنه .
نمیشه در فایل WindowStyle.xaml (همون ResourceDictionary) هم برای کنترل ها ، یه کاری کرد که به این روش عمل کنه؟
تشکر استاد :rose:
 

the_king

مدیرکل انجمن
استاد ، میگم در کدی که دادید ، کلا بجاش نمیشه کاری کرد که مثل پنجره ی اصلی پروژه مون که وقتی نام رویدادها را مینویسیم ، در اینتلیسنس ، راهنمایی میکنه و گزینه ی "New Event Handler" را میاره و وقتی این گزینه را میزنیم ، در کدهای سی شارپ ، هندلرِ این رویداد را اضافه میکنه .
نمیشه در فایل WindowStyle.xaml (همون ResourceDictionary) هم برای کنترل ها ، یه کاری کرد که به این روش عمل کنه؟
راهش اینه که طبق توضیحاتی که داده بودم عمل کنید، قرار بود وقتی فایل WindowStyles.xaml هست، فایل cs اش اسمش چی باشه؟ WindowTemplate.xaml.cs؟
بیخودی و بی دلیل نگفتم اسم فایل cs همنام باشه. طبعا وقتی شما اصول سازگاری با Designer ویژوال استدیو رو رعایت نکنید، نباید انتظار داشته باشید که Designer بیاد داخل فایل cs دیگری با اسم متفرقه WindowTemplate.xaml.cs کد خودکار درج کنه. ممکنه صد تا فایل cs داشته باشید که همه شون partial class WindowTemplate باشند، Designer نمیتونه همینطوری یک فایل cs رو انتخاب کنه.
میبینه WindowStyles.xaml.cs ای نیست و میفهمه درج کد خودکار میسر نیست و برای همین Intellisense عمل نمی کنه.

البته می توانید خودتون یک افزونه برای Intellisense طراحی کنید و برای هر موردی که خواستید روال جدید بنویسید.
Implementing Custom XAML Intellisense VS2017 Extension
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
راهش اینه که طبق توضیحاتی که داده بودم عمل کنید، قرار بود وقتی فایل WindowStyles.xaml هست، فایل cs اش اسمش چی باشه؟ WindowTemplate.xaml.cs؟
بیخودی و بی دلیل نگفتم اسم فایل cs همنام باشه. طبعا وقتی شما اصول سازگاری با Designer ویژوال استدیو رو رعایت نکنید، نباید انتظار داشته باشید که Designer بیاد داخل فایل cs دیگری با اسم متفرقه WindowTemplate.xaml.cs کد خودکار درج کنه. ممکنه صد تا فایل cs داشته باشید که همه شون partial class WindowTemplate باشند، Designer نمیتونه همینطوری یک فایل cs رو انتخاب کنه.
میبینه WindowStyles.xaml.cs ای نیست و میفهمه درج کد خودکار میسر نیست و برای همین Intellisense عمل نمی کنه.

البته می توانید خودتون یک افزونه برای Intellisense طراحی کنید و برای هر موردی که خواستید روال جدید بنویسید.
Implementing Custom XAML Intellisense VS2017 Extension

بله درست شد استاد . خیلی ممنون . :rose:
استاد ، پس با این کار ، نیازی به اون کد :

کد:
<Border.Style>
                                <Style TargetType="Border">
                                    <EventSetter Event="MouseDown" Handler="SomeAction"/>
                                </Style>
                            </Border.Style>

که داده بودید نیست . چون مستقیما میشه برای هر کنترلی ، رویداد تعریف کرد دیگه . درسته؟

------------------------------------

الان مهمترینکدهایی که برای این قضیه مهم هستن تا هندلرهایی که در کلاسی که مینویسیم را و اون هندلر را برای اون رویداد از کنترل ها میخوایم در فایل xaml ای ست کنیم ، اینه که کدهای زیر :

کد:
xmlns:local="clr-namespace:ProjectList"
    x:Class="ProjectList.WindowTemplate"

را مشخص کنیم ؟ درسته؟
که فضای نام اولی (فضای نام local) را مقدار فضای نام سی شارپ ای که میخوایم ازش استفاده کنیم و در x:Class هم که نام کلاسی که اون هندلر را در اونجا مینویسیم هست .
همچنین نام فایل xaml مون باید هم نام با فایل cs مون (که گفتید) باشه . درستن؟
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
Windows Forms دخالتی در رندر WPF نداره، هر روالی که موقع فراخوانی کنترل در WPF اجرا بشه در میزبان Windows Forms هم اجرا میشه و هر روالی که موقع فراخوانی کنترل در WPF اجرا نشه در میزبان Windows Forms هم اجرا نمیشه.

ممنون استاد .
بله میدونم .
منظورم اینه که در کد نویسی چی کار کنیم تا شکل کنترل را تغییر داده به جای دیگه (مثل windows form) ، منتقل کنیم؟

بذارید بهتر توضیح بدم :
مثلا من برای انتقال و استفاده از سی شارپ و کنترل هاش ، در زبان ها و محیط های دیگه (مثلا وقتی میخوام از توی اتوپلی ، سی شارپ و دات نت را استفاده کنم) ، در سی شارپ ، یه dll درست میکنم .
حالا مثلا وقتی بخوام button ئه شخصی سازی شده را در اتوپلی استفاده کنم ، اول میام یه کلاسی میسازم که از کلاس button ارث بری کرده (مثلا کلاسی بنام CustomButton میسازم) و بعد متد OnPaint اش را اورراید میکنم و شکل دلخواهم را رسم میکنم .
حالا این کلاس CustomButton را به اتوپلی منتقل میکنم و با فراخونی متدی از سی شارپ که درست کردم ، در بدنه ی متد اش که در سی شارپ نوشتم ، از این کلاس شی میسازم و استفاده میکنم .


حالا برای اینکه مثلا کنترلی در wpf که template ای براش توسط کدهای xaml بکار رفته شده (و تغییر شکل داده شده) را از wpf به windows form منتقل و توسط کنترل ElementHost ، از این کنترل تغییر شکل یافته استفاده کنیم ، چه مراحلی را باید طی کنیم؟
آیا باید کلاسی بنویسیم که مثلا در متد سازنده اش ، کدهای فایل xaml (که شامل template برای اون کنترل بودن) را لود کنه ؟
چون windows form که نمیتونه از کدهای xaml برای توصیف کنترل هاش استفاده کنه (یعنی کدهای xaml در wpf که برای windows form ناشناخته هست) .
کلا باید چه مراحلی را طی کنیم؟
و هم اینکه آیا برای این انتقال از wpf به windows form ، فقط باید dll بسازیم یا چون این انتقال در بین دات نت (و هر دو از زبان سی شارپ استفاده میکنن) ، بجز ساخت dll ، راه دیگه ای هم وجود داره؟
تشکر استاد . :rose:
 

the_king

مدیرکل انجمن
بله درست شد استاد . خیلی ممنون . :rose:
استاد ، پس با این کار ، نیازی به اون کد :

کد:
<Border.Style>
                                <Style TargetType="Border">
                                    <EventSetter Event="MouseDown" Handler="SomeAction"/>
                                </Style>
                            </Border.Style>

که داده بودید نیست . چون مستقیما میشه برای هر کنترلی ، رویداد تعریف کرد دیگه . درسته؟
برای این مثال که Border رو در ControlTemplate میسازید بله، چه مستقیم در Border و چه در Style اش، فرقی در نتیجه نداره. البته در حالت کلی EventSetter مواقعی که یک Style عمومی رو مستقل از ControlTemplate تعریف می کنید و نمیخواهید برای هر Border مجزا MouseDown رو متصل کنید کاربرد داره، مثلا اگر در Resources یک Window یک Style عمومی برای همه Border ها بسازید.

الان مهمترینکدهایی که برای این قضیه مهم هستن تا هندلرهایی که در کلاسی که مینویسیم را و اون هندلر را برای اون رویداد از کنترل ها میخوایم در فایل xaml ای ست کنیم ، اینه که کدهای زیر :

کد:
xmlns:local="clr-namespace:ProjectList"
    x:Class="ProjectList.WindowTemplate"
به نظر من درجه بندی اهمیت نداره، همه فضا های نام به یک اندازه مهم هستند. اما فضای نام ای که استفاده نشه طبعا اضافی است و بی تاثیر.
xmlns پیشفرض هم اهمیت داره. اما اگر از local در کد XAML استفاده نشده درج شدن و نشدن xmlns:local تاثیری نداره.
و با اون x:Class در واقع یک کلاس partial رو ایجاد می کنید، حتی اگه در جای دیگری کد #C این کلاس رو ننوشته باشید همین x:Class برای ایجاد شدنش کفایت کرده.
Code-Behind and XAML - WPF
 

جدیدترین ارسال ها

بالا