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

[SajjadKhati]

در کد اول شما رسم داخل grdConvertToBmp رو تبدیل کرده اید به یک Brush. فقط رسم داخل grdConvertToBmp ئه، دیگه کاری به موقعیت grdConvertToBmp در Window نداره.
حالا این Brush رو در کادری که نمایش بدهید در اون فضا رسم میشه، کاری نداره که grdConvertToBmp ئه کجا بود و چه Margin ای داشت.

خیلی ممنون استاد .
خوب فرقش چیه؟
اینکه تبدیل کنم به براش و از براش رندر بگیرم یا اینکه مستقیما در RenderedTargetBitmap رندر بگیرم؟
در واقع ، چه توی Brush بریزم یا توی RenderedTargetBitmap ، بالاخره در هر دو ، شامل توصیفاتِ رسم اش خواهد بود دیگه .
من تفاوت این دو حالت را متوجه نشدم .

چرا، هست، انتظار داشتید بدون مطالعه مطالب مفصل اش دقیق متوجه بشوید؟ اگر دقیق متوجه نمی شوید احتمالا به این خاطر ئه که در موردش دقیق مطالعه نمی کنید.
Resolution Independent با معیار های WPF که قطعا رعایت شده و در Windows Forms هم که کلا سیستم Resolution Independent ای نیست با توجه به تنظیم پیشفرض Form. AutoScaleMode (در واقع برای ContainerControl ها است) که روی Font تنظیم میشه، تا حدودی تغییر ابعاد خودکار رو انجام میده.
و این مساله هم که سیستم Resolution Independent هست یا نیست ارتباطی با موثر بودن و نبودن تنظیم dpi ویندوز برای نمایشگر نداره، اون یک ضریب نرم افزاری است که کاربر بتونه ابعاد اجزاء در همه سیستم ها رو بصورت هماهنگ بزرگتر یا کوچکتر کنه، تا بنا به نیازش نمایش درشت تر یا ریزتر باشه. طبعا هر سیستمی که به این تنظیم توجه نکنه یک نقص محسوب میشه. ربطی به این نداره که اون سیستم Resolution Independent ئه یا Resolution Dependent. اون ضریب باید موثر باشه.

معلومه که اصلا معنی Resolution Independent یا Resolution Dependent رو درک نکرده اید. در موردش بیشتر مطالعه کنید.

استاد یه لینک میدین که از اول (مبتدی) این قضیه ی Resolution Independent را توضیح داده باشه؟
من مقالاتی را که خوندم ، ربطش را به این قضیه متوجه نشدم . اون دو لینکی که قبلا بهتون داده بودم را خوندم و مطالب هاش را گفتم و پرسیدم ازتون ولی باز تفاوت این قضیه و اینکه کجاها با winform تفاوت داره و کجاها کاربرد داره را دقیق متوجه نشدم .
تشکر (بابت جواب پست بالا هم خیلی ممنون)

 

[the_king]

خیلی ممنون استاد .
خوب فرقش چیه؟

فرقش که رو که گفتم، جوابم رو نمی خونید؟ فرقش اینه که grdConvertToBmp موقعی که میخواد رسمش رو در RenderedTargetBitmap انجام بده همونکاری رو انجام میده که برای رسم عادی خودش انجام میده، یعنی در نظر میگیره که Margin و سایر موارد موثر در موقعیت رسم چه مقادیری دارند، اما Brush ای که از روی رسم داخل grdConvertToBmp ایجاد کرده اید فقط به رسم داخل grdConvertToBmp کار داره، Brush ئه کاری به این نداره که grdConvertToBmp ئه چه Margin ای داره و رسمش رو در چه موقعیتی انجام میده. Brush رو در هر جایی که رسم کنید محتویات Grid رو اونجا رسم می کنه، کاری نداره که Grid ئه کجاست، نمیخواد Grid ئه رو رسم کنه، میخواد محتویات Grid رو رسم کنه.

اینکه تبدیل کنم به براش و از براش رندر بگیرم یا اینکه مستقیما در RenderedTargetBitmap رندر بگیرم؟
در واقع ، چه توی Brush بریزم یا توی RenderedTargetBitmap ، بالاخره در هر دو ، شامل توصیفاتِ رسم اش خواهد بود دیگه .
من تفاوت این دو حالت را متوجه نشدم .

اشکالی نداره که متوجه نشوید، شما فرض کنید که توصیف داخل Grid با توصیف خود Grid که موقعیتی که Grid در اونجا انجام میشه هم شاملش هست یکی ئه، یعنی ...Grid> رو با توصیف داخل اون Grid یکی در نظر بگیرید، اتفاق بدی نمی افته. اما تفاوت رو که عملا می بینید. چه تفاوت اش رو با استدلال و چه بی استدلال متوجه بشوید خوبه، همینکه این اختلاف رو احساس می کنید که نتیجه رسم محتوای Grid توسط Brush که کاری به موقعیت Grid ئه نداره با نتیجه رسم خود Grid ئه که موقعیتی که در اون قرار داره متفاوت میشه و ظاهر رسم دو کد فرق می کنه کافیه. فرقش رو می بینید، صرفا دلیلش رو درک نمی کنید، اشکالی نداره، همینکه تفاوت اش رو بخاطر بسپارید خیلی خوبه.

استاد یه لینک میدین که از اول (مبتدی) این قضیه ی Resolution Independent را توضیح داده باشه؟
من مقالاتی را که خوندم ، ربطش را به این قضیه متوجه نشدم . اون دو لینکی که قبلا بهتون داده بودم را خوندم و مطالب هاش را گفتم و پرسیدم ازتون ولی باز تفاوت این قضیه و اینکه کجاها با winform تفاوت داره و کجاها کاربرد داره را دقیق متوجه نشدم .
تشکر (بابت جواب پست بالا هم خیلی ممنون)

شما اگر بخواهید Resolution Independent رو در WPF درک کنید طبعا باید در مورد WPF و Resolution Independent در WPF مطالعه کنید، اما اگر بخواهید تفاوت این دو تا سیستم کاملا متفاوت رو درک کنید دیگه مطالعه فقط در مورد WPF کافی نیست. باید اول هر دوشون رو خوب بشناسید. شما که الان نمی خواهید در مورد تفاوت این دو تا سیستم مقاله تحقیقی بنویسید، اگر بخواهید اینکار رو بکنید باید مطالب زیادی رو در مورد رسم در ویندوز و معماری هر کدوم از این دو سیستم بخونید. اون بحث دیگری است.
این مثال تجربی که زده مطلب طولانی و یا فنی ای نیست اما چون با مثال عملی توضیح داده که چه پارامتر هایی رو باید در نظر میگرفته و چیکار کرده تا به جواب درست رسیده ارزش مطالعه رو داره :
http://manojtechnicalblog.blogspot.com/2012/12/is-wpf-really-resolution-independent.html

 

[SajjadKhati]

فرقش که رو که گفتم، جوابم رو نمی خونید؟ فرقش اینه که grdConvertToBmp موقعی که میخواد رسمش رو در RenderedTargetBitmap انجام بده همونکاری رو انجام میده که برای رسم عادی خودش انجام میده، یعنی در نظر میگیره که Margin و سایر موارد موثر در موقعیت رسم چه مقادیری دارند، اما Brush ای که از روی رسم داخل grdConvertToBmp ایجاد کرده اید فقط به رسم داخل grdConvertToBmp کار داره، Brush ئه کاری به این نداره که grdConvertToBmp ئه چه Margin ای داره و رسمش رو در چه موقعیتی انجام میده. Brush رو در هر جایی که رسم کنید محتویات Grid رو اونجا رسم می کنه، کاری نداره که Grid ئه کجاست، نمیخواد Grid ئه رو رسم کنه، میخواد محتویات Grid رو رسم کنه.


اشکالی نداره که متوجه نشوید، شما فرض کنید که توصیف داخل Grid با توصیف خود Grid که موقعیتی که Grid در اونجا انجام میشه هم شاملش هست یکی ئه، یعنی ...Grid> رو با توصیف داخل اون Grid یکی در نظر بگیرید، اتفاق بدی نمی افته. اما تفاوت رو که عملا می بینید. چه تفاوت اش رو با استدلال و چه بی استدلال متوجه بشوید خوبه، همینکه این اختلاف رو احساس می کنید که نتیجه رسم محتوای Grid توسط Brush که کاری به موقعیت Grid ئه نداره با نتیجه رسم خود Grid ئه که موقعیتی که در اون قرار داره متفاوت میشه و ظاهر رسم دو کد فرق می کنه کافیه. فرقش رو می بینید، صرفا دلیلش رو درک نمی کنید، اشکالی نداره، همینکه تفاوت اش رو بخاطر بسپارید خیلی خوبه.

خیلی ممنون استاد .
پس اگه بخوایم Margin را در نظر نگیره ، فقط راهش اینه که اون کنترلِ Visual را در یک Brush ای رسم کنیم و بعد بقیه ی کارهامون را انجام بدیم ؟ (یعنی بصورت مستقیم راهی نداره که در RenderedTargetBitmap استفاده کنیم دیگه) .

شما اگر بخواهید Resolution Independent رو در WPF درک کنید طبعا باید در مورد WPF و Resolution Independent در WPF مطالعه کنید، اما اگر بخواهید تفاوت این دو تا سیستم کاملا متفاوت رو درک کنید دیگه مطالعه فقط در مورد WPF کافی نیست. باید اول هر دوشون رو خوب بشناسید. شما که الان نمی خواهید در مورد تفاوت این دو تا سیستم مقاله تحقیقی بنویسید، اگر بخواهید اینکار رو بکنید باید مطالب زیادی رو در مورد رسم در ویندوز و معماری هر کدوم از این دو سیستم بخونید. اون بحث دیگری است.
این مثال تجربی که زده مطلب طولانی و یا فنی ای نیست اما چون با مثال عملی توضیح داده که چه پارامتر هایی رو باید در نظر میگرفته و چیکار کرده تا به جواب درست رسیده ارزش مطالعه رو داره :
http://manojtechnicalblog.blogspot.com/2012/12/is-wpf-really-resolution-independent.html

این را هم خوندم .
این هم مثل اون (خلاصه ی کلامش) میگه با تغییرDPI (همون PPI) ئه ویندوز ، اندازه ی پروژه ی wpf به همون نسبت کوچیک و بزرگ میشه .
که باز هم من مفهوم دقیق Resolution Independent را از توش متوجه نشدم . حالا بماند .
ممنون .

 

[the_king]

خیلی ممنون استاد .
پس اگه بخوایم Margin را در نظر نگیره ، فقط راهش اینه که اون کنترلِ Visual را در یک Brush ای رسم کنیم و بعد بقیه ی کارهامون را انجام بدیم ؟ (یعنی بصورت مستقیم راهی نداره که در RenderedTargetBitmap استفاده کنیم دیگه) .

RenderedTargetBitmap خودش که تصویر نداره، از RenderTargetBitmap همیشه بصورت مستقیم استفاده می کنید. واسطه هم نیست که بخواهید ازش استفاده بکنید یا نکنید، هم در کد اول و هم در کد دوم تون RenderTargetBitmap دارید که برای تبدیل رندر به تصویر استفاده شده. من نمیدونم برای هر کاری چند راه هست که بخواهم نظر بدم که فقط راهش اینه یا x راه دیگه هم هست. مساله اینه که RenderedTargetBitmap برای ساختن تصویر بر اساس رندر یک شیء ئه، جایگزین مشخص دیگه ای هم نداره. اگر قراره رندر شیء ای رو به تصویر تبدیل کنید RenderedTargetBitmap برای این منظور ئه. اگر نمی خواهید رندر ای رو به تصویر تبدیل کنید RenderedTargetBitmap شاید بدردتون نخوره.

این را هم خوندم .
این هم مثل اون (خلاصه ی کلامش) میگه با تغییرDPI (همون PPI) ئه ویندوز ، اندازه ی پروژه ی wpf به همون نسبت کوچیک و بزرگ میشه .
که باز هم من مفهوم دقیق Resolution Independent را از توش متوجه نشدم . حالا بماند .
ممنون .

خوندن تون با نخوندن تون چندان فرقی نداشت، چون صریحا در نتیجه گیری اش هم گفته نمایشگر 96ppi پنجره WPF رو در همون same size نمایشگر 192ppi نمایش داد.

In conclusion, we’ve seen that WPF really is resolution independent as long as Windows display properties scale factor settings are properly taken into account. What WPF Resolution Independence really means that two monitors set to their native resolution and which are accurately reporting their DPI settings to WPF will display the same WPF window at the exact same size. Under those conditions a monitor with 96 physical pixels per inch will display any WPF window at the same size as a monitor which has 192 physical pixels per inch.​

​

 

[SajjadKhati]

خیلی ممنون استاد .
آخر من که متوجه نشدم وابسته به ppi ئه یا اندازه ی مانیتور یا چی .

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

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

 

[the_king]

خیلی ممنون استاد .
آخر من که متوجه نشدم وابسته به ppi ئه یا اندازه ی مانیتور یا چی .

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

استاد ، اینکه از xaml در wpf استفاده شده ، ربطش به جدا بودن ui از منطق چیه؟

