FormsAuthentication.SetAuthCookie(... // ... FormsAuthentication.RedirectFromLoginPage(...
خطا هنگام ایجاد هدر سفارشی با html
خطا هنگام ایجاد هدر سفارشی با html
- در نگارش جدید بجای HtmlHeader از XHtmlHeader استفاده کنید.
- برای مشاهدهی کامل stack trace، گزارش را در حالت دیباگ اجرا کنید:
.Generate(data => ..., ..., debugMode: true);
برای نمونه در متد ذیل، میزان حجم مصرفی در یک پوشه بازگشت داده میشود:
public async Task<long> GetDirectorySize(string path, string searchPattern) { if (!Directory.EnumerateFileSystemEntries(path, searchPattern).Any()) return 0; else return await Task.Run<long>(() => Directory.GetFiles(path, searchPattern, SearchOption.AllDirectories).Sum(t => (new FileInfo(t).Length))); }
AsyncTaskMethodBuilder<long>.Create()
باید دقت داشت که Task، یک نوع ارجاعی است و استفادهی از آن به معنای تخصیص حافظهاست. اما زمانیکه قسمتی از کد کاملا همزمان اجرا میشود و یا مقداری کش شده را بازگشت میدهد، این تخصیص حافظهی اضافی، خصوصا اگر در حلقهها بکار گرفته شود، هزینهبر خواهد بود.
امکان تعریف خروجیهای سفارشی متدهای async در C# 7.0
در C# 7 میتوان خروجیهای سفارشی را جهت متدهای async تعریف کرد و پیشنیاز اصلی آن پیاده سازی متد GetAwater است. برای مثال <System.Threading.Tasks.ValueTask<T یک چنین نوع سفارشی را ارائه میدهد. در این حالت، متد ابتدای بحث را میتوان به صورت ذیل بازنویسی کرد:
public async ValueTask<long> GetDirectorySize(string path, string searchPattern) { if (!Directory.EnumerateFileSystemEntries(path, searchPattern).Any()) return 0; else return await Task.Run<long>(() => Directory.GetFiles(path, searchPattern, SearchOption.AllDirectories).Sum(t => (new FileInfo(t).Length))); }
همانطور که از نام ValueTask نیز مشخص است، یک struct است؛ برخلاف Task و تخصیص حافظهی آن بر روی stack بجای heap صورت میگیرد. به این ترتیب با کاهش فشار بر روی GC، در حلقههایی که خروجی value type دارند، با اندازه گیریهای انجام شده، کارآیی تا 50 درصد هم میتواند بهبود یابد.
برای کامپایل قطعه کد فوق و تامین نوع جدید ValueTask، نیاز به نصب بستهی نیوگت ذیل نیز میباشد:
PM> install-package System.Threading.Tasks.Extensions
اشتباه 1:
استفاده از
throw ex;
throw;
اشتباه 2:
درک اشتباه عملکرد متد replace :
string s = "Take this out";
s.Replace("this", "that"); //wrong
s = s.Replace("this", "that"); //correct
اگر از fxCop استفاده کنید، اینگونه خطاها را (عدم استفاده از مقدار بازگشتی) گوشزد میکند.
اشتباه 3:
استفادهی بی دقت از متغیرهای استاتیک در یک برنامه وب. دو مثال زیر را در نظر بگیرید:
public static string GetCookieName(Cookie c)
{
return c.Name;
}
static List<string> cookieList = new List<string>();
public static void AddToCookieList(Cookie c)
{
cookieList.Add(c.Name);
}
برنامههای وب ذاتا چند ریسمانی هستند و زمانیکه یک متغیر را از نوع استاتیک تعریف میکنید، این متغیر، هنگام مراجعهی کاربران بین آنها به اشتراک گذاشته میشود و امکان تخریب یا استفادهی ناصحیح از مقادیر آنها وجود خواهد داشت. در حالت اول نیازی به مباحث همزمانی و قفل کردن منابع نیست زیرا متغیری که در متد استفاده میشود، thread safe است اما cookieList در مثال دوم خیر و حتما هنگام استفاده از آن باید مباحث قفل کردن منابع را درنظر داشت. (حتی اگر برنامهی شما از نوع وبی هم نیست اما چند ریسمانی است این مطلب باز هم صادق میباشد)
اشتباه 4:
مقابله با خطاها به شکلی نادرست: (اصطلاحا خفه کردن خطاها!)
try
{
//something
File.Delete(blah);
}
catch{}
هرچند گاهی از اوقات اگر خطای حاصل برای ما اهمیتی نداشت میتوان از آن استفاده نمود، در غیراینصورت باید حتما از این روش پرهیز کرد.
اشتباه 5:
ارائهی برنامههای ASP.Net با گزینهی پیش فرض Debug=true در web.config که پیشتر در مورد آن در این سایت بحث شده است.
اشتباه 6:
عدم استفاده از امکانات ویژهی دات نت فریم ورک هنگام کار با رشتهها:
string s = "This ";
s += "is ";
s += "not ";
s += "the ";
s += "best ";
s += "way.";
StringBuilder sb = new StringBuilder();
sb.Append("This ");
sb.Append("is ");
sb.Append("much ");
sb.Append("better. ");
زمانیکه نیاز به کنار هم قرار دادن رشتههای مختلف وجود داشت و تعداد آنها نیز زیاد بود، مثال دوم توصیه میشود.
البته در مثال فوق که تعداد کمی رشته قرار است با هم جمع شوند، کامپایلر به اندازهی کافی هوشمند خواهد بود که تمام آنها را کنار هم قرار دهد و تفاوتی در کارآیی احساس نشود، حتی روش اول سریعتر از روش دوم خواهد بود، اما زمان استفاده از هزاران رشته، این تفاوت محسوس است.
اشتباه 7:
عدم استفاده از عبارت using هنگام استفاده از اشیایی از نوع Idisposable . مثالی در این مورد.
using (StreamReader reader=new StreamReader(file))
{
//your code here
}
اشتباه 8:
فراموش کردن بررسی نال بودن یک شیء هنگام استفاده از آن.
string val = Session["xyz"].ToString();
این نوع کد نویسی یکی از اشتباهات متداول تمامی تازه واردان به ASP.Net است. حتما باید پیش از استفاده از متد ToString بررسی شود که آیا این سشن نال است یا نه. در غیراینصورت حاصل کار فقط یک exception خواهد بود. (استفاده از افزونهی ری شارپر در این موارد کمک بزرگی است، زیرا به محض قرار گرفتن مکان نما روی شیءایی که احتمال نال بودن آن میسر است، یک راهنما را به شما ارائه خواهد کرد)
اشتباه 9:
بازگشت دادن یک property عمومی از نوع لیستهای جنریک.
با توجه به اینکه این نوع لیستها فقط خواندنی نیستند و امکان دستکاری اطلاعات آن توسط فراخوان وجود دارد، توصیه میشود از نوع جنریک IEnumerable استفاده شود. همچنین توصیه شده است هنگام انتخاب نوع پارامترهای ورودی یک متد نیز به این مورد دقت شود.
کتابخانه jquery-lockfixed
lockfixed is a jQuery plugin which allows for DOM elements to be positioned anywhere on the page, and lock within the user's viewport when scrolling. Common use case is a menu under a header, which on scrolling stays within the viewport and doesn't overflow the footer.
Degrades nicely on mobile and tablet browsers and doesn't have any CSS prerequisites. Demo
.NET Framework 4.8.1 will be available for the following versions of Windows and distribution channels:
- Windows Update: Windows 11 21H2, Windows 10 21H2 (LTSC), and Windows 10 22H2
- Microsoft Update Catalog: Windows 11 21H2, Windows 10 21H2 (LTSC), Windows 10 22H2 and Windows Server 2022 (Desktop, Azure Editions), Azure Stack 21H2 and Azure Stack 22H2.
Build Events
من میخوام اندازه پشته توی ویزوال استودیو تغییر بدم در Post Build Event کد زیر نوشتم
editbin.exe /STACK:1000000 $(TargetFileName)
Error 7 The command "editbin.exe /STACK:10000 MS-AUV.exe" exited with code 9009.MS-AUV
<StackLayout BackgroundColor="LightYellow" HorizontalOptions="Center" Orientation="Vertical" VerticalOptions="Start" WidthRequest="320">
مشکل دیگری که وجود دارد این است که اگر بابت کمبود فضا، Stack Layout کوچکتر از 5 سانتی متر شود، از بغل، کامل، به کنارههای Parent خود میچسبد که اصلا جالب نیست. برای رفع این مشکل میتوانیم از Padding (حاشیه داخلی) و Margin (حاشیه خارجی) استفاده کنیم. در عکس زیر، Background مربوط به Content Page را قرمز و Stack Layout را آبی کردهایم. با اختصاص دادن یک سانتی متر (64) به Padding و نیم سانت به Margin، میتوانید در عکس زیر تاثیر آن را ببینید:
در سمت راست، بالا و چپ Stack Layout، به اندازه نیم سانت حاشیه قرمز میبینید که تاثیر Margin است. همچنین المانهای داخل Stack Layout نیز هر کدام یک سانت از اطراف فاصله دارند که تاثیر Padding است. در پایین Stack Layout، تا جایی که Content Page بزرگ شود، فضای قرمز میبینید، نیم سانت از این فضای قرمز به خاطر Margin بوده، ولی باقی مربوط به این است که VerticalOptions را برای Stack Layout، بر روی Start تنظیم کردهایم که باعث میشود Stack Layout بالای Content Page قرار بگیرد و زیر آن تماما قرمز شود. حتی اگر "عرض" صفحه نمایش بزرگتر از عکس قبلی میبود، فضای قرمز از راست و چپ بیشتر میشد که نیم سانت آن بابت Margin بوده و بیشتر از آن مربوط به HorizontalOptions است که برای Stack Layout روی Center تنظیم شده.
با توجه به اینکه Page - Layout - Controlها در Android-iOS-Windows به معادلهای Native خود تبدیل میشوند و برای مثال ظاهر Button در این سه پلتفرم متفاوت است، ممکن است Padding ای که به یک کنترل داده ایم و در اندروید خوب به نظر میرسد، در iOS مقدار دیگری را لازم داشته باشد. مثلا در Android مقدار 2 و در iOS مقدار 3 لازم داشته باشد. یا ممکن است این مقدار به ازای این که در موبایل، تبلت یا دسکتاپ باشیم، لازم باشد که متفاوت باشد. در Xaml ما دو امکان OnPlatform و OnIdiom را داریم که هر Property اعم از Font Size - Padding - Text و ... را میتوان به ازای هر شرایطی با مقداری متفاوت مقدار دهی نمود. برای مثال داریم:
<StackLayout Margin="{OnPlatform Android=3, iOS='0,0,20,0', UWP='2'}" Padding="{OnIdiom Default=2, Tablet=3}" ...
البته Propertyهای مهم دیگری نیز در UI تاثیر گذار هستند. برای مثال Opacity برای تنظیم شفافیت، FlowDirection برای تنظیم Right to left و Left to right بودن و خیلی Propertyهای دیگه که به مرور و با بیشتر کار کردن با Xamarin Forms با آنها آشنا میشوید.
در قسمت بعدی به نوشتن منطق میپردازیم؛ نحوه نمایش دادن خطا و رفتن از صفحهای به صفحهی دیگر.
کدامیک از قلمهای فارسی ذیل خواناتر هستند؟
در بقیه حالات حتی اگ هم ناراضی باشن سخنی نمیگویند ولی در یک نظرسنجی که کاربر دو نمونه رو ببینه میشه به نکات مهمتری رسید. فونت یکان یکی از فونتهای مورد علاقه من هست ولی در وب رضایت چندانی ازش ندارم. هر چند تا مدتها جز معدود فونتهای مجاز و خوب بود. دلیل اینکه ازش ناراضی هستم این هست که چندان برای وب بهینه نیست و در حالتهای سایز خیلی بزرگ و کوچک فرم خودش رو از دست میده ولی وزیر و صمیم این مشکل چندان حاد نیست. چون بسیار بهینهتر شدند یا مثلا تاهما تا موقعی که 9pt هست بسیار خوب عمل میکنه، بزرگتر بشه به یک فاجعه تبدیل میشه. من از صمیم راضی هستم چون واقعا برای خواندن مطالب بلند برای چشم عالی هست. خیلی حالت رسمی داره.