باید کدتون رو بررسی کنید و ببینید با چی تداخل داره چون مشکلی در WidthProperty نیست. من نمیتونم کد ناقص شما رو اجرا کنم، خودتون باید در پروژه بررسی اش کنید. اما میتونم در مثال ساده خودم ببینم که WidthProperty مشکلی نداره :
C#:
private void Button_Click(object sender, RoutedEventArgs e)
{
var style = new Style(typeof(MyWindow));
var setter = new Setter(MyWindow.MyBackgroundProperty, Brushes.Red);
style.Setters.Add(setter);
var w = new MyWindow() { Height = 200 };
var setter2 = new Setter(MyWindow.WidthProperty, 200d);
style.Setters.Add(setter2);
w.Style = style;
w.MyBackground = Brushes.Yellow;
w.ShowDialog();
}
سلامی مجدد
خیلی ممنون استاد .
دوباره رفتم سراغ پروژه (ان شاء ا... احتمالا این پروژه را با انرژی کمتری ادامه میدم ولی بیشترِ تمرکزم را روی آموزش میخوام بذارم) .
مشکلش این بود که در پنجره ی AlarmWindow ، پروپرتیِ SizeToContent اش را به WidthAndHeight سِت کرده بودم و باعث میشد که Width و Height ئه پنجره را بصورت اتوماتیک ، به اندازه ی محتوای پنجره سِت کنه .
تشکر استاد .
سلامی مجدد
استاد ، اینکه میگن یکی از ویژگی های wpf اینه که طراح ، طراحیِ برنامه را انجام میده و همزمان برنامه نویس هم بخش منطق تجاری اش را میتونه انجام بده ، صرفا بخاطر این نیست که در wpf ، از xaml استفاده میشه . درسته؟
بلکه بخش عمده ی این ویژگی (جدا بودن منطق تجاری از view) ، بخاطر اینه که اگه از معماریِ mvvm در اون پروژه استفاده بشه ، این قابلیت را (حداقل بصورت کامل) خواهد داشت . درسته؟
یعنی صِرف اینکه از xaml در wpf (بدون معماری mvvm) استفاده میشه ، حداقل بصورت کامل این قابلیتِ همزمانیِ طراحی view و منطق تجاری ، وجود نداره (شاید بخشی از این قابلیت ، بدون پیاده سازی معماری mvvm وجود داشته باشه ، اما کامل نمیشه انجام داد) . درسته؟
تشکر استاد .
سلامی مجدد
استاد ، اینکه میگن یکی از ویژگی های wpf اینه که طراح ، طراحیِ برنامه را انجام میده و همزمان برنامه نویس هم بخش منطق تجاری اش را میتونه انجام بده ، صرفا بخاطر این نیست که در wpf ، از xaml استفاده میشه . درسته؟
بلکه بخش عمده ی این ویژگی (جدا بودن منطق تجاری از view) ، بخاطر اینه که اگه از معماریِ mvvm در اون پروژه استفاده بشه ، این قابلیت را (حداقل بصورت کامل) خواهد داشت . درسته؟
یعنی صِرف اینکه از xaml در wpf (بدون معماری mvvm) استفاده میشه ، حداقل بصورت کامل این قابلیتِ همزمانیِ طراحی view و منطق تجاری ، وجود نداره (شاید بخشی از این قابلیت ، بدون پیاده سازی معماری mvvm وجود داشته باشه ، اما کامل نمیشه انجام داد) . درسته؟
تشکر استاد .
گفته که برای ارتباط نخ جدیدی که ساختیم با نخ ui thread (نخی که کنترل ها و المنت هامون را توش ساختیم) و برای آپدیت کردن (و دسترسی) به المنت ها در ui thread ، از طریق نخِ دیگه ، باید از اعضای dispatcher ئه اون کنترل و المنت استفاده کنیم (متد invoke در dispatcher) .
اما در مثال های زیرِ اون خط که اصلا نخ ای نساخت . صرفا از دلیگیت action (در متد invoke) استفاده کرد که همونطور که معلومه ، صرفا دلیگیت هست . شیِ جدیدِ thread ای نمیشه برای این دلیگیت ساخت تا از اون نخ ، به اعضای کنترل های ui thread مون دسترسی داشته باشیم .
در واقع کد زیر :
C#:
this.Dispatcher.Invoke(() => {
Login();
});
ای که نوشت ، نخ جدیدی براش ساخته نشد . در واقع در همون نخ ui thread اجرا میشه .
پس با این حال ، چرا همچین جمله ای را در بالا (که نقل قول کردم) نوشت؟!
تشکر استاد .
Dispatcher is used to manage multithreaded application. It manages Message queues.
www.c-sharpcorner.com
گفته که برای ارتباط نخ جدیدی که ساختیم با نخ ui thread (نخی که کنترل ها و المنت هامون را توش ساختیم) و برای آپدیت کردن (و دسترسی) به المنت ها در ui thread ، از طریق نخِ دیگه ، باید از اعضای dispatcher ئه اون کنترل و المنت استفاده کنیم (متد invoke در dispatcher) .
اما در مثال های زیرِ اون خط که اصلا نخ ای نساخت . صرفا از دلیگیت action (در متد invoke) استفاده کرد که همونطور که معلومه ، صرفا دلیگیت هست . شیِ جدیدِ thread ای نمیشه برای این دلیگیت ساخت تا از اون نخ ، به اعضای کنترل های ui thread مون دسترسی داشته باشیم .
در واقع کد زیر :
C#:
this.Dispatcher.Invoke(() => {
Login();
});
ای که نوشت ، نخ جدیدی براش ساخته نشد . در واقع در همون نخ ui thread اجرا میشه .
پس با این حال ، چرا همچین جمله ای را در بالا (که نقل قول کردم) نوشت؟!
خیلی ممنون استاد .
یعنی ممکنه اشتباه یا بدون تحقیق کافی نوشته باشن؟
اعتبار هر مقاله در سایت های این چنینی را نمینویسن که مثلا چقدر معتبره؟
چون سایت c-sharpcorner.com ، خیلی از مطالب خوب و آموزش های خوبی ارائه داده .
----------------------
همون انگار مثل قضیه ی Invoke (که بصورت همگام فراخونی میکنه) و BeingInvoke (که بصورت همزمان فراخونی میکنه) در کلاس Control در winform هست .
انگار کارکردش اینه که این متدها ، از درون نخِ دیگری باید فراخونی بشن (که در مثال لینک بالا ، از نخِ خودش که ui thread هست ، فراخونی کرده که در این صورت ، انگار کاربردی نداره) .
نه. ممکنه مثال اش برای موضوعی که میخواد توضیح بده مثال مناسبی نباشه. من هم ممکنه برای موضوعی یک مثال بنویسم که بعدا ببینم برای اون موضوع مثال بهتری هم بوده، یا اصلا مثال درستی نبوده و گمراه کننده است.
مساله فردی ئه، ممکنه در یک سایت صد نفر مطلب بنویسند که یکسری شون معلومات بیشتری دارند و یکسری شون معلومات کمتر. هر کسی ممکنه اشتباه کنه. اون چیزی که بیشتر اهمیت داره اینه که مطالب بازبینی بشه، رویش نظارت بشه، که اگر اشتباهی هست تصحیح بشه، اگر نواقصی هست تکمیل بشه.
من الان اگر چیزی در مجید آنلاین بنویسم و اشتباه باشه کی درستش می کنه؟ هیچکسی. فرق می کنه با مطالبی که در سایت مایکروسافت یا حتی ویکی پدیا هست، که حتی کاربر میتونه ایرادی که شناسایی کرد رو Edit کنه، ایراد رو برطرف کنه که اینها بعدا بازبینی میشه. مایکروسافت چرا مایکروسافت شده؟ چون حتی از بازدید کننده اش کمک می گیره تا مطالب تکمیل بشه. ازتون Review میگیره که آیا این پاسخ مفید بود یا نه. مطلبی که آمار بازخورد خوبی نداشته بازبینی می کنه.
خیلی ممنون استاد
خوب اگه رندر در نخ مجزایی انجام میشه ، پس چرا مشکل با ایجاد کردنِ کنترل در نخ مجزا را داره؟
چون اگه اشتباه نکنم ، عاملی که باعث میشه با کنترل ها در نخ مجزا مشکل پیدا کنه ، رسم و رندر کنترل هست دیگه ؟
وگرنه برای ایجاد اغلب قریب به اتفاقِ اشیاهای دیگه بجز کنترل ها و اشیاء های گرافیکی ، در نخ های دیگه که مشکلی نیست .
الان استاد ، من موارد را بصورت زیر ویرایش کردم . بی زحمت دوباره چک میکنید ؟ :
مزایای WPF نسبت به Windows Form :
1) تغییر ظاهر کنترل ها به هر شکل دلخواه توسط Template ها بدون اینکه منطق کنترل تحت تاثیر قرار بگیره.
این ، یکی از مهم ترین قابلیت های WPF به شمار میره که باعث میشه نیاز به استفاده از کنترل ها و کمپوننت های شرکت های دیگه (مثل Telerik و ...) نشه یا بصورت چشمگیری کم بشه .
.
.
تشکر
سلامی مجدد استاد .
استاد ، منابع بیشتری را بررسی کردم ، لیست مزایا و معایب و ویژگی های wpf را مجددا نوشتم .
کلا بیش از 90 درصد اینها ، ترجمه ی مستقیم یا مفاهیم منابع هست (که حالا یکی دو تاشو میذارم . چون زیادن و بیش از 10 تا لینک هستن) . چیزهایی که خودم اضافه کردم ، معمولا به عنوان توضیحات اضافی تر هستن .
اما استاد ، شخصا بعضی از مطالب از بعضی از این سایت های انگلیسی را دیدم ، شخصا حداقل حس میکنم که در بعضی موارد ، مطالبی را اشتباهی گفتن . گاها ، اشتباه واضحی بود (که البته من اونها را نیاوردم) .
======================
حالا استاد چک میکنین که چیزهایی که نوشتم ، درستن؟ :
مزایای WPF نسبت به Windows Form :
1) با پیاده سازی معماری MVVM در پروژه ، منطق تجاری با رابط کاربری ، از هم جدا میشن و به این ترتیب ، برنامه نویس میتونه منطق تجاری برنامه ، و طراح میتونه ظاهر کاربری برنامه را همزمان با هم انجام بدن .
همچنین این معماری ، قابلیت نگهداری و به روزرسانی و unit testing برنامه را بسیار بهبود میبخشه .
بخاطر Binding بهتر و استفاده از Command ها در WPF ، پیاده سازی معماری MVVM در WPF ، راحت تر از پیاده سازی این معماری در WinForm هست .
2) WPF ، یک سیستم نمایش قابل ترکیب هست . یعنی اغلب المنت هاش میتونن از ترکیب شدن توسط المنت های دیگه ، تشکیل بشن .
مثلا یک ComboBox ، ترکیبی از المنت TextBox و المنت Popup هست که هر کدوم از این دو المنت ، مجددا ترکیبی از المنت های دیگه میتونن باشن .
3) استفاده از Template ها که مدل انعطاف پذیر برای ساختن رابط کاربری را ارائه میکنه .
4) ایجاد تم و اسکین (Theme & Skin) توسط Style .
5) استفاده از افکت ها (مثل تار کردن و افکت های دیگه) و خصوصیات بیشتر برای کنترل ها نسبت به WinForm .
قابلیت های متنوع و پیشرفته مثل تنظیم چرخش ، شفافیت ، Mask ، Skew در کنترل ها و ... .
6) انیمیشنی و متحرک کردن کنترل ها .
7) استفاده از Vector Graphic برای رسم اجزاء گرافیکی (اجزاء تشکیل دهنده ی کنترل ها و ...) که باعث میشه با بزرگتر یا کوچیکتر شدن (نسبت به رسم شی گرافیک های برداری) ، کیفیت رسم اش کمتر نشه و تغییری نکنه .
- WinForm ، از Raster Graphic یا همون Bitmap برای رسم اجزای گرافیکی اش (مثل اجزاء کنترل ها) استفاده میکنه که ابعاد محدودی داره و با بزرگتر کردن (از حداکثرِ ابعادش) ، باعث کم شدن کیفیت میشه .
8) از رابط کاربری DirectX برای ترسیمات و رندر استفاده میکنه که باعث میشه از کارت گرافیک برای رندر به کار گرفته بشه .
- WinForm از رابط GDI+ برای ترسیمات استفاده میکنه .
9) بصورت Resolution Independent و مستقل از ریزولیشن عمل میکنه . به این معنا که اگه تنظیمات ریزولیشن و همچنین تنظیماتِ dpi در هر مانیتوری ، روی مقدارِ پیش فرضِ همون مانیتور تنظیم شده باشه ، در این صورت ، اندازه ی پنجره های WPF ، در مانیتورهای مختلف ، یکسان میشه .
10) چیدمان (Layout) منعطف تر
سفارشی کردن راحت تر المنت ها و کنترل ها
ابزارهای بیشتر برای debugging کردن . مثل Xaml Hot Reload و Live Visual Tree و ... .
سرعت بیشتر و صرف زمان کمتر برای طراحی ظاهر کاربری دلخواه
ایجاد اشیاء 3 بعدی
سیستم پشتیبانی از چند رسانه ای (صوت و تصویر) built-in
مهاجرت راحت تر به .Net Core
و ... .
-------------------------------
معایب WPF نسبت به Windows Form :
1) استفاده از منابع بیشترِ سخت افزار
2) بخاطر جدا بودنِ نخِ رسم کننده ی کنترل ها در WPF (و بخاطر هماهنگیِ کمتر نسبت به یک نخ و همچنین سربارِ بیشترِ نخ مجزا) ، بعد از ارسال درخواستِ رسمِ کنترل ، تاخیرِبیشتری نسبت به Win Form برای رسم کنترل ها وجود دارد .
3) کنترل هایی که مایکروسافت برای WPF طراحی کرد ، گاها نسبت به WinForm ، کمتر هست . مثل کنترل NumericUpDown و NotifyIcon و ... .
برای استفاده از این نوع کنترل ها در WPF ، باید از کمپوننت های مجزا استفاده کرد .
4) مدت زمان یادگیری WPF ، بیشتر از WinForm به طول میانجامد .
- قابلیت Content محور و تو در تو بودن XML ، باعث سادگی درک رابطه ی کدنویسی با رابط کاربری (که بصورت درختی هستند) میشه .
- XAML ، زبانی برای توصیف هست . یکی از موارد کاربردش ، برای توصیف المنت ها و کنترل های رابط کاربری هست . به این توصیف محور بودن ، Declarative Code یا Declarative Syntax میگن .
کدهای XAML ، نسبت به کدهای سی شارپ ، فشرده و جمع و جورتر هست .
If you have not taken a look at Windows Presentation Foundation (WPF) yet, you really should. WPF is a great desktop development platform. Granted, all of the tools are not yet in place, but Micros...
www.codemag.com
منابع ، زیادتر از اینهان . ولی چندتاش را دادم .
======================================
اون گزینه ی "سرعت بیشتر و صرف زمان کمتر برای طراحی ظاهر کاربری دلخواه" که قبلا باهاش مخالف بودین ، منظورم را که گفته بودم . منظورم ، طراحی 2 کنترلی که دقیقا شبیه به همدیگه باشن که هم در winform و هم در wpf بخواد طراحی بشه ، هست .
بعد اینکه استاد ، در همه ی مطالبی که درباره ی مزایا و معایب (cons و pros و همچنین advantage و disadvantage) ئه wpf جستجو کردم ، همه ی مطالب را توی همین زیر مجموعه ی "مزایا و معایب" ، لیست کردن .
یعنی "ویژگی های wpf" را که قبلا گفته بودید مثل xaml که چون winform ، از xaml استفاده نمیکنه ، این نوع مطالب را در زیر مجموعه ی مطلبِ "ویژگی های wpf" بذارم ، اون سایت ها ، مطالب xaml را در زیر مجموعه ی مزایا و معایب wpf گذاشتن .
1) با پیاده سازی معماری MVVM در پروژه ، منطق تجاری با رابط کاربری ، از هم جدا میشن و به این ترتیب ، برنامه نویس میتونه منطق تجاری برنامه ، و طراح میتونه ظاهر کاربری برنامه را همزمان با هم انجام بدن .
مزایای استفاده از MVVM که نمیتونه تحت مزایای WPF نوشته بشه، MVVM که مختص WPF نیست. در هر پلتفرمی MVVM بکار برده بشه مزایای MVVM سر جاشون هست، اما جزو مزایای اون پلتفرم حساب نمیشه.
مزیت نیست، یک ویژگی ئه، برتری ایجاد نمی کنه. در WPF برای مشخص کردن Theme & Skin از Style استفاده میشه، معنی اش این نیست که در Windows Forms چیزی تحت عنوان Theme & Skin نبوده. در Windows Forms هم به روش های دیگری Theme & Skin مشخص میشه.
مقایسه درستی نیست. انواع کنترل ها متفاوت هست با قابلیت ها و محدودیت های کم و زیاد که ربطی به WPF یا WinForm بودن ندارند. شما می توانید کنترل x رو با y مقایسه کنید یا مجموعه کنترل های A رو با B مقایسه کنید اما نمی توانید نتیجه مقایسه رو به مقایسه پلتفرم ها تعمیم بدهید.
مزیت نیست، ویژگی ئه. یک نفر با تاکسی میره یک نفر دیگه با اتوبوس. هم تاکسی و هم اتوبوس مزایا و معایب خودشون رو دارند. اینکه کسی از اتوبوس استفاده کرده نمیتونه مزیت خالص یا فقط عیب باشه.
مزایای استفاده از MVVM که نمیتونه تحت مزایای WPF نوشته بشه، MVVM که مختص WPF نیست. در هر پلتفرمی MVVM بکار برده بشه مزایای MVVM سر جاشون هست، اما جزو مزایای اون پلتفرم حساب نمیشه.
Developer documentation for all DevExpress products.
docs.devexpress.com
بله. این درسته.
در Windows Forms هم همینه. این منحصر به WPF نیست که بخواهید تحت عنوان مزیت مطرحش کنید.
مزیت نیست، یک ویژگی ئه، برتری ایجاد نمی کنه. در WPF برای مشخص کردن Theme & Skin از Style استفاده میشه، معنی اش این نیست که در Windows Forms چیزی تحت عنوان Theme & Skin نبوده. در Windows Forms هم به روش های دیگری Theme & Skin مشخص میشه.
مقایسه درستی نیست. انواع کنترل ها متفاوت هست با قابلیت ها و محدودیت های کم و زیاد که ربطی به WPF یا WinForm بودن ندارند. شما می توانید کنترل x رو با y مقایسه کنید یا مجموعه کنترل های A رو با B مقایسه کنید اما نمی توانید نتیجه مقایسه رو به مقایسه پلتفرم ها تعمیم بدهید.
مزیت نیست، ویژگی ئه. یک نفر با تاکسی میره یک نفر دیگه با اتوبوس. هم تاکسی و هم اتوبوس مزایا و معایب خودشون رو دارند. اینکه کسی از اتوبوس استفاده کرده نمیتونه مزیت خالص یا فقط عیب باشه.
چرا استاد؟
وقتی عنوانِ ۲ موضوع را مخلوط کردم ، توضیحاتش را هم میشه مخلوط کنم دیگه .
اون سایت های انگلیسی اصلا عنوانِ ویژگی wpf را ننوشتن . همه را تحت مزایا نوشتن (حداقل ، اغلب شون این طور کردن. اما تا جایی که یادم میاد ، کسی جدا نکرده بود) .
حالا اشتباه اونها را کاری ندارم .
ولی من که عنوانِ هر دو را مخلوط کردم ، پس میتونم توضیحات هر دو رو مخلوط کنم و این که اشتباه نیست .
این جوری ، جمع و جورتر میشه .
نهایتا اینکه شاید توی توضیحات بگم که کدوم یک از اینها ، مربوط به ویژگی هه .
تشکر استاد .
دو مورد از یک جنس رو میشه مخلوط کرد، نه از دو جنس متفاوت. اگر مزایا و ویژگی ها از یک جنس بودند میشد مخلوط شون کرد، اما نیستند.
مثلا دو میوه رو مقایسه می کنید، یکی اش ویتامین هاش بیشتر ئه، این بیشتر بودن ویتامین رو به عنوان مزیت نسبت به اون یکی می نویسید، نسبت به اون یکی، نه هر میوه ای، ممکنه یک میوه دیگه باشه که نسبت به اون ویتامین کمتری داشته باشه و بجای مزیت عیب باشه. مزیت نسبی ئه.
ولی ویژگی ها نسبت به چیز دیگری نیست، به مقایسه با موردی وابسته نیست، مثلا این میوه قرمز ئه، قرمز بودن نسبت به چیزی سنجیده نمیشه.
فرضا من برای شما مزایا سیب سرخ نسبت به موز و ویژگی های سیب رو درهم می نویسم، شیرین، قرمز، سرشار از ویتامین A، گرد و ... شما از گرد بودن و قرمز بودن سیب چه نتیجه ای باید بگیرید؟ که سیب بهتر از موز ئه؟ اگر مربع بود بهتر بود؟ از مطلبی که ویژگی و مزایا از هم تفکیک نشده چطور برداشت می کنید؟ باید نتیجه بگیرید که +GDI یا DirectX خوب هستند یا بد؟ اگر خواننده نتیجه گرفت که استفاده از DirectX رو به عنوان مزیت نوشته اید درست برداشت کرده یا وقتی به عنوان ویژگی در نظر گرفت؟ بر چه اساسی باید تشخیص بده؟
اون سایت های انگلیسی اصلا عنوانِ ویژگی wpf را ننوشتن . همه را تحت مزایا نوشتن (حداقل ، اغلب شون این طور کردن. اما تا جایی که یادم میاد ، کسی جدا نکرده بود) .
وقتی چیزی بنویسید که روی نتیجه گیری خواننده تاثیر مخرب داشته باشه کار اشتباهی کردید. به نظر من کاری نداشته باشید. کلی قضاوت کنید که اگر مطلبی رو طوری بنویسید که احتمال نتیجه گیری اشتباه ازش هست، کار تون درست ئه، یا اشتباه. من میخواهم بدونم که مزایای شیر نسبت به آب چیه، شما بین مزایا توضیح می دهید که شیر سفید ئه به دلیل فلان ترکیبات. من اگر برداشت کنم که این سفید بودن مزیت ئه، من رو گمراه کرده اید، به اشتباه انداخته اید.
این چه منطقی ئه، شما اگر همه پاراگراف ها رو یکی کنید یا بجز جملات کلیدی بقیه رو حذف کنید قطعا جمع و جور تر میشه، اما به چه قیمتی؟ هدف اصلی جمع و جور شدن مطلب ئه یا انتقال درست مطلب؟
دو مورد از یک جنس رو میشه مخلوط کرد، نه از دو جنس متفاوت. اگر مزایا و ویژگی ها از یک جنس بودند میشد مخلوط شون کرد، اما نیستند.
مثلا دو میوه رو مقایسه می کنید، یکی اش ویتامین هاش بیشتر ئه، این بیشتر بودن ویتامین رو به عنوان مزیت نسبت به اون یکی می نویسید، نسبت به اون یکی، نه هر میوه ای، ممکنه یک میوه دیگه باشه که نسبت به اون ویتامین کمتری داشته باشه و بجای مزیت عیب باشه. مزیت نسبی ئه.
ولی ویژگی ها نسبت به چیز دیگری نیست، به مقایسه با موردی وابسته نیست، مثلا این میوه قرمز ئه، قرمز بودن نسبت به چیزی سنجیده نمیشه.
فرضا من برای شما مزایا سیب سرخ نسبت به موز و ویژگی های سیب رو درهم می نویسم، شیرین، قرمز، سرشار از ویتامین A، گرد و ... شما از گرد بودن و قرمز بودن سیب چه نتیجه ای باید بگیرید؟ که سیب بهتر از موز ئه؟ اگر مربع بود بهتر بود؟ از مطلبی که ویژگی و مزایا از هم تفکیک نشده چطور برداشت می کنید؟ باید نتیجه بگیرید که +GDI یا DirectX خوب هستند یا بد؟ اگر خواننده نتیجه گرفت که استفاده از DirectX رو به عنوان مزیت نوشته اید درست برداشت کرده یا وقتی به عنوان ویژگی در نظر گرفت؟ بر چه اساسی باید تشخیص بده؟
تجربه های قبلی تون نشون داده که باید موردی بررسی بشه. من نمیدونم در مورد کدوم مطلب اینو میگید.
وقتی چیزی بنویسید که روی نتیجه گیری خواننده تاثیر مخرب داشته باشه کار اشتباهی کردید. به نظر من کاری نداشته باشید. کلی قضاوت کنید که اگر مطلبی رو طوری بنویسید که احتمال نتیجه گیری اشتباه ازش هست، کار تون درست ئه، یا اشتباه. من میخواهم بدونم که مزایای شیر نسبت به آب چیه، شما بین مزایا توضیح می دهید که شیر سفید ئه به دلیل فلان ترکیبات. من اگر برداشت کنم که این سفید بودن مزیت ئه، من رو گمراه کرده اید، به اشتباه انداخته اید.
این چه منطقی ئه، شما اگر همه پاراگراف ها رو یکی کنید یا بجز جملات کلیدی بقیه رو حذف کنید قطعا جمع و جور تر میشه، اما به چه قیمتی؟ هدف اصلی جمع و جور شدن مطلب ئه یا انتقال درست مطلب؟
We explain the principles of user experience design and how to make sure you offer the best experience for your users
www.itproportal.com
عنوانش اینه که "چرا wpf بهتر از winform هست؟"
در بند 8 تا 10 اش اومد مزیت های xaml (به عنوان اینکه xaml در طراحیِ ui ئه wpf استفاده میشه) نام برد .
اما شما تا جایی که اشتباه نکنم ، گفته بودید که چون xaml به عنوان طراحی ui در winform استفاده نمیشه پس نباید مقایسه کرد و جزء ویژگی های wpf هست .
هر چند نظرتون را در این زمینه ، تا حدی قبول دارم اما نظر من تقریبا یه چیز دیگه هست . الان فرضا ، فرض کنید که در هواپیماهای جنگنده ی نسل های اخیر ، از موتور جت استفاده میشه . اما موتور هواپیماهای جنگنده ی 100 سال قبل یا بیشتر ، موتور ملخی بود . قطعا هم خیلی از قطعاتی در موتور جت بکار رفته که در موتورهای ملخی نبوده .
این باعث نمیشه که بگیم وقتی میخوایم هواپیمای ملخی با هواپیماهای جت را با هم مقایسه کنیم ، موتور شون را با هم مقایسه نکنیم (و صرفا موتور هواپیمای جت را جزء ویژگی هایش به شمار بیاریم) چون خیلی از قطعات موتور جت ، در موتور ملخی وجود نداره یا حداقل اون قطعاتی که در موتور ملخی وجود نداره اما در موتور جت وجود داره را نباید تحت عنوان مقایسه کردن ، به شمار بیاریم .
---------------------------------------
اصلا یه چیز دیگه . اینکه بیام عنوانش را بجای مزیت و ویژگی wpf ، یه عنوان دیگه بگیرم . مثل این :
If you have not taken a look at Windows Presentation Foundation (WPF) yet, you really should. WPF is a great desktop development platform. Granted, all of the tools are not yet in place, but Micros...
www.codemag.com
عنوانش این باشه که "چرا از wpf استفاده کنیم؟"
چطوره؟
با این عنوان هم میشه همه ی مزیت ها و ویژگی ها را با خیال راحت ترکیب کرد و هم دغدقه ی این رو نداشت که به نظر من که فلان مورد ، مزیت هست و ویژگی شاید محسوب نشه اما نظر شما برعکس باشه ، حالا اینکه کدوم نظر درست یا غلط باشه .
خیلی ممنون استاد .
نه، اگر درست ترجمه اش کنید می بینید که برداشت تون اشتباه ئه. مثلا "Even if Visual Studio designer is not available, you can code in XAML (Extensible Application Markup Language)" یعنی چی؟
معنی اش این نیست که WPF از XAML استفاده می کنه پس خوبه؟ نه. میگه با هر ویرایشگر ابتدایی در حد Notepad هم می توانید طراحی واسط کاربر WPF رو که در قالب XAML ئه بنویسید، برای اینکار لازم نیست که حتما از Designer ویژوال استدیو استفاده کنید. در XAML چند تا مزیت پیدا کرده و اونها رو نوشته. ممکنه مزایا و معایب دیگری در XAML باشه، هر کدوم رو میتونه بنویسه، ولی نمیاد مزیت رو با جمله ای عوض کنه که بگه WPF از XAML برای طراحی واسط کاربری استفاده می کنه. اینکه مزیت نشد، ویژگی ئه.
فرمت فایل های Resource در Windows Forms (فایل هایی با پسوند resx) چیه؟ XML. چه نتیجه ای ازش میشه گرفت؟ یعنی می توانید فایل های Resource رو با هر ویرایشگر ابتدایی بسازید، لازم نیست حتما Designer بکار برده بشه. حالا این توصیف یک مزیت ئه، نه اینکه بگید فایل های Resource در Windows Forms از XML استفاده می کنه. اینکه از DirectX استفاده می کنه ویژگی ئه، ممکنه شما ده تا مزیت داخلش پیدا کنید، دو تا عیب. شما می توانید اون ده تا مزیت رو بنویسید، نه اینکه استفاده از DirectX رو به عنوان مزیت بنویسید.
بله. ببینید جمله اش چی میگه. یک مثال ساده بزنم، میگم رنگ این لباس سفید ئه. سفید ویژگی ئه. شما نمی توانید سفید بودن رو مزیت در نظر بگیرید. اما بجایش مزیت رو میگم، میگم رنگ این لباس سفید ئه و نور خورشید رو کم جذب می کنه و در هوای گرم خنک تر از رنگ های تیره است. خنکی در هوای گرم مزیت ئه. یا میگم چون چرک رو راحت نشون میده برای لباس کادر درمان باعث رعایت بهتر بهداشت میشه، رعایت بهتر بهداشت مزیت ئه. یا میگم چون سفید ئه برای استتار نیروی ویژه در برف خوبه، استتار بهتر مزیت ئه. اما ممکنه بگم سفید ئه و برای رنگ لباس تعمیر کار و آتش نشان و ... خوب نیست، رنگ نامناسب بودن عیب ئه. سفید میتونه هم مزیت باشه و هم عیب. اون مزیت یا عیب رو باید بنویسید، نه اینکه ویژگی رو به عنوان مزیت یا عیب بنویسید.
در چند نظرتون را در این زمینه ، تا حدی قبول دارم اما نظر من تقریبا یه چیز دیگه هست . الان فرضا ، فرض کنید که در هواپیماهای جنگنده ی نسل های اخیر ، از موتور جت استفاده میشه . اما موتور هواپیماهای جنگنده ی 100 سال قبل یا بیشتر ، موتور ملخی بود . قطعا هم خیلی از قطعاتی در موتور جت بکار رفته که در موتورهای ملخی نبوده .
این باعث نمیشه که بگیم وقتی میخوایم هواپیمای ملخی با هواپیماهای جت را با هم مقایسه کنیم ، موتور شون را با هم مقایسه نکنیم (و صرفا موتور هواپیمای جت را جزء ویژگی هایش به شمار بیاریم) چون خیلی از قطعات موتور جت ، در موتور ملخی وجود نداره یا حداقل اون قطعاتی که در موتور ملخی وجود نداره اما در موتور جت وجود داره را نباید تحت عنوان مقایسه کردن ، به شمار بیاریم .
مزیت یا عیب ویژگی رو می نویسید، خیلی فرق می کنه با ذکر اسم دو ویژگی. ممکنه یک چیزی خیلی مزایا داشته باشه ولی هزینه نگهداری یا تولید اش گرانتر باشه، تعمیر اش پیچیده تر باشه، کاربری اش سخت تر باشه. مزیت و عیب با مقایسه یک به یک فرق داره، اینکه در مورد فلان ویژگی ای در x از y بیشتر ئه میتونه هم مزیت باشه و هم عیب. تا مزیت یا عیب رو توضیح ندهید چیزی معلوم نمیشه.
If you have not taken a look at Windows Presentation Foundation (WPF) yet, you really should. WPF is a great desktop development platform. Granted, all of the tools are not yet in place, but Micros...
www.codemag.com
عنوانش این باشه که "چرا از wpf استفاده کنیم؟"
چطوره؟
با این عنوان هم میشه همه ی مزیت ها و ویژگی ها را با خیال راحت ترکیب کرد و هم دغدقه ی این رو نداشت که به نظر من که فلان مورد ، مزیت هست و ویژگی شاید محسوب نشه اما نظر شما برعکس باشه ، حالا اینکه کدوم نظر درست یا غلط باشه .
خیلی ممنون استاد .
نه. نمیشه. چرا از سیب استفاده کنیم؟ چون گرد ئه. آخه گرد بودن سیب که ویژگی ئه، به خودی خود چه دلیلی برای بکار گیری سیب ئه؟ اگر بگید میخواهم میوه ای را انتخاب کنم که داخل قوطی کمپوت بشه، بله مزیت ئه، چون قوطی استوانه است و دور ریز کم میشه. اما اگر قوطی مکعب بود، دیگه این گرد بودن مزیت نیست. باید بگید برای قوطی استوانه کمپوت، گرد بودن سیب مزیت ئه، نه اینکه گرد بودن سیب رو به عنوان چرا از سیب استفاده کنیم بنویسید.
چرا از WPF استفاده کنیم؟ چون از DirectX استفاده می کنه. اینکه نشد مزیت، برای کسی که میخواد از توان کارت گرافیکی برای جلوه های ویژه استفاده کنه مزیت ئه، برای کسی که بخواد نرم افزار کم مصرف بسازه و باطری رو دیرتر خالی کنه عیب ئه. برای اون مثال انیمیشن بلادرنگ که کدش رو نوشتم عیب ئه، اگر از +GDI استفاده کرده بود انیمیشن روانتر و سریعتر میشد. نمیشه چیزی که اشتباهه رو با عوض کردن عنوان درست کرد.
نه، اگر درست ترجمه اش کنید می بینید که برداشت تون اشتباه ئه. مثلا "Even if Visual Studio designer is not available, you can code in XAML (Extensible Application Markup Language)" یعنی چی؟
معنی اش این نیست که WPF از XAML استفاده می کنه پس خوبه؟ نه. میگه با هر ویرایشگر ابتدایی در حد Notepad هم می توانید طراحی واسط کاربر WPF رو که در قالب XAML ئه بنویسید، برای اینکار لازم نیست که حتما از Designer ویژوال استدیو استفاده کنید. در XAML چند تا مزیت پیدا کرده و اونها رو نوشته. ممکنه مزایا و معایب دیگری در XAML باشه، هر کدوم رو میتونه بنویسه، ولی نمیاد مزیت رو با جمله ای عوض کنه که بگه WPF از XAML برای طراحی واسط کاربری استفاده می کنه. اینکه مزیت نشد، ویژگی ئه.
فرمت فایل های Resource در Windows Forms (فایل هایی با پسوند resx) چیه؟ XML. چه نتیجه ای ازش میشه گرفت؟ یعنی می توانید فایل های Resource رو با هر ویرایشگر ابتدایی بسازید، لازم نیست حتما Designer بکار برده بشه. حالا این توصیف یک مزیت ئه، نه اینکه بگید فایل های Resource در Windows Forms از XML استفاده می کنه. اینکه از DirectX استفاده می کنه ویژگی ئه، ممکنه شما ده تا مزیت داخلش پیدا کنید، دو تا عیب. شما می توانید اون ده تا مزیت رو بنویسید، نه اینکه استفاده از DirectX رو به عنوان مزیت بنویسید.
بله. ببینید جمله اش چی میگه. یک مثال ساده بزنم، میگم رنگ این لباس سفید ئه. سفید ویژگی ئه. شما نمی توانید سفید بودن رو مزیت در نظر بگیرید. اما بجایش مزیت رو میگم، میگم رنگ این لباس سفید ئه و نور خورشید رو کم جذب می کنه و در هوای گرم خنک تر از رنگ های تیره است. خنکی در هوای گرم مزیت ئه. یا میگم چون چرک رو راحت نشون میده برای لباس کادر درمان باعث رعایت بهتر بهداشت میشه، رعایت بهتر بهداشت مزیت ئه. یا میگم چون سفید ئه برای استتار نیروی ویژه در برف خوبه، استتار بهتر مزیت ئه. اما ممکنه بگم سفید ئه و برای رنگ لباس تعمیر کار و آتش نشان و ... خوب نیست، رنگ نامناسب بودن عیب ئه. سفید میتونه هم مزیت باشه و هم عیب. اون مزیت یا عیب رو باید بنویسید، نه اینکه ویژگی رو به عنوان مزیت یا عیب بنویسید.
مزیت یا عیب ویژگی رو می نویسید، خیلی فرق می کنه با ذکر اسم دو ویژگی. ممکنه یک چیزی خیلی مزایا داشته باشه ولی هزینه نگهداری یا تولید اش گرانتر باشه، تعمیر اش پیچیده تر باشه، کاربری اش سخت تر باشه. مزیت و عیب با مقایسه یک به یک فرق داره، اینکه در مورد فلان ویژگی ای در x از y بیشتر ئه میتونه هم مزیت باشه و هم عیب. تا مزیت یا عیب رو توضیح ندهید چیزی معلوم نمیشه.
نه. نمیشه. چرا از سیب استفاده کنیم؟ چون گرد ئه. آخه گرد بودن سیب که ویژگی ئه، به خودی خود چه دلیلی برای بکار گیری سیب ئه؟ اگر بگید میخواهم میوه ای را انتخاب کنم که داخل قوطی کمپوت بشه، بله مزیت ئه، چون قوطی استوانه است و دور ریز کم میشه. اما اگر قوطی مکعب بود، دیگه این گرد بودن مزیت نیست. باید بگید برای قوطی استوانه کمپوت، گرد بودن سیب مزیت ئه، نه اینکه گرد بودن سیب رو به عنوان چرا از سیب استفاده کنیم بنویسید.
چرا از WPF استفاده کنیم؟ چون از DirectX استفاده می کنه. اینکه نشد مزیت، برای کسی که میخواد از توان کارت گرافیکی برای جلوه های ویژه استفاده کنه مزیت ئه، برای کسی که بخواد نرم افزار کم مصرف بسازه و باطری رو دیرتر خالی کنه عیب ئه. برای اون مثال انیمیشن بلادرنگ که کدش رو نوشتم عیب ئه، اگر از +GDI استفاده کرده بود انیمیشن روانتر و سریعتر میشد. نمیشه چیزی که اشتباهه رو با عوض کردن عنوان درست کرد.
آها . خیلی ممنون استاد .
منظورتون اینه که اگه ویژگی یه چیز را بگم ، حالا بیام بگم که کاربردِ اون ویژگی چیه و به چه دردی میخوره ، در این صورت میشه در لیست مزیت ها جا بدم و جای بگیره؟
خوب ، در توضیحاتی که برای استفاده از XAML در طراحی رابط کاربری wpf دادم ، به مواردی مثل "قابلیت تو در تو بودن کدهای xaml که باعث سادگی درک رابطه ی کدنویسی با رابط کاربری میشه" و همچنین "فشرده تر و جمع و جورتر بودن کدهای xaml" و ... اشاره کردم و عکسی از این قضیه هم در همون پاورپوینت (در پست 692) گذاشتم .
پس حداقل در این یک مورد (توضیحات مربوط به xaml را در مزیت wpf نوشتم) ، درست عمل کردم دیگه .
تشکر استاد .
مورد 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
استاد ، یه سئوال دیگه درباره ی این برنامه تون دارم .
من وقتی پروژه ی wpf اش را اجرا میکنم ، عملکرد کارت گرافیک مجتمع ام تا 80 الی 90 درصد میره . (کارت گرافیک مجزا ندارم . مدلش هم intel HD 4600 و کارت مجتمع پردازنده ی i5 4460 هست) .
تفاوت عملکرد رسم در سیستم من هم طبق اطلاعاتی که خودتون در صفحه دادین ، حدود 10 برابر wpf کندتر هست .
میگم این قضیه ی کندی در سیستم من ، بخاطر ضعف کارت گرافیکم شاید باشه؟ ها؟
مثلا سیستمی که به کارت گرافیک GTX 1050 Ti یا بالاتر مجهز باشه ، احتمال داره که سرعت رندرینگش خیلی بهتر بشه . نه؟
میتونم بپرسم کارت گرافیک شما چه مدلی هست و تفاوت رسم این دو برنامه ی wpf و winform با چه اختلافی در سیستم شما اجرا میشه و همچنین عملکرد gpu در سیستم تون تا چند درصد میره؟
البته قضیه ی جدا بودن دو نخ ui و نخ رندر که ذاتا باعث هماهنگیِ کمتر و کندتر نسبت به تک نخی میشه ، جای خود . ولی میخوام بدونم کارت گرافیک اگه قویتر باشه ، چقدر در رندر این برنامه تاثیر داره .
استاد ، یه سئوال دیگه درباره ی این برنامه تون دارم .
من وقتی پروژه ی wpf اش را اجرا میکنم ، عملکرد کارت گرافیک مجتمع ام تا 80 الی 90 درصد میره . (کارت گرافیک مجزا ندارم . مدلش هم intel HD 4600 و کارت مجتمع پردازنده ی i5 4460 هست) .
تفاوت عملکرد رسم در سیستم من هم طبق اطلاعاتی که خودتون در صفحه دادین ، حدود 10 برابر wpf کندتر هست .
میگم این قضیه ی کندی در سیستم من ، بخاطر ضعف کارت گرافیکم شاید باشه؟ ها؟
مثلا سیستمی که به کارت گرافیک GTX 1050 Ti یا بالاتر مجهز باشه ، احتمال داره که سرعت رندرینگش خیلی بهتر بشه . نه؟
میتونم بپرسم کارت گرافیک شما چه مدلی هست و تفاوت رسم این دو برنامه ی wpf و winform با چه اختلافی در سیستم شما اجرا میشه و همچنین عملکرد gpu در سیستم تون تا چند درصد میره؟
البته قضیه ی جدا بودن دو نخ ui و نخ رندر که ذاتا باعث هماهنگیِ کمتر و کندتر نسبت به تک نخی میشه ، جای خود . ولی میخوام بدونم کارت گرافیک اگه قویتر باشه ، چقدر در رندر این برنامه تاثیر داره .
استاد ، من این برنامه را در سیستم خود اجرا کردم . کارت گرافیک را تا ۹۰ درصد درگیر میکرد.
مشخصاتش هم it 4460 بدون کارت گرافیک مجزا هست :
winform اش حدودا 49000 time و wpf اش حدود 4700 time بود .
بعد توسط anydesk در لپتاپ فامیلم که اخیرا براش خریده بودم اجرا کردم . مشخصاتش هم i7 6700hq با gtx 950m ddr5 هست و روی شارژر وصل بود و تنظیمات پاورش روی balance بود و فرکانس cpu هم بالای 2.7 ghz میرفت و عملکرد گرافیکش هم فکر کنم بیشتر از ۷۰ درصد بود . چون اینترنتم ضعیف بود ، دیرکرد در تصویر داشتم :
winform اش حدودا 8700 time و wpf اش حدود 5100 time رفت .
________________________
این times ای که در برنامه نوشتید ، همون تعدادِ دفعاتِ رسم هست دیگه . درسته؟
یعنی هر چقدر بیشتر باشه ، تعداد رسم اش هم بیشتره دیگه . درسته؟
یعنی هر چی بیشتر باشه ، رسمِ بیشتر و سریعتری داره دیگه . درسته؟
الان واسه ی من که ۴۴۶۰ هه ، winform ام 49000 time بود . اما 6700hq که هم در عملکرد تک و هم چند هسته ای بهتر از پردازنده ام هست ، 87000 time که حدودا ۵ برابر کندتر بود.
چرا؟!!
کارت گرافیک gtx 950m ddr5 هم فقط اندکی از کارت گرافیک مجتمع ام بهتر عمل کرد .
چرا تفاوت پردازنده ی ۴۴۶۰ و ۶۷۰۰hq این قدر و اون هم ۶۷۰۰hq ، در این برنامه ، این قدر ضعیف تره؟
در صورتی که در برنامه های دیگه که خودم تست کردم (چه تک یا چند هسته ای) و همچنین در بنچمارک های رسمی ، هم در عملکرد تک و چند هسته ای ، 6700hq به مراتب سریعتر از ۴۴۶۰ هه مخصوصا در عملکرد چند هسته ای .
بی زحمت ، درباره ی اجرای این برنامه در سیستم تون میگید که wpf و winform هر کدوم چند times میدن؟
www.itproportal.com
www.codemag.com
docs.devexpress.com
معرفی سامانه فیش 98: راهحلی نوین برای مدیریت فیشهای حقوقی