نگید منطق، بگید منطق تجاری. نمیشه تجاری رو خلاصه سازی یا حذف کرد. منطق = منطق تجاری نیست، همونطور که خط = خط استوا نیست.
در WPF جداسازی UI از منطق تجاری انجام شده. اگه بگید منطق یا logic خالی، میشه یک مفهوم عمومی که برای هر منطق ای باید صدق کنه.
اینجا فقط صحبت business logic ئه، انواع logic هایی مثل input logic و application logic و presentation logic هم داریم که نمیشه بجای هم بکار بردشون. باید صریحا بگید منطق تجاری وگرنه مفهوم جمله تون اشتباه ئه.
ربط این مساله که از XAML استفاده شده به جدا بودن UI از منطق تجاری در اینه که در WPF که قرار بوده واسط کاربری مستقل از منطق تجاری باشه و منطق تجاری رو با زبانی مثل #C پیاده سازی می کنیم، اما با #C میشد واسط کاربری رو هم توصیف کرد؟ خیر. همچین کاری رو نمیتونه انجام بده چون زبان توصیفی نیست. شما با #C می توانید یک چیزهایی رو توصیف کنید، مثلا Interface ای رو مثل ICollection رو توصیف می کنید، اما اون واسط کاربری نیست، واسط ای است که برای ارتباط بین اشیاء بکار می برید.

برای توصیف کردن واسط کاربری باید از زبان مناسب توصیف واسط کاربری استفاده کرد، بصورت متعارف این یعنی زبان های نشانه گذاری، مثلا XAML، نه یک زبان برنامه نویسی.
#C یک Programming Language ئه، نه Markup Language.
نمیشه واسط کاربری روی با #C توصیف کرد، چیزی که شما با #C برای ساختن واسط کاربری می نویسید توصیف نیست، کدی برنامه ای است که با اجرا شدنش اشیاء ای رو ایجاد می کنه، توصیف نمی کنه. همونطور که با Markup language ای مثل XAML نمیشه پیچیدگی های منطق تجاری رو پیاده سازی کرد. برای همینه که HTML که یک Markup Language ئه کافی نیست و نیاز به javascript ای پیدا می کنیم که یک زبان برنامه نویسی است.

در واقع بذارید این جوری بگم که خوب توی winform که از سی شارپ برای ui استفاده میشه ، بالاخره اونجا هم اگه کدهای سی شارپ را بنویسیم ، باعث میشه ظاهرش ساخته بشه . اما اینجا کدهای xaml را بنویسیم باعث میشه ظاهرش ساخته بشه . خوب هر دو زبان اند و فرق شون توی سینکس هست . بنابراین زبان نوشتنِ منطق از ui جدا باشه یا نباشه ، فرق خاصی نباید کنن . من آخر تفاوت و فواید جدا بودن زبان منطق از ui را متوجه نشدم .
تشکر

من متوجه شدم که به نظر شما فرق خاصی بین زبان های نشانه گذاری مثل HTML و زبان های برنامه نویسی مثل #C نیست و تفاوت خاصی بین شون قائل نیستید اما این صرفا به این خاطر عدم تسلط به موضوع ئه.
وقتی من به موضوعی مسلط نباشم نمی توانم در مورد نظرم بحث کنم. شما چند تا برنامه نویس با تجربه وب پیدا کنید و بهشون بگید به نظر شما HTML و Javascript (یا XAML و #C) هر دو زبان هستند و فرق خاصی با هم ندارند و فقط سینتکس شون متفاوت ئه، ببینید چطور واکنش نشون میدن. حتی ممکنه خیال کنند دارید سر به سرشان میذارید.
شما نظرتون رو اعلام می کنید و من هم می شنوم، اما دلیلی نداره که بخواهم سر نظرتون بحث کنم یا نظرتون رو تغییر بدم. باید در مورد شون مطالعه کنید.

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

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

 

[SajjadKhati]

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

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

مطالب اینهان :

مزایای WPF نسبت به Windows Form :


1) استفاده از XML در طراحی رابط کاربری :

- باعث جدا کردن طراحی رابط کاربری از منطق تجاری میشه .

فایده اش اینه که طراح رابط کاربری با برنامه نویسی منطق تجاری میتونه جدا از هم بصورت همزمان انجام بشه .


- قابلیت Content محور و تو در تو بودن XML ، باعث سادگی درک رابطه ی کدنویسی با رابط کاربری (که بصورت درختی هستند) میشه .


2) وسعت و عملکرد و خصوصیت و انعطاف پذیری بیشتر کنترل ها نسبت به WinForm


3) هر کنترلی را درون کنترل ContentControl میشه قرار داد بدون اینکه منطقِ کنترل ها تحت تاثیر قرار بگیره و بدون اینکه کنترلی را شخصی سازی کنیم با کمترین میزان کدنویسی . که یکی از عواملی هست که باعث میشه توسعه ی کنترل ها ، راحت بشه .


4) تغییر ظاهر کنترل ها به هر شکل دلخواه توسط Template ها بدون اینکه منطق کنترل تحت تاثیر قرار بگیره.

این ، یکی از مهم ترین قابلیت های WPF به شمار میره که باعث میشه نیاز به استفاده از کنترل ها و کمپوننت های شرکت های دیگه (مثل Telerik و ...) نشه یا بصورت چشمگیری کم بشه .


5) استفاده از افکت ها (مثل تار کردن و افکت های دیگه) برای کنترل ها .

قابلیت های متنوع و پیشرفته مثل تنظیم چرخش ، شفافیت ، Skew ، Command در کنترل ها و ... .


6) ایجاد تم و اسکین (Theme & Skin) توسط Style .


- در WinForm ، اندکی کدنویسی بیشتر و زمان بیشتری را برای نوشتن کد لازم داره.


7) انیمیشنی و متحرک کردن کنترل ها .


8) استفاده از Vector Graphic که باعث میشه با بزرگتر یا کوچیکتر شدنِ رسم شی گرافیک ، کیفیت رسم اش کمتر نشه و تغییری نکنه .


- WinForm ، از Raster Graphic برای رسم استفاده میکنه که با بزرگتر کردن ، باعث کم شدن کیفیت میشه .


9) از رابط کاربری DirectX برای ترسیمات و رندر استفاده میکنه که باعث میشه از کارت گرافیک برای رندر به کار گرفته بشه .


- WinForm از رابط GDI+ برای ترسیمات استفاده میکنه .


10) بصورت Resolution Independent و مستقل از ریزولیشن عمل میکنه .


11) Binding بهینه تر نسبت به WinForm



12) ایجاد اشیاء 3 بعدی

سیستم گرافیک 2 بعدی قویتر

سیستم پشتیبانی از چند رسانه ای (صوت و تصویر) قویتر

سیستم رویداد بهینه تر

سیستم پروپرتی بهتر

امنیت بیشتر

کارایی بهینه تر و قابل انعطاف تر

مهاجرت راحت تر به .Net Core

سیستم Resource بهینه و قویتر

پشتیبانی از کنترل های WinForm در WPF

استفاده از MVVM Pattern

استفاده از Microsoft Blend برای کمک در طراحی رابط کاربری

و ... .

 

[the_king]

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

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

مطالب اینهان :

مزایای WPF نسبت به Windows Form :


1) استفاده از XML در طراحی رابط کاربری :

- باعث جدا کردن طراحی رابط کاربری از منطق تجاری میشه .

فایده اش اینه که طراح رابط کاربری با برنامه نویسی منطق تجاری میتونه جدا از هم بصورت همزمان انجام بشه .


- قابلیت Content محور و تو در تو بودن XML ، باعث سادگی درک رابطه ی کدنویسی با رابط کاربری (که بصورت درختی هستند) میشه .


2) وسعت و عملکرد و خصوصیت و انعطاف پذیری بیشتر کنترل ها نسبت به WinForm


3) هر کنترلی را درون کنترل ContentControl میشه قرار داد بدون اینکه منطقِ کنترل ها تحت تاثیر قرار بگیره و بدون اینکه کنترلی را شخصی سازی کنیم با کمترین میزان کدنویسی . که یکی از عواملی هست که باعث میشه توسعه ی کنترل ها ، راحت بشه .


4) تغییر ظاهر کنترل ها به هر شکل دلخواه توسط Template ها بدون اینکه منطق کنترل تحت تاثیر قرار بگیره.

این ، یکی از مهم ترین قابلیت های WPF به شمار میره که باعث میشه نیاز به استفاده از کنترل ها و کمپوننت های شرکت های دیگه (مثل Telerik و ...) نشه یا بصورت چشمگیری کم بشه .


5) استفاده از افکت ها (مثل تار کردن و افکت های دیگه) برای کنترل ها .

قابلیت های متنوع و پیشرفته مثل تنظیم چرخش ، شفافیت ، Skew ، Command در کنترل ها و ... .


6) ایجاد تم و اسکین (Theme & Skin) توسط Style .


- در WinForm ، اندکی کدنویسی بیشتر و زمان بیشتری را برای نوشتن کد لازم داره.


7) انیمیشنی و متحرک کردن کنترل ها .


8) استفاده از Vector Graphic که باعث میشه با بزرگتر یا کوچیکتر شدنِ رسم شی گرافیک ، کیفیت رسم اش کمتر نشه و تغییری نکنه .


- WinForm ، از Raster Graphic برای رسم استفاده میکنه که با بزرگتر کردن ، باعث کم شدن کیفیت میشه .


9) از رابط کاربری DirectX برای ترسیمات و رندر استفاده میکنه که باعث میشه از کارت گرافیک برای رندر به کار گرفته بشه .


- WinForm از رابط GDI+ برای ترسیمات استفاده میکنه .


10) بصورت Resolution Independent و مستقل از ریزولیشن عمل میکنه .


11) Binding بهینه تر نسبت به WinForm



12) ایجاد اشیاء 3 بعدی

سیستم گرافیک 2 بعدی قویتر

سیستم پشتیبانی از چند رسانه ای (صوت و تصویر) قویتر

سیستم رویداد بهینه تر

سیستم پروپرتی بهتر

امنیت بیشتر

کارایی بهینه تر و قابل انعطاف تر

مهاجرت راحت تر به .Net Core

سیستم Resource بهینه و قویتر

پشتیبانی از کنترل های WinForm در WPF

استفاده از MVVM Pattern

استفاده از Microsoft Blend برای کمک در طراحی رابط کاربری

و ... .

مورد 1 تون رو به عنوان مزیت نوشته اید، استفاده از XML ویژگی است، نه مزیت. Windows Forms برای نگهداری Resource های پروژه و فرم ها از XML استفاده می کنه (فایل های resx.). که این نه مزیت ئه و نه عیب. ویژگی ئه. اینکه Windows Forms برای نگهداری Resource ها از XML استفاده می کنه رو در لیست مزایای Windows Forms نمی بینید چون استفاده کردن یا نکردن از XML مزیت یا عیب نیست.

مورد 2 هم مقایسه مشخصی بین فلان و بهمان نیست، یک کنترل x رو می توانید با کنترل مشابه y مقایسه کنید ولی نمی توانید هزاران کنترل یک پلتفرم رو با هزاران کنترل پلتفرم دیگه ای مقایسه کنید و نتیجه بگیرید.
هر کنترلی مشخصات و معایب و مزایایی داره که به طراحی خودش بستگی داره نه پلتفرم.

مورد 3 هم مزیت نسبت به چی است؟ شما در Windows Forms در هر کنترل ای که ContainerControl باشه (جزو ControlStyles ها است) می توانید هر تعداد کنترلی رو از هر نوعی اضافه کنید، پس تا اینجا فرقی نداره.
در ضمن این مساله که شما در ContentControl ئه کنترل هایی قرار بدهید، بخودی خود شخصی سازی بدون استفاده است. فرضا شما دو تا دکمه داخل ContentControl ئه قرار می دهید،
این دکمه ها وظیفه خاصی دارند؟ نه. ظاهر کنترل رو تغییر می دهید ولی عملکرد همونه که بود. برای کارآمد شدن شخصی سازی شما مجبور به کد نویسی هستید، همون چیزی که در Windows Forms هم هست.
در Windows Forms هم تغییر دادن ظاهر کنترل ها راحت ئه اما صرفا شخصی سازی رو در ظاهر کنترل نمی خواهیم، تغییر ظاهر همراه با تغییر عملکرد انجام میشه.

مورد 4 دو گروه مخاطب متفاوت داره، که قاطی شون کرده. برنامه نویسانی که از کمپوننت های آماده استفاده می کنند، حالا توانایی ساختن کمپوننت و کنترل های اختصاصی رو ندارند یا مایل به اینکار نیستند، به هر حال خودشون قصد ساختن کنترل ها رو ندارند. این گروه هم در Windows Forms و هم در WPF و هم در هر پلتفرم دیگری دنبال کنترل های آماده هستند، که هم از نظر تعداد و هم تنوع تعداد کنترل های Windows Forms بیشتر ئه.
این گروه در WPF هم خودشان کنترل هایی مشابه کنترل های Telerik را طراحی نخواهند کرد، برنامه نویسانی که در Windows Forms سراغ کنترل های آماده Telerik باشند در WPF هم همینکار رو می کنند، ساختن کنترل های پیشرفته و حرفه ای برای کسانی که تخصص اینکار رو ندارند دشوار ئه، در هر پلتفرمی که باشه.

مورد 9 و 12 ابهام خیلی زیادی داره، بهتر یا بهینه تر یعنی چی؟ معیار چیه؟ کدشون رو مقایسه کرده اید؟ پروسه های در حال اجرا رو مقایسه کرده اید؟ معماری شون رو مقایسه کرده اید؟
توان مصرفی شون رو مقایسه کرده اید؟ میزان حافظه مصرفی رو مقایسه کردید؟
چی اعدادی از چه پارامتر هایی مقایسه شده و نتیجه گرفته شده که بهینه تر یا بهتر شده؟ یعنی مثلا تعداد رویداد ها کمتر شده؟ یا سرعت واکنش به رویداد ها بیشتر ئه؟ یا حافظه کمتری مصرف میکنه؟ یا توان پردازنده کمتری لازم داره؟
اگر چیزی بهتر یا بهینه تر باشه باید جدول مقایسه ای باشه که با ارقام این مساله رو نشون بده.
این پست و نمونه کدش رو ببینید :
wpfvswinforms.rar
سوال: طراحی کامپوننت در WPF و استفاده در Windows Form

 

[SajjadKhati]

مورد 1 تون رو به عنوان مزیت نوشته اید، استفاده از XML ویژگی است، نه مزیت. Windows Forms برای نگهداری Resource های پروژه و فرم ها از XML استفاده می کنه (فایل های resx.). که این نه مزیت ئه و نه عیب. ویژگی ئه. اینکه Windows Forms برای نگهداری Resource ها از XML استفاده می کنه رو در لیست مزایای Windows Forms نمی بینید چون استفاده کردن یا نکردن از XML مزیت یا عیب نیست.

خیلی ممنون استاد .
پس عنوان را به "مزایا و ویژگی های WPF نسبت به Windows Form" تغییر دادم .

مورد 2 هم مقایسه مشخصی بین فلان و بهمان نیست، یک کنترل x رو می توانید با کنترل مشابه y مقایسه کنید ولی نمی توانید هزاران کنترل یک پلتفرم رو با هزاران کنترل پلتفرم دیگه ای مقایسه کنید و نتیجه بگیرید.
هر کنترلی مشخصات و معایب و مزایایی داره که به طراحی خودش بستگی داره نه پلتفرم.

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

بله میدونم هر کنترل مزایا و معایب را داره اما بصورت میانگین و کلی نسبت به کنترل های WinForm منظورم هست .
از تعداد کلاس های بیشتر گرفته (مثلا کلاس Freezable و همچنین تقسیم شدن و گسترش خیلی از کلاس ها به چندین کلاس و توسعه ی اونها مثلا کلاس Component و Control در WinForm به کلاس های Visual و UIElement و FrameworkElement و Control گسترش یافتن و همچنین گسترش بسیاری از کلاس های مربوط به المنت های دیگه چه Visual و ...) تا گسترش خصوصیات جدید (مثل OpacityMask و Effect و Skew و ...) تا قابلیت های جدیدشون مثل انیمیشن تا تعریف عملکرد جدید (مثال بجای Color از Brush استفاده شده) تا گسترش خود Brush ها به تعریف ویدئو و ... .
حالا نمیشه این همه توضیحات را موقع معرفی فقط برای یک پارامتر داد . ان شاء ا... اینها را فقط به صورت در قسمت اول میگم تا بعدا در قسمت های بعد ، آموزش هر کدوم از این ها را بصورت مجزا آموزش بدم .

البته توضیح دومی را به متن زیر تغییر دادم :
"2) وسعت و عملکرد و خصوصیت و انعطاف پذیری بیشتر کنترل ها و المنت ها و گرافیک ها و غیره نسبت به WinForm"

مورد 3 هم مزیت نسبت به چی است؟ شما در Windows Forms در هر کنترل ای که ContainerControl باشه (جزو ControlStyles ها است) می توانید هر تعداد کنترلی رو از هر نوعی اضافه کنید، پس تا اینجا فرقی نداره.

من دقیقا متوجه نشدم چه عضوی در ContainerControl ئه Windows Forms مد نظرتونه که میشه هر شی ای را بهش اضافه کرد . قطعا منظورتون پروپرتیِ Control.Controls در Windows Forms نباید باشه؟
به هر حال ، ContainerControl ی Windows Forms هم اگه این قابلیت را داشته باشن ، باز هم ContainerControl ها محدود به یه سری کنترل های بسیار محدودی هستند (مثل form و usercontrol و ...) . ولی گستردگی ContentControl ها در wpf ، شامل کنترل های بسیار گسترده تری میشه . باز هم ContentControl محدود به نوع کنترل نیست بلکه هر شی ای هست که میدونید .

در ضمن این مساله که شما در ContentControl ئه کنترل هایی قرار بدهید، بخودی خود شخصی سازی بدون استفاده است. فرضا شما دو تا دکمه داخل ContentControl ئه قرار می دهید،
این دکمه ها وظیفه خاصی دارند؟ نه. ظاهر کنترل رو تغییر می دهید ولی عملکرد همونه که بود. برای کارآمد شدن شخصی سازی شما مجبور به کد نویسی هستید، همون چیزی که در Windows Forms هم هست.
در Windows Forms هم تغییر دادن ظاهر کنترل ها راحت ئه اما صرفا شخصی سازی رو در ظاهر کنترل نمی خواهیم، تغییر ظاهر همراه با تغییر عملکرد انجام میشه.

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

همونطور که مستحضرید ، همین پروپرتی ، ContentControl.Content خیلی میتونه از ساخت template ها جلوگیری کنه و کاربر با کمترین کد بتونه به هدفش برسه برای تغییرات ظاهریِ اولیه (مثلا اضافه کردن Border و ...) .

مورد 4 دو گروه مخاطب متفاوت داره، که قاطی شون کرده. برنامه نویسانی که از کمپوننت های آماده استفاده می کنند، حالا توانایی ساختن کمپوننت و کنترل های اختصاصی رو ندارند یا مایل به اینکار نیستند، به هر حال خودشون قصد ساختن کنترل ها رو ندارند. این گروه هم در Windows Forms و هم در WPF و هم در هر پلتفرم دیگری دنبال کنترل های آماده هستند، که هم از نظر تعداد و هم تنوع تعداد کنترل های Windows Forms بیشتر ئه.
این گروه در WPF هم خودشان کنترل هایی مشابه کنترل های Telerik را طراحی نخواهند کرد، برنامه نویسانی که در Windows Forms سراغ کنترل های آماده Telerik باشند در WPF هم همینکار رو می کنند، ساختن کنترل های پیشرفته و حرفه ای برای کسانی که تخصص اینکار رو ندارند دشوار ئه، در هر پلتفرمی که باشه.

البته ، این برای آموزش wpf هست . آموزش هم شامل template ها میشه . بنابراین من به اون دسته از کاربرانی که از کمپوننت کار میکنن یا آموزشم را نمیبینن ، کاری ندارم . حالا در wpf از کمپوننت استفاده کنن یا نکنن (ملاکی برام نیست) .
برام ارائه ای این قابلیت template و آموزشش مهم هه .

مورد 9 و 12 ابهام خیلی زیادی داره، بهتر یا بهینه تر یعنی چی؟ معیار چیه؟ کدشون رو مقایسه کرده اید؟ پروسه های در حال اجرا رو مقایسه کرده اید؟ معماری شون رو مقایسه کرده اید؟
توان مصرفی شون رو مقایسه کرده اید؟ میزان حافظه مصرفی رو مقایسه کردید؟
چی اعدادی از چه پارامتر هایی مقایسه شده و نتیجه گرفته شده که بهینه تر یا بهتر شده؟ یعنی مثلا تعداد رویداد ها کمتر شده؟ یا سرعت واکنش به رویداد ها بیشتر ئه؟ یا حافظه کمتری مصرف میکنه؟ یا توان پردازنده کمتری لازم داره؟
اگر چیزی بهتر یا بهینه تر باشه باید جدول مقایسه ای باشه که با ارقام این مساله رو نشون بده.
این پست و نمونه کدش رو ببینید :
wpfvswinforms.rar
سوال: طراحی کامپوننت در WPF و استفاده در Windows Form

این قسمت فقط معرفی هه . معرفی هم کلیات هست . مثلا من میخوام موشک فینیکس را معرفی کنم برای کسایی که نمیدونن چیه ، میگم موشک قدرتمند راداری برای هواپیمای F14 هست که سرعت فلان قدر را داره در قسمت های بعد میام میام جزئیاتش را آموزش میدم و در اونجا کاربر متوجه میشه که در جلسه ی اول وقتی گفتیم قدرتمند هه ، این تمایز قدرتش با بقیه ی موشک ها چقدر هه و در چه پارامترهایی هه و عملکرد قطعات درونی اش هر کدوم به چه شکل هه .


این بخش 9 و 12 بصورت کلی هه . مثل بقیه ی موارد که گفتم هم قطعا بصورت کلی (و مبهم) بیان شد و بعدا در قسمت های بعدی آموزش هر کدومش داده میشه .
به هر حال ، توضیحات بیشتر اینکه :
- شماره ی 9 که به نظرم حداقل مبهم نیست (بیانش معلوم هه دیگه) .
- ایجاد اشیاء 3 بعدی که مشخصه .
- سیستم گرافیک 2 بعدی قویتر => یعنی مثلا سیستم رندر Vector Base ، چیزهایی مثل Effect ها و ...
- سیستم پشتیبانی از چند رسانه ای (صوت و تصویر) قویتر=> کلاس های MediaElement وMediaPlayer (حالا نمیدونم از کدکها و فرمت های بیشتری پشتیبانی میکنن یا نه)
- سیستم رویداد بهینه تر => مثل Routed Event
- البته توضیح "سیستم پروپرتی بهتر" را پاک میکنم چون به قول شما ویژگی هست .
- امنیت بیشتر => دقیق نمیدونم . توی لینک زیر دیدم نوشته (بخش 4) :

Winforms vs WPF | Learn The Top 6 Most Awesome Differences

- کارایی بهینه تر و قابل انعطاف تر => باز هم در لینک بالا (شماره 6) نوشته . همچنین سند زیر در مایکروسافت در این باره هست (همچنین کلاس هایی مثل Freezable که میشه اشیاهایی که از این کلاس ارث بری میکنن را برای قابلیت فقط خوندنی ست کرد تا کارایی شون افزایش پیدا کنه) :

Optimize app performance - WPF

- مهاجرت راحت تر به .Net Core => مستندات این هم در اینترنت هست .
- سیستم Resource بهینه و قویتر=> منظورم Resource های مربوط به فایل ها نیست . بلکه قابلیت تعریف Resource توسط پروپرتیِ FrameworkElement.Resources هست .
- پشتیبانی از کنترل های WinForm در WPF => هم که جزء ویژگی هست .
- استفاده از MVVM Pattern => این را هم باید حذف کنم استاد . درسته؟ چون MVVM همون قابلیت لایه بندی هست دیگه؟ مثل 3 لایه بودن در WinForm . اگه آره پس درWinForm هم میشه بصورت MVVM نوشت دیگه؟
- استفاده از Microsoft Blend برای کمک در طراحی رابط کاربری => هم که دیگه مشخصه .

تشکر استاد

 

[the_king]

خیلی ممنون استاد .
پس عنوان را به "مزایا و ویژگی های WPF نسبت به Windows Form" تغییر دادم .

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

بله میدونم هر کنترل مزایا و معایب را داره اما بصورت میانگین و کلی نسبت به کنترل های WinForm منظورم هست .

میانگین و کلی روی چه حساب و کتابی؟ همینجوری رو هوا؟
میانگین که معنی اش مشخص ئه، شما اگر هزار تا عدد داشته باشید، میانگین شون به همه اون هزار عدد وابسته است، فقط با در نظر گرفتن دو سه عدد به میانگین نمی رسید.
ارزیابی کلی تون بر اساس چی بوده؟ چطوری این نتیجه رو داده؟ این طرف چه مقداری داده و اون طرف چه مقداری داده که این نتیجه بدست اومده؟
شما که می توانید بصورت کلی کنترل های WPF رو با Windows Forms مقایسه کنید باید بدونید برای هر کدوم یک ملاک و مقداری داشته باشید.
بصورت میانگین و کلی، وسعت و عملکرد و خصوصیت و انعطاف پذیری کنترل های WPF براتون مشخص شده؟ چقدر ئه؟ بر اساس چیه؟ عدد ئه؟ درصد ئه؟ با 0 تا 10 مشخص شده؟

از تعداد کلاس های بیشتر گرفته (مثلا کلاس Freezable و همچنین تقسیم شدن و گسترش خیلی از کلاس ها به چندین کلاس و توسعه ی اونها مثلا کلاس Component و Control در WinForm به کلاس های Visual و UIElement و FrameworkElement و Control گسترش یافتن و همچنین گسترش بسیاری از کلاس های مربوط به المنت های دیگه چه Visual و ...) تا گسترش خصوصیات جدید (مثل OpacityMask و Effect و Skew و ...) تا قابلیت های جدیدشون مثل انیمیشن تا تعریف عملکرد جدید (مثال بجای Color از Brush استفاده شده) تا گسترش خود Brush ها به تعریف ویدئو و ... .

تعداد کلاس معیار کدوم نتیجه گیری شما است؟ از تعداد کلاس بیشتر چه نتیجه ای می گیرید؟ مثلا این دو تا مثال کنترل A و کنترل B رو مقایسه کنید و از بیشتر بودن تعداد کلاس ها نتیجه گیری کنید :

        public class A : Control
        {
        }

        public class BaseControl : Control
        {
        }

        public class WinControl : BaseControl
        {
        }

        public class VisualControl : WinControl
        {
        }
       
        public class B : VisualControl
        {
        }

البته توضیح دومی را به متن زیر تغییر دادم :
"2) وسعت و عملکرد و خصوصیت و انعطاف پذیری بیشتر کنترل ها و المنت ها و گرافیک ها و غیره نسبت به WinForm"

میل خودتونه، هر کسی رو که با اطلاعات اشتباه گمراه کنید گناهش به گردن شما است، نه من.

من دقیقا متوجه نشدم چه عضوی در ContainerControl ئه Windows Forms مد نظرتونه که میشه هر شی ای را بهش اضافه کرد . قطعا منظورتون پروپرتیِ Control.Controls در Windows Forms نباید باشه؟

لطفا قبل از اینکه به پاسخ های من جواب بدید بخونید ببینید چی نوشتم، "هر شیء ای" در جواب من بود که میگید مد نظر منه؟ شما در پست خودتون نوشته اید "3) هر کنترلی را درون کنترل ContentControl میشه قرار داد" یعنی گفته اید هر شیء ای رو میشه داخل ContentControl قرار داد؟ ToolTip به عنوان یک شیء رو میشه داخل ContentControl ئه Grid قرار داد؟
فرق بین هر شیء ای با شیء کنترل رو نمی دونید؟ در تمامی Control ها میشه داخل Controls شیء به عنوان فرزند قرار داد، اما اگر ContainerControl باشه کاربر میتونه موقع طراحی فرم داخلش کنترل قرار بده، مثل Panel و GroupBox و ...

به هر حال ، ContainerControl ی Windows Forms هم اگه این قابلیت را داشته باشن ، باز هم ContainerControl ها محدود به یه سری کنترل های بسیار محدودی هستند (مثل form و usercontrol و ...) . ولی گستردگی ContentControl ها در wpf ، شامل کنترل های بسیار گسترده تری میشه . باز هم ContentControl محدود به نوع کنترل نیست بلکه هر شی ای هست که میدونید .

بسیار محدود؟ تعداد کنترل های Windows Forms رو میدونید که میگید بسیار محدود؟ قبل از اینکه WPF رو با Windows Forms مقایسه کنید لازم نیست که Windows Forms رو بشناسید؟
لیست بسیار محدود کنترل هایی که میشه داخل ContainerControl قرار داد رو می توانید بنویسید؟

بله ، باهاشون میشه فقط ظاهر کنترل را تغییر داد . منطق کنترل را نمیشه . همونطور که میدونید ، اساسا توسط wpf نمیشه چندان منطق کنترل ها را بجز با کدنویسی تغییر داد (مثل winform که برای ساختن منطق جدید در کنترل ها ، کنترل ها را سفارشی کرد) و wpf هم ساخته نشده تا کاربر راحت تر بتونه منطق کنترل را تغییر بده . wpf طراحی شده تا کاربر راحت تر بتونه ظاهر کنترل را تغییر بده .

منبع این ادعا که "wpf طراحی شده تا کاربر راحت تر بتونه ظاهر کنترل را تغییر بده ." کجا است؟ در سایت مایکروسافت یا یک سایت معتبر دیگه هست؟ مایکروسافت برای بزک کردن که پلتفرم نمیسازه.

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

اکثرا؟ نظر سنجی کرده اید؟ از چند نفر آمار گرفته اید؟ تعداد برنامه نویسان دنیا دست تون هست که میگید اکثر شون مشکل خاصی ندارند؟ نظر اکثریت رو چطور میدونید؟ علم غیب دارین؟

همونطور که مستحضرید ، همین پروپرتی ، ContentControl.Content خیلی میتونه از ساخت template ها جلوگیری کنه و کاربر با کمترین کد بتونه به هدفش برسه برای تغییرات ظاهریِ اولیه (مثلا اضافه کردن Border و ...) .

وقتی شما نمیدونید برنامه نویس داره چه برنامه ای می نویسه و نمیدونید نیازش در این برنامه چیه، چطور قضاوت می کنید که با فلان مورد به هدفش می رسه یا نمیرسه؟

البته ، این برای آموزش wpf هست . آموزش هم شامل template ها میشه . بنابراین من به اون دسته از کاربرانی که از کمپوننت کار میکنن یا آموزشم را نمیبینن ، کاری ندارم . حالا در wpf از کمپوننت استفاده کنن یا نکنن (ملاکی برام نیست) .
برام ارائه ای این قابلیت template و آموزشش مهم هه .

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

این قسمت فقط معرفی هه . معرفی هم کلیات هست . مثلا من میخوام موشک فینیکس را معرفی کنم برای کسایی که نمیدونن چیه ، میگم موشک قدرتمند راداری برای هواپیمای F14 هست که سرعت فلان قدر را داره در قسمت های بعد میام میام جزئیاتش را آموزش میدم و در اونجا کاربر متوجه میشه که در جلسه ی اول وقتی گفتیم قدرتمند هه ، این تمایز قدرتش با بقیه ی موشک ها چقدر هه و در چه پارامترهایی هه و عملکرد قطعات درونی اش هر کدوم به چه شکل هه .

کاری که شما انجام دادید معرفی نیست، دادن اطلاعات فنی در مورد موشک فینیکس AIM-54 هم نیست، شما نه عدد دادید و نه منبع و نه روش ارزیابی رو مشخص کردید.

این بخش 9 و 12 بصورت کلی هه . مثل بقیه ی موارد که گفتم هم قطعا بصورت کلی (و مبهم) بیان شد و بعدا در قسمت های بعدی آموزش هر کدومش داده میشه .
به هر حال ، توضیحات بیشتر اینکه :
- شماره ی 9 که به نظرم حداقل مبهم نیست (بیانش معلوم هه دیگه).

کلی بودن اشکالی نداره، ابهام و اشتباه بودن ایراد داره.
یعنی شما موارد 9 و 12 رو بصورت جزئی توضیح می دهید و ابهام برطرف میشه؟ یعنی می توانید توضیح بدهید که Routed Events بهینه تر ئه؟ چه چیزی اش بهینه تر ئه؟
یا توضیح می توانید سیستم گرافیک دو بعدی قوی تری داره و در نتیجه مثال نقض wpfvswinforms.rar وجود نداره؟

- سیستم گرافیک 2 بعدی قویتر => یعنی مثلا سیستم رندر Vector Base ، چیزهایی مثل Effect ها و ...

حالا خوبه که نرم افزار های گرافیکی برداری و غیر برداری معروف و شناخته شده مبتنی بر Windows Forms هستند، نه WPF و این ادعا رو دارید.

 

[the_king]

- سیستم رویداد بهینه تر => مثل Routed Event

یعنی چی بهینه تر؟ چه چیزی نسبت به سیستم رخداد های Windows Forms بهینه تر ئه؟ چقدر بهینه تر ئه؟ چند درصد؟ چه مقداری؟ چه ملاکی؟

- امنیت بیشتر => دقیق نمیدونم . توی لینک زیر دیدم نوشته (بخش 4) :
Winforms vs WPF | Learn The Top 6 Most Awesome Differences

من با هیچکدوم از مقایسه های فنی که انجام دادن مشکلی دارم، برای همین با مزیت "امنیت بیشتر" مخالفتی نداشتم. دلایل و معیارهای هر کدوم از اون مقایسه ها که در سایت های می بینید مشخص ئه.
مشکل صرفا در مواردی است که شما بدون عیار و ملاک اضافه کرده اید.

- کارایی بهینه تر و قابل انعطاف تر => باز هم در لینک بالا (شماره 6) نوشته . همچنین سند زیر در مایکروسافت در این باره هست (همچنین کلاس هایی مثل Freezable که میشه اشیاهایی که از این کلاس ارث بری میکنن را برای قابلیت فقط خوندنی ست کرد تا کارایی شون افزایش پیدا کنه) :

اگه فکر می کنید در ترجمه کردن منابع انگلیسی به مشکل بر میخورید لطفا در آموزش هاتون از اون منابع استفاده نکنید. کارایی بهینه تر یعنی Optimized Performance، اصلا اون شماره 6 ربطی به کارایی بهینه تر نداره.
حالا انعطاف پذیرتر از کجا اومد؟ achieved at very fast rate رو چی ترجمه می کنید؟ achieve یعنی چی؟ نه اون کارایی که مد نظرشه سرعت اجرا است و نه سرعت دریافت داده و نه نمایش داده و نه اینجور موارد. یک معیار کلی از اینه که برنامه نویس برای اینکه فلان کار رو انجام بده در WPF به زمان بیشتری نیاز داره یا در Windows Forms. و حتی در توضیحات مواردی مثل Windows forms are less time consuming or less tricky هست که میگه در بعضی جاها برای WPF باید زمان بیشتری صرف کنید. achieve یعنی به انجام رساندن، به مقصود رسوندن. یعنی برای طراحی و توسعه نرم افزار اگه بخواهید فلان کار رو انجام بدهید در WPF در زمان کمتر و با سرعت بیشتری انجامش می دهید. ممکنه سرعت اجرای کد فرقی نکنه یا حتی در WPF کند تر باشه، یعنی کارایی اش بهتر نباشه، اما در زمان کمتری نرم افزار تون رو توسعه می دهید. این اصلا ربطی به کارایی بهینه تر نداره.
کارایی هم یا بهتر میشه یا بهینه تر. بهتر یعنی کارایی بالاتر. بهینه تر یعنی تغییراتی د مورد قبلی داده شده که بهتر عمل کنه، وقتی WPF بر پایه Windows Forms نیست و معماری مجزایی است، دیگه چیزی رو بهینه نکرده اند، یا بهتر ئه یا بهتر نیست. بهینه سازی در کار نیست که بگید بهینه تر.
میزان مصرف حافظه و میزان نیاز به پردازنده WPF و Windows Forms رو مقایسه کنید و ببینید کارایی اش بهینه نیست.

Optimize app performance - WPF

اینکه اصلا ربطی به Windows Forms نداره. شما ReSharper رو روی Visual Studio نصب می کنید و می بینید کند اش می کنه. برای کمتر شدن این کندی و بهینه کردنش یکسری راهنمایی ها است، این که معنی اش این نیست که ReSharper نسبت به فلان نرم افزار مشابه بهینه تر ئه چون یک راهنمایی برای افزایش کارایی اش هست. اون بهینه سازی برای خود WPF ئه، ربطی به نمونه های مشابه نداره.

- مهاجرت راحت تر به .Net Core => مستندات این هم در اینترنت هست .

من اصلا مشکلی با این مواردی که در هر منبع معتبری پیدا میشه ندارم.

- سیستم Resource بهینه و قویتر=> منظورم Resource های مربوط به فایل ها نیست . بلکه قابلیت تعریف Resource توسط پروپرتیِ FrameworkElement.Resources هست .

اینکه قابلیت تعریف Resource توسط پروپرتی فلان هست یعنی این ویژگی هست، فقط همین. یعنی سیستم Resource بهینه و قوی تر ئه؟ در Windows Forms قابلیت تعریف Resource توسط ComponentResourceManager با همون فرمت XML هست. یعنی بهینه تر و قوی تر ئه؟
در Windows Forms مشخصه های کنترل ها با IExtenderProvider افزایش پیدا می کنه، یعنی پروپرتی های Windows Forms بهینه تر و قوی تر ئه؟

- پشتیبانی از کنترل های WinForm در WPF => هم که جزء ویژگی هست .

بله. که برعکسش هم هست. چیزی نیست که بخواهید مقایسه کنید.

- استفاده از MVVM Pattern => این را هم باید حذف کنم استاد . درسته؟ چون MVVM همون قابلیت لایه بندی هست دیگه؟ مثل 3 لایه بودن در WinForm . اگه آره پس درWinForm هم میشه بصورت MVVM نوشت دیگه؟

اگر به عنوان مزیت نوشته اید مزیت نیست، اما اگه به عنوان ویژگی نوشته اید مشکلی نداره. هر مدل و معماری مشخصی رو با تغییرات کم یا زیاد میشه روی هر پلتفرمی پیاده سازی کرد، اما در کل هر پلتفرمی روی یک مدل معماری خاص طراحی شده که پیاده سازی اون مدل و مدل های مشابهش رو ساده می کنه، مثلا MVVM با WPF بخوبی و سادگی جور در میاد، نه اینکه در Windows Forms قابل اجرا نباشه.
این نه مزیت ئه و نه عیب. صرفا یک ویژگی است.

- استفاده از Microsoft Blend برای کمک در طراحی رابط کاربری => هم که دیگه مشخصه .

این نه ویژگی است و نه مزیت. مثلا انواع نرم افزار های گرافیکی یا تخصصی طراحی UI هستند که برای طراحی رابط کاربری Windows Forms قابل استفاده هستند، از طراحی کامل فرم گرفته تا تصویر زمینه و آیکون و ...
طبعا اینها رو نمی توانید جزو ویژگی های پلتفرم بدانید.

 

[SajjadKhati]

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

سلامی مجدد
خیلی ممنون استاد .
جداشون کردم .

میانگین و کلی روی چه حساب و کتابی؟ همینجوری رو هوا؟
میانگین که معنی اش مشخص ئه، شما اگر هزار تا عدد داشته باشید، میانگین شون به همه اون هزار عدد وابسته است، فقط با در نظر گرفتن دو سه عدد به میانگین نمی رسید.
ارزیابی کلی تون بر اساس چی بوده؟ چطوری این نتیجه رو داده؟ این طرف چه مقداری داده و اون طرف چه مقداری داده که این نتیجه بدست اومده؟
شما که می توانید بصورت کلی کنترل های WPF رو با Windows Forms مقایسه کنید باید بدونید برای هر کدوم یک ملاک و مقداری داشته باشید.
بصورت میانگین و کلی، وسعت و عملکرد و خصوصیت و انعطاف پذیری کنترل های WPF براتون مشخص شده؟ چقدر ئه؟ بر اساس چیه؟ عدد ئه؟ درصد ئه؟ با 0 تا 10 مشخص شده؟


تعداد کلاس معیار کدوم نتیجه گیری شما است؟ از تعداد کلاس بیشتر چه نتیجه ای می گیرید؟ مثلا این دو تا مثال کنترل A و کنترل B رو مقایسه کنید و از بیشتر بودن تعداد کلاس ها نتیجه گیری کنید :

        public class A : Control
        {
        }

        public class BaseControl : Control
        {
        }

        public class WinControl : BaseControl
        {
        }

        public class VisualControl : WinControl
        {
        }
      
        public class B : VisualControl
        {
        }

کلاس خالی را نگفتم که استاد
اگه هیچ قابلیت یا انعطاف پذیری بیشتری در کار نبود ، مایکروسافت نمیومد دوباره یه پلتفرم جدید طراحی کنه . از همون winform استفاده میکرد و صرفا قابلیت های winform را افزایش میداد .
کما اینکه قابلیت هایی مثل OpacityMask و Rotate (کلا Transform ئه کل کنترل . نه صرفا فقط محتوای کنترل) ، خود Opacity ئه کنترل و مواردی از این قابلیت ها را به کنترل ها اضافه کرد که در winform فقط با شخصی سازی کنترل شدنی هست (اون هم با حجم کد گاها بسیار زیاد) .
در انعطاف پذیری هم در ContentControl ها و هم Panel ها و هم Template ها این مورد را میتونیم ببینیم.
که قطعا همه ی این موارد (و حتی بیشتر) را میدونین .

بعد اینکه خیلی از اینهایی که نوشتم ، گفته ی خودم نبود (البته بعضی ها را خودم اضافه کردم) . خیلی از اینها را از منابع و سایت ها گرفتم . حالا شاید گاها خوب درک نکرده باشم . اگه میخواین ، بگین لینک بدم .

میل خودتونه، هر کسی رو که با اطلاعات اشتباه گمراه کنید گناهش به گردن شما است، نه من.

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

لطفا قبل از اینکه به پاسخ های من جواب بدید بخونید ببینید چی نوشتم، "هر شیء ای" در جواب من بود که میگید مد نظر منه؟ شما در پست خودتون نوشته اید "3) هر کنترلی را درون کنترل ContentControl میشه قرار داد" یعنی گفته اید هر شیء ای رو میشه داخل ContentControl قرار داد؟ ToolTip به عنوان یک شیء رو میشه داخل ContentControl ئه Grid قرار داد؟
فرق بین هر شیء ای با شیء کنترل رو نمی دونید؟ در تمامی Control ها میشه داخل Controls شیء به عنوان فرزند قرار داد، اما اگر ContainerControl باشه کاربر میتونه موقع طراحی فرم داخلش کنترل قرار بده، مثل Panel و GroupBox و ...

اینکه گفتم هر کنترلی را میشه داخلش قرار داد ، اشتباه کردم . هر شی باید بنویسم .
بله درست میگید . ToolTip را در ContentControl نمیشه قرار داد . ممکنه خیلی از اشیاء کلاس ها و کنترل های دیگه ای هم وجود داشته باشن که نشه توشون قرار داد که اونها جزء موارد ما نیستن . وگرنه طراحان ، پروپرتی ContentControl.Content را میتونستن از نوع یه کلاس خاصی بگیرن که محدود به اون اشیاء باشه نه اینکه از نوع Object بگیرن .

بسیار محدود؟ تعداد کنترل های Windows Forms رو میدونید که میگید بسیار محدود؟ قبل از اینکه WPF رو با Windows Forms مقایسه کنید لازم نیست که Windows Forms رو بشناسید؟
لیست بسیار محدود کنترل هایی که میشه داخل ContainerControl قرار داد رو می توانید بنویسید؟

استاد ، من گفتم اگه منظورتون ContainerControl بود .
هنوز که نمیدونم منظورتون کدوم بود .
منظورتون پروپرتی Control.Controls هست؟
واسه ی همینکه نمیدونم و دقیق نمیشناسم ، گفتم بی زحمت بررسی کنید اشتباه نداشته باشم ها .

منبع این ادعا که "wpf طراحی شده تا کاربر راحت تر بتونه ظاهر کنترل را تغییر بده ." کجا است؟ در سایت مایکروسافت یا یک سایت معتبر دیگه هست؟ مایکروسافت برای بزک کردن که پلتفرم نمیسازه.

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

اکثرا؟ نظر سنجی کرده اید؟ از چند نفر آمار گرفته اید؟ تعداد برنامه نویسان دنیا دست تون هست که میگید اکثر شون مشکل خاصی ندارند؟ نظر اکثریت رو چطور میدونید؟ علم غیب دارین؟


وقتی شما نمیدونید برنامه نویس داره چه برنامه ای می نویسه و نمیدونید نیازش در این برنامه چیه، چطور قضاوت می کنید که با فلان مورد به هدفش می رسه یا نمیرسه؟

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

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

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

البته گفتم که اغلب غریب به اتفاق این مطالب را از منابع و سایت ها پیدا کردم و اگه خواستید بگین لینک منابع را بهتون بدم .

کاری که شما انجام دادید معرفی نیست، دادن اطلاعات فنی در مورد موشک فینیکس AIM-54 هم نیست، شما نه عدد دادید و نه منبع و نه روش ارزیابی رو مشخص کردید.


کلی بودن اشکالی نداره، ابهام و اشتباه بودن ایراد داره.
یعنی شما موارد 9 و 12 رو بصورت جزئی توضیح می دهید و ابهام برطرف میشه؟ یعنی می توانید توضیح بدهید که Routed Events بهینه تر ئه؟ چه چیزی اش بهینه تر ئه؟
یا توضیح می توانید سیستم گرافیک دو بعدی قوی تری داره و در نتیجه مثال نقض wpfvswinforms.rar وجود نداره؟

بسیاری اش را بله دیگه .
البته نگفتم Routed Events بهینه تر هست . گفتم رویداد wpf بهینه تر هست . بخاطر داشتن همین Routed Events .

البته این مثال و پروژه تون نیاز داره که کاملا کدها بررسی بشه و wpf را هم کاملا بشناسیم . ولی در وهله ی اول ، الان پس سریعتر عمل نمیکنه؟
تفاوت سرعت کد هم خیلی بالاست . به چه دلیل این طوره و این قدر wpf کندتر هه؟

حالا خوبه که نرم افزار های گرافیکی برداری و غیر برداری معروف و شناخته شده مبتنی بر Windows Forms هستند، نه WPF و این ادعا رو دارید.

الان Windows Forms از گرافیک برداری پشتیبانی میکنه؟!
پس چرا توی این همه سایت ها یکی از مهمترین عاملِ تفاوتِ WPF از Windows Forms را پشتیبانیِ WPF از گرافیک برداری اعلام میکنن؟!

 

[SajjadKhati]

یعنی چی بهینه تر؟ چه چیزی نسبت به سیستم رخداد های Windows Forms بهینه تر ئه؟ چقدر بهینه تر ئه؟ چند درصد؟ چه مقداری؟ چه ملاکی؟


من با هیچکدوم از مقایسه های فنی که انجام دادن مشکلی دارم، برای همین با مزیت "امنیت بیشتر" مخالفتی نداشتم. دلایل و معیارهای هر کدوم از اون مقایسه ها که در سایت های می بینید مشخص ئه.
مشکل صرفا در مواردی است که شما بدون عیار و ملاک اضافه کرده اید.


اگه فکر می کنید در ترجمه کردن منابع انگلیسی به مشکل بر میخورید لطفا در آموزش هاتون از اون منابع استفاده نکنید. کارایی بهینه تر یعنی Optimized Performance، اصلا اون شماره 6 ربطی به کارایی بهینه تر نداره.
حالا انعطاف پذیرتر از کجا اومد؟ achieved at very fast rate رو چی ترجمه می کنید؟ achieve یعنی چی؟ نه اون کارایی که مد نظرشه سرعت اجرا است و نه سرعت دریافت داده و نه نمایش داده و نه اینجور موارد. یک معیار کلی از اینه که برنامه نویس برای اینکه فلان کار رو انجام بده در WPF به زمان بیشتری نیاز داره یا در Windows Forms. و حتی در توضیحات مواردی مثل Windows forms are less time consuming or less tricky هست که میگه در بعضی جاها برای WPF باید زمان بیشتری صرف کنید. achieve یعنی به انجام رساندن، به مقصود رسوندن. یعنی برای طراحی و توسعه نرم افزار اگه بخواهید فلان کار رو انجام بدهید در WPF در زمان کمتر و با سرعت بیشتری انجامش می دهید. ممکنه سرعت اجرای کد فرقی نکنه یا حتی در WPF کند تر باشه، یعنی کارایی اش بهتر نباشه، اما در زمان کمتری نرم افزار تون رو توسعه می دهید. این اصلا ربطی به کارایی بهینه تر نداره.
کارایی هم یا بهتر میشه یا بهینه تر. بهتر یعنی کارایی بالاتر. بهینه تر یعنی تغییراتی د مورد قبلی داده شده که بهتر عمل کنه، وقتی WPF بر پایه Windows Forms نیست و معماری مجزایی است، دیگه چیزی رو بهینه نکرده اند، یا بهتر ئه یا بهتر نیست. بهینه سازی در کار نیست که بگید بهینه تر.
میزان مصرف حافظه و میزان نیاز به پردازنده WPF و Windows Forms رو مقایسه کنید و ببینید کارایی اش بهینه نیست.

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

اینکه اصلا ربطی به Windows Forms نداره. شما ReSharper رو روی Visual Studio نصب می کنید و می بینید کند اش می کنه. برای کمتر شدن این کندی و بهینه کردنش یکسری راهنمایی ها است، این که معنی اش این نیست که ReSharper نسبت به فلان نرم افزار مشابه بهینه تر ئه چون یک راهنمایی برای افزایش کارایی اش هست. اون بهینه سازی برای خود WPF ئه، ربطی به نمونه های مشابه نداره.


من اصلا مشکلی با این مواردی که در هر منبع معتبری پیدا میشه ندارم.


اینکه قابلیت تعریف Resource توسط پروپرتی فلان هست یعنی این ویژگی هست، فقط همین. یعنی سیستم Resource بهینه و قوی تر ئه؟ در Windows Forms قابلیت تعریف Resource توسط ComponentResourceManager با همون فرمت XML هست. یعنی بهینه تر و قوی تر ئه؟
در Windows Forms مشخصه های کنترل ها با IExtenderProvider افزایش پیدا می کنه، یعنی پروپرتی های Windows Forms بهینه تر و قوی تر ئه؟


بله. که برعکسش هم هست. چیزی نیست که بخواهید مقایسه کنید.


اگر به عنوان مزیت نوشته اید مزیت نیست، اما اگه به عنوان ویژگی نوشته اید مشکلی نداره. هر مدل و معماری مشخصی رو با تغییرات کم یا زیاد میشه روی هر پلتفرمی پیاده سازی کرد، اما در کل هر پلتفرمی روی یک مدل معماری خاص طراحی شده که پیاده سازی اون مدل و مدل های مشابهش رو ساده می کنه، مثلا MVVM با WPF بخوبی و سادگی جور در میاد، نه اینکه در Windows Forms قابل اجرا نباشه.
این نه مزیت ئه و نه عیب. صرفا یک ویژگی است.


این نه ویژگی است و نه مزیت. مثلا انواع نرم افزار های گرافیکی یا تخصصی طراحی UI هستند که برای طراحی رابط کاربری Windows Forms قابل استفاده هستند، از طراحی کامل فرم گرفته تا تصویر زمینه و آیکون و ...
طبعا اینها رو نمی توانید جزو ویژگی های پلتفرم بدانید.

کلا استاد ممنون میشم موارد اشتباه را تصحیح کنید و همچنین مواردی که به نظرتون در لیست نیست را بهم بگین اضافه کنم (چه موارد ویژگی ها چه موارد مقایسه ها) .
تشکر

 

[the_king]

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

این شد دلیل و منطق؟ مایکروسافت برای طراحی پلتفرم جدید با نظر و ایده شما تصمیم میگیره؟
Adobe سالها بعد از طراحی Photoshop چند تا نرم افزار دیگه مثل Adobe Photoshop Lightroom و Adobe Photoshop Elements طراحی کرده، اینها قابلیت و انعطاف پذیری شون بیشتر از فتوشاپ شده؟

کما اینکه قابلیت هایی مثل OpacityMask و Rotate (کلا Transform ئه کل کنترل . نه صرفا فقط محتوای کنترل) ، خود Opacity ئه کنترل و مواردی از این قابلیت ها را به کنترل ها اضافه کرد که در winform فقط با شخصی سازی کنترل شدنی هست (اون هم با حجم کد گاها بسیار زیاد) .
در انعطاف پذیری هم در ContentControl ها و هم Panel ها و هم Template ها این مورد را میتونیم ببینیم.
که قطعا همه ی این موارد (و حتی بیشتر) را میدونین .

همه اینها رو میدونم. اینها مورد 5 ئه که بهشون اشاره کرده اید و من هم ایرادی به مورد 5 ای که نوشتید نگرفتم. اما اینها که بهشون اشاره کردید نه دلیل برای انعطاف پذیری بیشتر ئه و نه چیز دیگری.
یک ویژگی WPF رو نمی توانید بزور به عنوان مزیت دربیارید. شما با اون انعطاف پذیری بیشتر و نمیدونم چی چی بهینه تر و قوی تر که مدعی هستید این مثال ساده Windows Forms رو با چند کد #C یا XAML در WPF پیاده سازی می کنید؟

        private void button1_Click(object sender, EventArgs e)
        {
            using (var g = button1.CreateGraphics())
            {
                var pixels = new bool[button1.Width, button1.Height];
                var count = button1.Width * button1.Height;
                var rnd = new Random();
                for (var i = 0; i < count; i++)
                {
                    int x, y;
                    do
                    {
                        x = rnd.Next(button1.Width);
                        y = rnd.Next(button1.Height);
                    } while (pixels[x,y]);
                    pixels[x, y] = true;
                    g.DrawLine(SystemPens.Control, x, y, x + 1, y);
                }
            }
        }

بعد اینکه خیلی از اینهایی که نوشتم ، گفته ی خودم نبود (البته بعضی ها را خودم اضافه کردم) . خیلی از اینها را از منابع و سایت ها گرفتم . حالا شاید گاها خوب درک نکرده باشم . اگه میخواین ، بگین لینک بدم .

من اون مواردی که بهشون ایراد گرفتم همون مواردی است که خودتون اختراع کرده اید، جدید و ابداعی بودنشون مشکلی نداره، مشکل اینه که پشتوانه نداره، دو تا عدد، یک معیار منطقی، چیزی نشون ندادید که مشخص بشه چی با چی مقایسه شده و این نتیجه رو گرفته اید. به نظرتون عجیب نیومد که چطور بقیه به ذهنشون نرسیده که اون مزیت ها رو بنویسند؟

خوب من چی کار کنم استاد؟

خیلی ساده است.
1 - پیش داوری نکنید. یعنی وقتی می خواهید x رو با y مقایسه کنید فرض رو بر این قرار ندید که y قوی تر و حالا بیاییم اثباتش کنیم. فرضا نیایید فرض رو بر این نگیرید که چون WPF جدیدتر ئه پس باید کارایی و ... بهتری داشته باشه.
2 - وقتی می خواهید x رو با y مقایسه کنید، مزیت و عیب رو با معیار منطقی اش بسنجید. مثلا تعداد کلاس یا تعداد وراثت کلاس ها معیار انطاف پذیری یا بهینه بودن نیست، فقط ملاک اینه که این نرم افزار تعداد کلاس و تعداد وراثت بیشتری داره. همین. از روی این معیار نمیشه قضاوت کرد که کدوم کارایی بهتری داره یا انعطاف پذیری اش بیشتر ئه.
3 - در ترجمه منابع دقت کنید، ببینید به چی اشاره می کنه، فرضا اگه میگه در x فلان کار زمان بیشتری لازم داره دیگه نمی توانید نتیجه بگیرید که در y همه کارها سریعتر از x انجام میشه.

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

که اشتباه ئه، مثلا هم زدم، نباید بنویسید هر شیء. هر شیء محدودیت نداره. چون دقت نمی کنید یک اشتباه رو چند بار تکرار می کنید.
براتون مثال زدم، شی میتونه ToolTip باشه، اما شما نمی توانید ToolTip ها رو به عنوان شیء داخل Grid قرار بدهید.

بله درست میگید . ToolTip را در ContentControl نمیشه قرار داد . ممکنه خیلی از اشیاء کلاس ها و کنترل های دیگه ای هم وجود داشته باشن که نشه توشون قرار داد که اونها جزء موارد ما نیستن . وگرنه طراحان ، پروپرتی ContentControl.Content را میتونستن از نوع یه کلاس خاصی بگیرن که محدود به اون اشیاء باشه نه اینکه از نوع Object بگیرن .

"موارد ما" چیه دیگه؟ مثل اینه که بگید ایران بزرگترین کشور دنیا است. بعد بگم پس روسیه و چین و کانادا و ... چی؟ جواب بدید که اونها جزو کشور های ما نیستند.
وقتی میدونید فرض تون مثال نقض داره یعنی فرض تون غلط ئه. فرض غلط که با نادیده گرفتن مثال های نقض درست نمیشه.
هر مشخصه ای نوع اش object باشه برای قبول کردن هر نوع شیء کفایت می کنه؟ همه مشخصه ها مثل Tag نیستند که کاری به مقدار نداشته باشند و در نتیجه اعتبارسنجی نکنند. مشخصه یا پارامتر میتونه از نوع object باشه ولی با Validation داخلش صرفا انواع و مقادیر خاصی رو قبول کنه، اینکه نشد هر شی ای.

استاد ، من گفتم اگه منظورتون ContainerControl بود .
هنوز که نمیدونم منظورتون کدوم بود .
منظورتون پروپرتی Control.Controls هست؟
واسه ی همینکه نمیدونم و دقیق نمیشناسم ، گفتم بی زحمت بررسی کنید اشتباه نداشته باشم ها .

شما زحمت بکشید و لیست اون کنترل های بسیار محدود رو بنویسید تا جواب بدم.

ظاهر کنترل و البته گرافیک بهترو مخصوصا سریعتر .

این جواب سوال من نبود. سوالم این بود که منبع این ادعا که "wpf طراحی شده تا کاربر راحت تر بتونه ظاهر کنترل را تغییر بده ." کجا است؟ لینکش رو بدید.

یعنی الان شما میگین wpf علاوه بر ظاهر کنترل و کلا گرافیک ، ساخته شده تا منطق کنترل را هم کاربر بتونه راحت تر (به نسبت winform) تغییر بده؟

من فارسی می نویسم نه انگلیسی که بگید بد ترجمه شده. این جمله رو از کدوم نوشته من استخراج کرده اید؟

من که تفاوتی از لحاظ تهیه ی سریعتر منطق کنترل در wpf و winform نمیبینم .

منطق کنترل از کجا وسط بحث اومد؟ چی دارید میگید؟ به جواب های من ربطی داره؟

شاید سند هیچ کدوم در اینترنت نباشه ولی خودتون هم فکر کنم میدونید که در wpf سر و کارمون با تغییر منطق کنترل نیست .

سند چیزی که موجود نیست یا باید اثبات پذیر باشه و خودتون اثباتش کنید یا ادعای بدون پشتوانه و بی اعتبار ئه.
الان میگید در WPF سر و کارمون با تغییر منطق کنترل نیست. ادعای شما است. سند داره؟ خیر. حاصل سالها تحقیق روی انواع پروژه های WPF ئه؟ خیر. ادعای طراح و سازنده WPF ئه؟ خیر.
اثبات پذیر ئه؟ خیر. مثال نقض داره؟ قطعا. حتی اگه در یک مثال پروژه WPF منطق کنترل ای با حالت پیشفرض متفاوت باشه، فرضا در TextBox_KeyDown چیزی رو Handled کنه منطق کنترل تغییر کرده و ادعا تون نقض شده. یک ادعایی می کنید بدون پشتوانه، بدون سند، بدون منطق.

 

[the_king]

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

مگه نمیگید اکثرا مشکل ندارند؟ اون اکثرا چند نفر هستند و اون اقلیت چند نفر؟ وقتی میدونید اکثریت مشکل ندارند باید مشخص باشه اکثریت به اقلیت چه نسبتی داره، جایی باید آمارش باشه که بگید بر این اساس ئه.

استاد کلا مباحث را بذاریم کنار .
بعد هم از من سئوال نکنین . من که استاد شما نیستم که ازم صد تا سئوال کردین

من در مقابل سوالات شما سوال نکردم، در مورد ادعا های شما سوال کردم، شما وقتی ادعا می کنید که فلان بهمان ئه، هر کسی، حتی شاگردتون هم نباشه میتونه ازتون سوال کنه که این ادعا روی چه اساسی ئه.
شما همیشه باید بتوانید ادعایی رو مطرح کنید که بتوانید پاسخگو باشید، ربطی به این نداره که چه کسی ازتون سوال می کنه.
این اشتباه ئه که اول یک ادعا رو مطرح کنید و بعد ببینید من ایراد میگیرم یا نه. ادعای بدون پشتوانه و منطق رو کلا بذارید کنار، چه به من بگید و چه در آموزش ها باشه و چه در هر جای دیگری اشتباه ئه.

البته گفتم که اغلب غریب به اتفاق این مطالب را از منابع و سایت ها پیدا کردم و اگه خواستید بگین لینک منابع را بهتون بدم .

خیلی ممنون می شوم اگر برای اون چند مورد که بهشون اشاره کردم منابع رو معرفی کنید. با همون منابع بهتون نشون میدم که چطور نتیجه اشتباه گرفته اید.

البته نگفتم Routed Events بهینه تر هست . گفتم رویداد wpf بهینه تر هست . بخاطر داشتن همین Routed Events .

اولا میگید بهینه تر. تر صفت تفضیلی ئه. بهینه تر یعنی رویداد در WPF باید بر اساس Windows Form باشه که بهینه سازی بیشتری شده. نمیشه که معماری مجزایی باشه و بهینه تر باشه.
در حالی که معماری مجزایی است. پس بهینه تر اشتباه ئه، باید بگید بهتر. حالا میگید بهتر ئه؟ بخاطر داشتن این Routed Event چه چیزی بهتر شده؟
چه چیز نامطلوبی کاهش پیدا کرده یا چه چیز مثبتی افزایش پیدا کرده؟ سوال خیلی ساده است.

البته این مثال و پروژه تون نیاز داره که کاملا کدها بررسی بشه و wpf را هم کاملا بشناسیم

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

تفاوت سرعت کد هم خیلی بالاست . به چه دلیل این طوره و این قدر wpf کندتر هه؟

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

الان Windows Forms از گرافیک برداری پشتیبانی میکنه؟!

بله، مثلا نمایش فونت برداری ئه. GraphicsPath و ...

پس چرا توی این همه سایت ها یکی از مهمترین عاملِ تفاوتِ WPF از Windows Forms را پشتیبانیِ WPF از گرافیک برداری اعلام میکنن؟!

صحبت پشتیبانی نیست، کاری به امکان رسم و نمایش ندارند، سیستم شون رو دارند مقایسه می کنند. نمیگن که Windows Forms نمی تونه گرافیک برداری رو نشون بده یا WPF نمیتونه تصاویر Bitmap رو نشون بده.
پشتیبانی یعنی اینکه بتونه فلان مورد رو انجام بده. فرق می کنه با اینکه ذاتا چی باشه.
دارند میگن که معماری خود اون پلتفرم بر اساس چیه. Windows Forms معماری اش مبتنی بر Raster و حافظه Bitmap ئه. بردار رو نهایتا موقع نمایش تبدیل به پیکسل ها می کنه تا نمایش بده.
برعکسش WPF معماری اش مبتنی بر Vector ئه، مثل Adobe Flash یا صفحات وب. برای همین بهتون توصیه کردم که در WPF از تصاویر Bitmap اجتناب کنید، چون مزیت WPF روی بردار ئه که بتونه در ابعاد متفاوت کیفیتش رو حفظ کنه.

 

[SajjadKhati]

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

خیلی ممنون استاد .
استاد ، برای بقیه ی بخش ها ، بحث را ادامه نمیدم چون همینجوری دارم از هدفم دور میشم. اصلا هدف من ، بحث کردن نبود . هدفم این بود که اون 12 مورد را که بهتون ارائه دادم ، شما اگه مشکلی میبینید و غلط هه ، به من عبارت دقیق تصحیح شده اش را بدین . اگه هم چیزی از ویژگی و مزایا (که از هم جداشون کردم) را در لیست نگفتم ، بهم بگید که اضافه کنم . من فکر میکردم که wpf نسبت به winform اصلا معایبی نداره و از همه لحاظ بهتر شده ، با این اوصاف ، اگه معایبی هم نسبت به wpf داره (که ظاهرا توی سرعت اجرای کدهاست) ، این را هم عبارت صحیح اش را بهم بگین ، ممنون میشم .

یه کم بیشتر درباره ی قضیه ی این قاشق و چنگال بیشتر توضیح میدین؟ در واقع ، من هنوز متوجه نشدم که چرا سرعت اجرای کدهای wpf خیلی کمتره؟ آیا دلیل اش همون قضیه ی clr ای که (به نسبت C++ Native) در پست قبل مثال زدم هست؟
بعد اینکه میشه با تنظیمات (یا استفاده از اشیاهایی مثلا Freezable و اینها) یا هر روش دیگه، سرعت اجرای کد wpf را زیادتر کرد؟ جوری که در این پروژه ای که دادین ، سرعت wpf با winform برابر بشه؟ یا حداقل این اختلاف فاحش را تا حدود زیادی جبران کنه؟
کلا دلیل اختلاف بسیار زیاد کد wpf و winform چیه؟

صحبت پشتیبانی نیست، کاری به امکان رسم و نمایش ندارند، سیستم شون رو دارند مقایسه می کنند. نمیگن که Windows Forms نمی تونه گرافیک برداری رو نشون بده یا WPF نمیتونه تصاویر Bitmap رو نشون بده.
پشتیبانی یعنی اینکه بتونه فلان مورد رو انجام بده. فرق می کنه با اینکه ذاتا چی باشه.
دارند میگن که معماری خود اون پلتفرم بر اساس چیه. Windows Forms معماری اش مبتنی بر Raster و حافظه Bitmap ئه. بردار رو نهایتا موقع نمایش تبدیل به پیکسل ها می کنه تا نمایش بده.
برعکسش WPF معماری اش مبتنی بر Vector ئه، مثل Adobe Flash یا صفحات وب. برای همین بهتون توصیه کردم که در WPF از تصاویر Bitmap اجتناب کنید، چون مزیت WPF روی بردار ئه که بتونه در ابعاد متفاوت کیفیتش رو حفظ کنه.

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


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

اون سایت ها ، لینک های زیرن (البته میگم اندکی را هم خودم اضافه کردم) به علاوه حدود 3 تا فیلم ویدئوی انگلیسی که در کامپیوترم دارم اند :

Winforms vs WPF | Learn The Top 6 Most Awesome Differences

و

What is the difference between WPF and WinForms?

و

WPF vs. WinForms - The complete WPF tutorial

و

Why Use WPF?

و

Why WPF Is Better Than WinForms in .NET | ITProPortal

و

Eternitech - WPF (Windows Presentation Foundation)-Integration Solutions

و

Advantages and disadvantages of WPF over winforms ? - CodeProject

و

Advantages of UI design in XAML

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

استاد ، الان برام این اهمیت داره که جاهایی که به نظرتون اون متن (12 مورد) که دادم اگه اشتباه هست ، لطفا بی زحمت اصلاح اش کنید و متن دقیق را بهم بدین .
همچنین اگه موردی هست که به نظرتون گفته نشد (چه ویژگی چه مزایا و مقایسه ی با windows form) را بگین .
همچنین در صورت داشتن معایب wpf نسبت به windows form ، این معایب را هم بگین .
تشکر

 

[the_king]

خیلی ممنون استاد .
استاد ، برای بقیه ی بخش ها ، بحث را ادامه نمیدم چون همینجوری دارم از هدفم دور میشم. اصلا هدف من ، بحث کردن نبود . هدفم این بود که اون 12 مورد را که بهتون ارائه دادم ، شما اگه مشکلی میبینید و غلط هه ، به من عبارت دقیق تصحیح شده اش را بدین . اگه هم چیزی از ویژگی و مزایا (که از هم جداشون کردم) را در لیست نگفتم ، بهم بگید که اضافه کنم . من فکر میکردم که wpf نسبت به winform اصلا معایبی نداره و از همه لحاظ بهتر شده ، با این اوصاف ، اگه معایبی هم نسبت به wpf داره (که ظاهرا توی سرعت اجرای کدهاست) ، این را هم عبارت صحیح اش را بهم بگین ، ممنون میشم .

در همون گوگل اگه WPF vs WinForms رو جستجو کنید معایب و مزایای رو تحت عناوین advantages / disadvantages یا pros / cons نوشته میشه. دقت کنید که دنبال مقاله های Why x is better یا Why use x نگردید چون یکطرفه هستند و از اول هدفشون اینه که بگن x بهتره. معروفترین برند ها هم برای تبلیغ محصولاتشون هزینه می کنند، برای همین اینجور مقالات یکطرفه با گرفتن پول نوشته شدن تا چیزی رو تبلیغ کنند.

یه کم بیشتر درباره ی قضیه ی این قاشق و چنگال بیشتر توضیح میدین؟ در واقع ، من هنوز متوجه نشدم که چرا سرعت اجرای کدهای wpf خیلی کمتره؟ آیا دلیل اش همون قضیه ی clr ای که (به نسبت C++ Native) در پست قبل مثال زدم هست؟

در طراحی معماری هر محصولی چه سخت افزاری و چه نرم افزاری یکسری پارامتر هایی هستند که نمیشه همه اونها رو در بهترین حالت حفظ کرد. فقط بحث نرم افزار نیست، مثلا در طراحی جعبه دنده خودرو یا تایر خودرو و ... هم همینطور ئه. اگه سعی کنید یکی از اون پارامتر های رو بهبود بدید ناچار یک مورد دیگه تضعیف میشه. مثلا در Windows Forms نمایش کنترل در همون نخ ای انجام میشه که کنترل رو ساخته، و این نمیتونه همیشه مزیت یا همیشه عیب باشه. در برخی کاربرد ها مزیت میشه و برای برخی کاربرد ها عیب. برعکس در WPF رندر و نمایش در نخ مستقل ای انجام می شه، و این نمیتونه همیشه مزیت یا همیشه عیب باشه. در برخی کاربرد ها مزیت میشه و برای برخی کاربرد ها عیب. اگر x در کاربردی مزیتی داشت حتما در کاربرد دیگری دیگه مزیت نداره. همونطور که زبان سطح بالای #C به لطف NET. و ماشین مجازی اش در توسعه نرم افزار بصورت محسوسی ساده تر و سریعتر از C++ Native نرم افزار رو توسعه میده، اما همون ماشین مجازی در جایی که به دسترسی به سطوح پایینتر باشه یا سرعت اجرای بالایی نیاز باشه تبدیل میشه به عیب.
اینکه C++ Native زبان سطح پایین تری بوده برای طراحی و توسعه نرم افزار های سیستمی مزیت شده اما برای رفع باگ در کد یا زمان لازم برای طراحی و توسعه شده نرم افزار شده عیب.
اینکه C++ Native سرعت اجرای کد بیشتری داشته برای کاربرد هایی که به پردازش زیادی نیاز داشتن شده مزیت اما در عوض دیگه سادگی کار با NET. و ماشین مجازی اش رو نداره.
هیچ راهی نیست که بشه معماری ای رو طراحی کرد که همه پارامتر های مثبت رو یکجا داشته باشه. برنامه نویس اگه پلتفرم رو خوب بشناسه از هر کدوم ویژگی های یک پلتفرم در جایی که مزیت باشه استفاده می کنه و تا جایی که میتونه از کاربرد هایی که مزیت اون پلتفرم نیست اجتناب می کنه.

بعد اینکه میشه با تنظیمات (یا استفاده از اشیاهایی مثلا Freezable و اینها) یا هر روش دیگه، سرعت اجرای کد wpf را زیادتر کرد؟

حالت کلی نداره، هر راه حلی صرفا در جایی مفید واقع میشه که شرایط لازم اون راه حل برقرار باشه، تاثیرش هم همون نسبت بیشتر یا کمتر میشه.
مثلا در مواردی که یک سری اشیاء Freezable بدون نیاز به تغییرات خاصی در حالت modifiable هستند با unmodifiable کردنشون سربار بررسی اون اشیاء کمتر میشه. کمتر شدن سربار میتونه خیلی محسوس باشه یا اصلا تاثیر محسوسی نداشته باشه، بستگی به این داره که چه مقدار اشیاء و با چه نرخ ای درگیر این قضیه باشند. معمولا در کدی که بخوبی نوشته شده باشه سربار بخودی خود کم هست، انتظار معجزه نداریم.

جوری که در این پروژه ای که دادین ، سرعت wpf با winform برابر بشه؟ یا حداقل این اختلاف فاحش را تا حدود زیادی جبران کنه؟

گمون نمی کنم. من روی نقطه قوت Windows Forms که نقطه ضعف WPF بوده یک مثال زدم اما نمیخواستم یک کد بهینه Windows Forms رو با یک غیر بهینه WPF مقایسه کنم.
MyElement رو برای همین ساختم که تا جایی که میسر بود WPF هم بهترین بازدهی رو داشته باشه.
وگرنه طبعا اگر نمایش متن رو به طریق دیگری فرضا اضافه کردن TextBlock انجام میدادم که سرعت اجرای کد WPF فاجعه میشه، البته اونطوری مقایسه منصفانه ای هم نبود.
اینکه شما Brushes.Blue رو Freeze بکنید یا نکنید به هر حال Brushes.Blue یک Brush ئه static سیستمی است و تاثیر اضافه کردن کد های ;()brushes[0].Freeze(); brushes[1].Freeze(); brushes[2].Freeze محسوس نخواهد داشت. نمیشه نقاط ضعف یک پلتفرم رو به سادگی به مزیت شون تبدیل کرد، طراحان پلتفرم ها خودشون تا جایی که میشه اینکار رو انجام می دهند.

کلا دلیل اختلاف بسیار زیاد کد wpf و winform چیه؟

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

آها یعنی به Windows Forms گرافیک برداری میشه داد اما موقع رندر کردن ، اون را بر اساس گرافیک Raster و بیت مپ رندر میکنه؟ و wpf هم برعکس هه؟ البته بیت مپ که به گرافیک برداری تبدیل بشه ، اگه از از اندازه ی اون بیت مپ بزرگتر باشه ، باز هم کیفیت اش کم میشه . درسته؟

Bitmap برای رسم در WPF به بردار تبدیل نمیشه، DirectX فقط بردار رو قبول نمی کنه، Bitmap رو هم میشناسه، خود DirectX تصاویر Bitmap ای رو مستقل از بردار ها رسم می کنه، صرفا برای رسم در ابعاد مورد نیاز تغییر اندازه پیدا میکنه، که البته کیفیتش هم در این پردازش کم میشه.

اگه این طور باشه ، پس باز هم نباید فرق خاصی کنن . مهم نتیجه هست که نتیجه شون با هم یکی میشه . چون گرافیک برداری را به Windows Forms بدیم ، چون برداری هه ، وقتی که به وکتور تبدیل بشه ، اون وکتور گرافیک اصلا افت کیفیت پیدا نمیکنه (چون برای وکتور گرافیک افت کیفیت معنا نداره) .

درسته اما مشکل Windows Forms اینه که اغلب اجزاء گرافیکی اش ذاتا از تصاویر Bitmap تامین میشن، بردار نیستند که کیفیت شون حفظ بشه. بجز فونت ها در سایر موارد به ندرت از بردار در برنامه ها استفاده شده.
ظاهر کنترل های Windows Forms از تم هایی میان که تصویر Bitmap دارند و برای بزرگتر شدن مناسب نیستند.

الان یعنی در wpf ، بیت مپ قبل از رندر ، به وکتور تبدیل میشه؟ اگه این طور باشه کیفیت رندر بیت مپ در wpf نباید چندان تغییری کنه پس چرا بیت مپ و عکس ای را که به عنوان کنترل image در wpf رسم میکنیم ، اگه بزرگش کنیم ، تغییر کیفیت میده؟

نه. این اتفاق صرفا در حالتی پیش میومد که DirectX صرفا بردار رو میشناخت. نه، همچین کاری نمیکنه. WPF تصاویر Bitmap رو بدون تبدیل به بردار نمایش میده.

اون سایت ها ، لینک های زیرن (البته میگم اندکی را هم خودم اضافه کردم) به علاوه حدود 3 تا فیلم ویدئوی انگلیسی که در کامپیوترم دارم اند :

من اون مواردی که خودتون اضافه کرده اید و محل بحث بود رو در اینها نمی بینم. ولی کلا با همین سبک می توانید جستجو کنید و به موارد جدیدی از مقایسه ها برسید.
یک نکته در ابتدا گفتم که برخی مقالات جانبدارانه هستند و جنبه تبلیغاتی دارند که در همون عنوان شون مشخص میشه. ممکنه یکسری مواردشون کاملا درست باشه ولی کلا اگه مقایسه یک جانبه باشه قابل اتکا نیستند.
مثلا این مقاله کاری به این نداره که WPF ممکنه عیبی هم داشته باشه، صرفا میگه WPF این موارد رو داره پس خوبه. طوری نوشته که انگار سایپا داره پراید رو نقد می کنه.
10 reasons why WPF is better than Windows Forms
برعکس این مقاله میخواد بگه چرا از WPF متنفر ئه، الزاما مطالب اشتباهی نیست اما طبعا از مزیت های WPF هم خبری نیست.
5 Reasons why I hate WPF - Simple Talk
از مطلبی که فقط میخواد معایب WPF رو میگه نباید توقع داشته باشید که مقایسه دو طرفه ای بکنه و معایب Windows Forms رو هم بگه
http://aspdotnethelpmaster.blogspot.com/2015/04/disadvantages-of-wpf.html

 

[SajjadKhati]

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

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

        private void Button_Click_4(object sender, RoutedEventArgs e)
        {
            System.Threading.Thread thread = new System.Threading.Thread(new System.Threading.ThreadStart(this.ThreadStart));
            thread.SetApartmentState(System.Threading.ApartmentState.STA);
            thread.Start();
        }

        private void ThreadStart()
        {
            Button button = new Button();
            button.Content = "salam";
            button.HorizontalAlignment = HorizontalAlignment.Left;
            button.VerticalAlignment = VerticalAlignment.Top;
            button.Margin = new Thickness(100, 100, 00, 00);
            button.Width = 500;
            button.Height = 300;

            myGrid1.Children.Add(button);
        }

و ارور زیر :

System.InvalidOperationException: 'The calling thread cannot access this object because a different thread owns it.'

Bitmap برای رسم در WPF به بردار تبدیل نمیشه، DirectX فقط بردار رو قبول نمی کنه، Bitmap رو هم میشناسه، خود DirectX تصاویر Bitmap ای رو مستقل از بردار ها رسم می کنه، صرفا برای رسم در ابعاد مورد نیاز تغییر اندازه پیدا میکنه، که البته کیفیتش هم در این پردازش کم میشه.

درسته اما مشکل Windows Forms اینه که اغلب اجزاء گرافیکی اش ذاتا از تصاویر Bitmap تامین میشن، بردار نیستند که کیفیت شون حفظ بشه. بجز فونت ها در سایر موارد به ندرت از بردار در برنامه ها استفاده شده.
ظاهر کنترل های Windows Forms از تم هایی میان که تصویر Bitmap دارند و برای بزرگتر شدن مناسب نیستند.

نه. این اتفاق صرفا در حالتی پیش میومد که DirectX صرفا بردار رو میشناخت. نه، همچین کاری نمیکنه. WPF تصاویر Bitmap رو بدون تبدیل به بردار نمایش میده.

منظورتون از اجزاء گرافیکی ، اجزایی اند که شکل کنترل ها را میسازند؟
در واقع منظورتون اینه که اجزایی که شکل های کنترل ها و کلا گرافیک را در WinForm میسازن ، از بیت مپ ساخته شدن و بیت مپ ها هم که اندازه ی مشخصی دارند و پس اگه اندازه ی کنترل هایی که در WinForm میسازیم ، از اندازه ی اجزای اصلی شون بزرگتر بشن ، کیفیت شون پایین تر میاد؟ درسته؟
اندازه ی اجزاشون رو میدونین چقدره؟ (طول و عرضش)؟

من اون مواردی که خودتون اضافه کرده اید و محل بحث بود رو در اینها نمی بینم. ولی کلا با همین سبک می توانید جستجو کنید و به موارد جدیدی از مقایسه ها برسید.
یک نکته در ابتدا گفتم که برخی مقالات جانبدارانه هستند و جنبه تبلیغاتی دارند که در همون عنوان شون مشخص میشه. ممکنه یکسری مواردشون کاملا درست باشه ولی کلا اگه مقایسه یک جانبه باشه قابل اتکا نیستند.
مثلا این مقاله کاری به این نداره که WPF ممکنه عیبی هم داشته باشه، صرفا میگه WPF این موارد رو داره پس خوبه. طوری نوشته که انگار سایپا داره پراید رو نقد می کنه.
10 reasons why WPF is better than Windows Forms
برعکس این مقاله میخواد بگه چرا از WPF متنفر ئه، الزاما مطالب اشتباهی نیست اما طبعا از مزیت های WPF هم خبری نیست.
5 Reasons why I hate WPF - Simple Talk
از مطلبی که فقط میخواد معایب WPF رو میگه نباید توقع داشته باشید که مقایسه دو طرفه ای بکنه و معایب Windows Forms رو هم بگه
http://aspdotnethelpmaster.blogspot.com/2015/04/disadvantages-of-wpf.html

اما استاد من هنوز سئوال اصلی ام که این بود اگه اشتباهی در اون 12 مورد بود را ویرایش کنین (بی زحمت) ، هنوز جواب نگرفتم .
الان فقط مشکلات را گفتین . من الان مثلا متوجه شدم که موارد 2 و 3 ، مشکل دارن . ولی نمیدونم برای تصحیح شون چی بنویسم؟ یا اصلا کلا این دو را حذف کنم؟ همچنین موارد دیگه .
بی زحمت اون 12 مورد هر جا اشکال داشت و اگه قابل اصلاح بود ، متن درست اش را میگید بجاش چی بنویسم؟
همچنین متن معایب wpf نسبت به WinForm را هم میگید؟
اگه مورد جدیدی هم به نظرتون هست ، بهم بگید اضافه کنم .
تشکر

 

[the_king]

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

        private void Button_Click_4(object sender, RoutedEventArgs e)
        {
            System.Threading.Thread thread = new System.Threading.Thread(new System.Threading.ThreadStart(this.ThreadStart));
            thread.SetApartmentState(System.Threading.ApartmentState.STA);
            thread.Start();
        }

        private void ThreadStart()
        {
            Button button = new Button();
            button.Content = "salam";
            button.HorizontalAlignment = HorizontalAlignment.Left;
            button.VerticalAlignment = VerticalAlignment.Top;
            button.Margin = new Thickness(100, 100, 00, 00);
            button.Width = 500;
            button.Height = 300;

            myGrid1.Children.Add(button);
        }

و ارور زیر :

System.InvalidOperationException: 'The calling thread cannot access this object because a different thread owns it.'

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

منظورتون از اجزاء گرافیکی ، اجزایی اند که شکل کنترل ها را میسازند؟

بله. بطور مشخص آیکون ها، Windows Theme که ظاهر دکمه و اسکرول بار و ... نشون میده.

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

بله. دو سه تا عدد ثابت نیست که از من میپرسید. در هر تم ای اندازه هر جزء بصورت مجزا مشخص شده.
https://linkgish.blogspot.com/2015/09/make-your-windows-7-own-theme-with.html

اما استاد من هنوز سئوال اصلی ام که این بود اگه اشتباهی در اون 12 مورد بود را ویرایش کنین (بی زحمت) ، هنوز جواب نگرفتم .

من هر چیزی که لازم بود بگم در موردشون گفتم، حتی هر کدوم که مبهم بود ازتون توضیح هم خواستم که توضیحی ندادید. من هم جواب نگرفتم. ازتون پرسیدم وجود Routed Event چی رو بهبود داده؟ توضیح ندادید.
پرسیدم کارایی بهینه تر یعنی چی رو بهینه کرده؟ توضیح ندادید. پرسیدم سیستم Resource چی رو بهینه و قویتر کرده؟ توضیح ندادید. من قرار نیست ویراستار شما باشم. به سوالات تون جواب میدم ولی جواب سوالات من رو نمیدید.

الان فقط مشکلات را گفتین . من الان مثلا متوجه شدم که موارد 2 و 3 ، مشکل دارن . ولی نمیدونم برای تصحیح شون چی بنویسم؟ یا اصلا کلا این دو را حذف کنم؟ همچنین موارد دیگه .

چیزی که اشتباه ئه رو فقط باید حذف کنید، ویرایش کردنش مشکلی رو حل نمی کنه. اون دو تا مورد 2 و 3 رو اگه می توانید برای درستی اش استدلال منطقی داشته باشید که هیچ نگه دارید ولی اگه میبینید ایراد داره، مثال نقض داره، قابل اثبات نیست و ... باید حذف بشه. ویرایش فایده نداره. من مواردی که ابهام داشت رو تک به تک ازتون پرسیدم که اگه برایش دلیل دارید مشخص بشه، هنوز دلیل منطقی ای ازتون نشنیدم اما مهم این نیست که من رو قانع کنید، من یک نفر ام. مهم اینه که چیزی رو بیان کنید که قابل دفاع باشه. هر کسی زیر سوالش ببره بتوانید جواب قانع کننده بدهید. اینکه بگید اینها جزو اشیاء ما نیستند یا اکثرشون با فلان قضیه مشکلی ندارند که دفاع نیست.

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

 

[SajjadKhati]

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

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

من هر چیزی که لازم بود بگم در موردشون گفتم، حتی هر کدوم که مبهم بود ازتون توضیح هم خواستم که توضیحی ندادید. من هم جواب نگرفتم. ازتون پرسیدم وجود Routed Event چی رو بهبود داده؟ توضیح ندادید.
پرسیدم کارایی بهینه تر یعنی چی رو بهینه کرده؟ توضیح ندادید. پرسیدم سیستم Resource چی رو بهینه و قویتر کرده؟ توضیح ندادید. من قرار نیست ویراستار شما باشم. به سوالات تون جواب میدم ولی جواب سوالات من رو نمیدید.


چیزی که اشتباه ئه رو فقط باید حذف کنید، ویرایش کردنش مشکلی رو حل نمی کنه. اون دو تا مورد 2 و 3 رو اگه می توانید برای درستی اش استدلال منطقی داشته باشید که هیچ نگه دارید ولی اگه میبینید ایراد داره، مثال نقض داره، قابل اثبات نیست و ... باید حذف بشه. ویرایش فایده نداره. من مواردی که ابهام داشت رو تک به تک ازتون پرسیدم که اگه برایش دلیل دارید مشخص بشه، هنوز دلیل منطقی ای ازتون نشنیدم اما مهم این نیست که من رو قانع کنید، من یک نفر ام. مهم اینه که چیزی رو بیان کنید که قابل دفاع باشه. هر کسی زیر سوالش ببره بتوانید جواب قانع کننده بدهید. اینکه بگید اینها جزو اشیاء ما نیستند یا اکثرشون با فلان قضیه مشکلی ندارند که دفاع نیست.

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

الان استاد ، من موارد را بصورت زیر ویرایش کردم . بی زحمت دوباره چک میکنید ؟ :

مزایای WPF نسبت به Windows Form :


1) تغییر ظاهر کنترل ها به هر شکل دلخواه توسط Template ها بدون اینکه منطق کنترل تحت تاثیر قرار بگیره.

این ، یکی از مهم ترین قابلیت های WPF به شمار میره که باعث میشه نیاز به استفاده از کنترل ها و کمپوننت های شرکت های دیگه (مثل Telerik و ...) نشه یا بصورت چشمگیری کم بشه .


2) استفاده از افکت ها (مثل تار کردن و افکت های دیگه) و خصوصیات بیشتر برای کنترل ها نسبت به WinForm .

قابلیت های متنوع و پیشرفته مثل تنظیم چرخش ، شفافیت ، Mask ، Skew ، Command در کنترل ها و ... .


3) ایجاد تم و اسکین (Theme & Skin) توسط Style .


- در WinForm ، اندکی کدنویسی بیشتر و زمان بیشتری را برای نوشتن کد لازم داره.


4) انیمیشنی و متحرک کردن کنترل ها .


5) استفاده از Vector Graphic برای رسم اجزاء گرافیکی (اجزاء تشکیل دهنده ی کنترل ها و ...) که باعث میشه با بزرگتر یا کوچیکتر شدنِ رسم شی گرافیک های برداری ، کیفیت رسم اش کمتر نشه و تغییری نکنه .


- WinForm ، از Raster Graphic یا همون Bitmap برای رسم اجزای گرافیکی اش (مثل اجزاء کنترل ها) استفاده میکنه که ابعاد محدودی داره و با بزرگتر کردن ، باعث کم شدن کیفیت میشه .


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


7) از رابط کاربری DirectX برای ترسیمات و رندر استفاده میکنه که باعث میشه از کارت گرافیک برای رندر به کار گرفته بشه .


- WinForm از رابط GDI+ برای ترسیمات استفاده میکنه .


8) بصورت Resolution Independent و مستقل از ریزولیشن عمل میکنه .


9) Binding بهینه تر نسبت به WinForm



10) ایجاد اشیاء 3 بعدی

سیستم پشتیبانی از چند رسانه ای (صوت و تصویر) built-in

امنیت بیشتر

مهاجرت راحت تر به .Net Core

و ... .





معایب WPF نسبت به Windows Form :


1) استفاده از منابع بیشترِ سخت افزار


2) کندی اجرای کدها





ویژگی های WPF نسبت به Windows Form :


1) استفاده از XML در طراحی رابط کاربری :

- باعث جدا کردن طراحی رابط کاربری از منطق تجاری میشه .

فایده اش اینه که طراح رابط کاربری با برنامه نویسی منطق تجاری میتونه جدا از هم بصورت همزمان انجام بشه .


- قابلیت Content محور و تو در تو بودن XML ، باعث سادگی درک رابطه ی کدنویسی با رابط کاربری (که بصورت درختی هستند) میشه .


2) استفاده از MVVM Pattern

تشکر