مطالب
iTextSharp و نمایش صحیح تاریخ در متنی راست به چپ

خروجی PDF زیر را در نظر بگیرید:

مشکلی را در آن مشاهده می‌کنید؟ اصل آن یا صحیح آن باید به شکل زیر باشد:


و این وارونه نمایش دادن‌ها، دقیقا مشکلی است که حین کار با iTextSharp برای نمایش متنی مثلا به همراه یک تاریخ شمسی وجود دارد. البته این مشکل هم اساسا به خود استاندارد یونیکد برمی‌گردد که یک سری کاراکتر را «کاراکتر ضعیف» معرفی کرده؛ برای مثال کاراکتر اسلش بکار رفته در یک تاریخ هم از این دست است. بنابراین PDF تولیدی توسط iTextSharp از دید استاندارد یونیکد مشکلی ندارد، زیرا یک «نویسه ضعیف» مثل اسلش نمی‌تواند جهت را تغییر دهد؛ مگر اینکه از یک «نویسه قوی» برای دستکاری آن استفاده شود. برای مثال این نویسه‌ها قوی هستند:

U+202A:   LEFT-TO-RIGHT EMBEDDING (LRE) 
U+202B:   RIGHT-TO-LEFT EMBEDDING (RLE)
U+202D:   LEFT-TO-RIGHT OVERRIDE (LRO)
U+202E:   RIGHT-TO-LEFT OVERRIDE (RLO)
U+202C:   POP DIRECTIONAL FORMATTING (PDF)

برای رسیدن به تصویر صحیح نمایش داده شده در بالا، متد FixWeakCharacters زیر را تهیه کرده‌ام که حداقل با iTextSharp جواب می‌ده:

using System;
using System.Diagnostics;
using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;

namespace RleTests
{
class Program
{
const char RightToLeftEmbedding = (char)0x202B;
const char PopDirectionalFormatting = (char)0x202C;

static string FixWeakCharacters(string data)
{
if (string.IsNullOrWhiteSpace(data)) return string.Empty;
var weakCharacters = new[] { @"\", "/", "+", "-", "=", ";", "$" };
foreach (var weakCharacter in weakCharacters)
{
data = data.Replace(weakCharacter, RightToLeftEmbedding + weakCharacter + PopDirectionalFormatting);
}
return data;
}

static void Main(string[] args)
{
using (var pdfDoc = new Document(PageSize.A4))
{
PdfWriter.GetInstance(pdfDoc, new FileStream("Test.pdf", FileMode.Create));
pdfDoc.Open();

FontFactory.Register("c:\\windows\\fonts\\Arial.ttf");
Font tahoma = FontFactory.GetFont("Arial", BaseFont.IDENTITY_H);

var table1 = new PdfPTable(1);
table1.WidthPercentage = 100;

var pdfCell = new PdfPCell
{
RunDirection = PdfWriter.RUN_DIRECTION_RTL,
Border = 0,
Phrase = new Phrase(FixWeakCharacters(
"تاریخ: " + "1390/11/18" + Environment.NewLine +
"شماره پروژه: " + "1/2/3/4/56" + Environment.NewLine +
"اسلش: " + " 12/A/13 " + Environment.NewLine +
"بک اسلش: " + " 12\\13\\14 " + Environment.NewLine +
"مساوی و جمع: " + " 2+3=5 " + Environment.NewLine +
"سمی کولون: " + " 2=1+1; " + Environment.NewLine +
"دلار: " + "12$" + Environment.NewLine +
"کاما: " + "12,34,67" + Environment.NewLine +
"نقطه: " + "12.34" + Environment.NewLine +
"پرانتز: " + "متن (ساده)"
),
tahoma)
};

table1.AddCell(pdfCell);
pdfDoc.Add(table1);

}

Process.Start("Test.pdf");
}
}
}

از این نوع مشکلات حین کار با HTML هم هست؛ وارونه نمایش داده شدن تاریخ فارسی در بین یک متن راست به چپ. البته در آنجا راه حل زیر هم توصیه شده (بدون نیاز به دستکاری نویسه‌ها):

<span dir="ltr" style="display:inline">1390/11/19</span>

مطالب
مشکل توزیع در توسعه نرم افزار‌های WindowsCE
در حین توسعه نرم افزاری برای ویندوز کامپکت مرتبا به خطاهایی که قبلا برنخورده بودم میرسیدم. چند باری هم کارهای انجام شده را بررسی کردم و در فوروم‌های مرتبط دنبال سرنخی از راه حل گشتم ولی یا جوابی مرتبط وجود نداشت و یا راه حل‌های پیشنهادی دور از حل مسئله بود؛ تا اینکه یکی از خطا‌ها نظرم را جلب کرد:
Could not load type 'System.Windows.Forms.Form' from assembly 'System.Windows.Forms, Version=3.5.0.0, Culture=neutral, PublicKeyToken=969DB8053D3322AC'.
System.Windows.Forms 3.5.7283.0 but 3.5.0.0 windows CE
پس از بررسی کلی دستگاه و راهنمای آن متوجه شدم ویندوزی که برای دستگاه ساخته شده، به صورت پیش فرض دارای دات نت نصب شده‌است. من هم از دات نت نسخه‌ی سه با سرویس پک یک و ویندوز کامپکت نسخه‌ی 6 استفاده میکردم. در حین اجرا و دیباگ برنامه بر روی دستگاه، اگر نسخه‌ای از دات نت نصب باشد، زحمت به‌روز کردن دات نت را برای توزیع نمی‌دهد و برنامه به مشکل بر می‌خورد. راه حل این مشکل هم ساخت ویندوز جدید بدون دات نت فریمورک است که حدود یک ساعت و نیم زمان می‌برد:

برای انجام این فرآیند احتیاج به نصب مقدماتی بر روی یک ویندوز تازه است که ترتیب نصب آن نیز بسیار مهم است:
1. Microsoft Visual Studio 2005
2. Microsoft Visual Studio 2005  Service Pack 1
3. Microsoft Windows Embedded CE 6.0 Toolkit
4. Windows Embedded CE 6.0 Platform Builder Service Pack 1
5. Windows Embedded CE 6.0 R2
6. Windows Embedded CE 6.0 R3
اشتراک‌ها
نگارش نهایی NET Core 3.0. منتشر شد

We’re excited to announce the release of .NET Core 3.0. It includes many improvements, including adding Windows Forms and WPF, adding new JSON APIs, support for ARM64 and improving performance across the board. C# 8 is also part of this release, which includes nullable, async streams, and more patterns. F# 4.7 is included, and focused on relaxing syntax and targeting .NET Standard 2.0. You can start updating existing projects to target .NET Core 3.0 today. The release is compatible with previous versions, making updating easy. 

نگارش نهایی NET Core 3.0. منتشر شد
مطالب
یافتن خطاهای متداول کدهای جاوا اسکریپتی با غنی سازی تنظیمات کامپایلر TypeScript
یکی از اهداف مهم استفاده‌ی از TypeScript، یافتن خطاهای متداول کدهای جاواسکریپتی، پیش از اجرای آن‌ها در مرورگر است. برای مثال، قطعه کد زیر:
  defaultChecks() {
    const author = { firstName: "Vahid", lastName: "N" };
    console.log(author.lastname);
    author.lastName.trimStart();
    author.firstName.charCodeAt("1");
  }
دارای سه مشکل است که سریعا توسط TypeScript شناسایی می‌شود:


- خاصیت lastname در شیء author وجود خارجی ندارد.
- نوع رشته‌ای، به همراه متد trimStart نیست.
- متد charCodeAt یک عدد را به عنوان پارامتر قبول می‌کند.

اما باید درنظر داشت که بسیاری از قابلیت‌های بررسی کد TypeScript، به صورت پیش‌فرض فعال نیستند که در ادامه آن‌ها را برای یافتن پیش از موعود بسیاری از مشکلات، فعالسازی خواهیم کرد.


نصب افزونه‌ی TSLint در VSCode

جهت مشاهده‌ی بهتر خطاهای کامپایلر TypeScript، پیش از کامپایل نهایی کدها، می‌توان از افزونه‌ی TSLint استفاده کرد. برای نصب آن، ابتدا باید بسته‌ی ذیل را نصب کرد:
  > npm install -g tslint typescript
سپس نیاز است افزونه‌ی آن‌را نیز نصب کنید: https://marketplace.visualstudio.com/items?itemName=eg2.tslint
کار TSLint انجام static code analysis است؛ چیزی شبیه به افزونه‌هایی مانند ری‌شارپر در ویژوال استودیو که راهنماهایی را در مورد بهتر کردن کیفیت کدهای نوشته شده ارائه می‌دهد.


فعالسازی بررسی نال و نوع‌های نال پذیر

 strictNullChecks یکی از مهم‌ترین پرچم‌های تنظیمات کامپایلر تایپ‌اسکریپت است. برای افزودن آن، به فایل tsconfig.json مراجعه کرده و پرچم آن‌را به true تنظیم کنید:
{
    "compilerOptions": {
        "strictNullChecks": true
    }
}
به این ترتیب کامپایلر تایپ‌اسکریپت، بین null ،undefined و سایر نوع‌ها، تفاوت قائل خواهد شد و اگر نوعی نال‌پذیر است، باید آن‌را به صورت صریح type | null تعریف کنید.
برای مثال، متد ذیل را در نظر بگیرید:
  getSessionItem(key: string): any {
    const data = window.sessionStorage.getItem(key);
    return JSON.parse(data);
  }
زمانیکه پرچم strictNullChecks فعال شود، قطعه کد فوق با خطای ذیل کامپایل نخواهد شد:
[ts]
Argument of type 'string | null' is not assignable to parameter of type 'string'.
Type 'null' is not assignable to type 'string'.
const data: string | null
از این جهت که خروجی متد getItem به صورت string | null تعریف شده‌است؛ اما پارامتر متد JSON.parse فقط string را قبول می‌کند. یعنی ممکن است data دریافتی نال باشد که متد JSON.parse قادر به پردازش آن نیست.
برای رفع این مشکل تنها کافی است بررسی کنیم که آیا data نال است یا خیر؟ و اگر خیر، آنگاه آن‌را به متد JSON.parse ارسال کنیم:
  getSessionItem(key: string): any {
    const data = window.sessionStorage.getItem(key);
    if (data) {
      return JSON.parse(data);
    } else {
      return null;
    }
  }
همانطور که ملاحظه می‌کنید، فعالسازی strictNullChecks می‌تواند از بروز بسیاری از خطاهای در زمان اجرای برنامه، جلوگیری کند.


گزارش return‌های فراموش شده

در متد ذیل، یک return فراموش شده وجود دارد و تمام شرط‌های برنامه به یک خروجی مشخص، منتهی نمی‌شوند:
  noImplicitReturns(a: number) {
    if (a > 10) {
      return a;
    }
    // No return in this branch
  }
برای تشخیص زود هنگام یک چنین مشکلاتی می‌توان پرچم noImplicitReturns را در فایل tsconfig.json به true تنظیم کرد:
{
    "compilerOptions": {
        "noImplicitReturns": true
    }
}
پس از این تنظیم، کامپایلر در مورد متد noImplicitReturns، خطای ذیل را صادر می‌کند:
 [ts] Not all code paths return a value.


تشخیص کدهای مرده

قطعه کدی که پس از یک return قرار بگیرد، یک کد مرده نامیده می‌شود. با تنظیم پرچم allowUnreachableCode در فایل tsconfig.json به false، می‌توان کامپایلر TypeScript را وادار کرد تا اینگونه موارد را به عنوان خطا گزارش کند:
{
    "compilerOptions": {
        "allowUnreachableCode": false
    }
}
پس از این فعالسازی، کامپایلر TypeScript دو خطای [ts] Unreachable code detected را در مورد قطعه کد ذیل صادر می‌کند:
    allowUnreachableCode() {
      if (false) {
        console.log("Unreachable code");
      }
      const a = 1;
      if (a > 0) {
        return 10; // reachable code
      }
      return 0;
      console.log("Unreachable code");
    }
مورد اول مربوط به بدنه‌ی if ایی است که شرط آن false است و این بدنه هیچگاه فراخوانی نمی‌شود و مورد دوم، به سطر پس از return آخر مرتبط است که آن مورد نیز یک کد مرده محسوب می‌شود.


تشخیص پارامترها و متغیرهای استفاده نشده

دو متد ذیل را درنظر بگیرید:
  unusedLocals() {
    const a = "foo"; // Error: 'a' is declared but its value is never read
    return "bar";
  }

  unusedParameters(n: number) {
    n = 0; // Never read
  }
در اولی متغیر a تعریف شده‌است، اما هیچگاه استفاده نشده‌است. در متد دوم، پارامتر n نیز هیچگاه خوانده نشده‌است و وجود آن بی‌مصرف است؛ حتی ممکن است نشان فراموش شدن استفاده‌ی از آن و مقدار دهی اشتباه آن باشد.
برای فعالسازی بررسی یک چنین مواردی باید دو پرچم ذیل را در فایل tsconfig.json به true تنظیم کرد:
{
    "compilerOptions": {
        "noUnusedLocals": true,
        "noUnusedParameters": true
    }
}
پس از آن، کامپایلر دو خطای ذیل را در مورد متدهای فوق، گزارش می‌کند:
[ts] 'a' is declared but its value is never read.
[ts] 'n' is declared but its value is never read.


یافتن خواصی که نباید در یک شیء وجود داشته باشند

در مثال ذیل، خاصیت baz در تعاریف اصلی نوع‌های x و y وجود ندارد:
  excessPropertyForObjectLiterals() {
    let x: { foo: number };
    x = { foo: 1, baz: 2 };  // Error, excess property 'baz'
    let y: { foo: number, bar?: number };
    y = { foo: 1, baz: 2 };  // Error, excess property 'baz'
  }
برای فعالسازی یافتن یک چنین مواردی که در بسیاری از حالات ممکن است ناشی از اشتباهات تایپی نیز باشند، می‌توان پرچم suppressExcessPropertyErrors را در فایل tsconfig.json به false تنظیم کرد:
{
    "compilerOptions": {
        "suppressExcessPropertyErrors": false
    }
}
پس از آن برای نمونه در مورد انتساب اول، یک چنین پیام خطایی از طرف کامپایلر TypeScript صادر خواهد شد:
[ts]
Type '{ foo: number; baz: number; }' is not assignable to type '{ foo: number; }'.
Object literal may only specify known properties, and 'baz' does not exist in type '{ foo: number; }'.
(property) baz: number


یافتن breakهای فراموش شده در عبارات switch

در مثال زیر، یک break فراموش شده‌است:
  fallthroughCasesInSwitchStatement(a: number) {
    switch (a) {
      case 0:
        break;

      case 1:
        a += 1;

      case 2:
        a += 2;
        break;
    }
  }
برای تشخیص آن توسط کامپایلر TypeScript باید پرچم noFallthroughCasesInSwitch را در فایل tsconfig.json به true تنظیم کرد:
{
    "compilerOptions": {
        "noFallthroughCasesInSwitch": true
    }
}
پس از آن کامپایلر TypeScript خطای «[ts] Fallthrough case in switch» را در مورد متد فوق صادر می‌کند.


یافتن ایندکس‌های تعریف نشده‌ی در اشیاء

در مثال زیر، شیء x دارای خاصیت b نیست؛ اما دقیقا با این ایندکس مورد استفاده قرار گرفته‌است:
  indexingObjectsLackingIndexSignatures() {
    const x = { a: 0 };
    x["a"] = 1; // ok
    x["b"] = 1; // Error, type '{ a: number; }' has no index signature.
  }
برای تشخیص یک چنین خطاهایی می‌توان پرچم suppressImplicitAnyIndexErrors را در فایل tsconfig.json به false تنظیم کرد:
{
    "compilerOptions": {
        "suppressImplicitAnyIndexErrors": false
    }
}
پس از آن کامپایلر TypeScript خطای ذیل را در مورد دسترسی به ایندکسی که با امضای شیء سازگاری ندارد، صادر می‌کند:
[ts] Element implicitly has an 'any' type because type '{ a: number; }' has no index signature.


اجبار به تعریف صریح نوع‌ها در TypeScript

عمده‌ی قابلیت TypeScript در یافتن خطاها به تعاریف نوع‌ها و راهنمایی کامپایلر آن در این زمینه بر می‌گردد. اما چون این زبان سازگاری کاملی را با JavaScript دارد، تعریف نوع‌ها در آن اجباری نیست و در این حالت اگر نوعی تعریف نشده باشد، به any تفسیر می‌شود. جهت اجبار به تعریف نوع‌ها در TypeScript می‌توان پرچم noImplicitAny را در فایل tsconfig.json به true تنظیم کرد:
{
    "compilerOptions": {
        "noImplicitAny": true
    }
}
در این حالت دیگر قطعه کد ذیل کامپایل نخواهد شد:
  noImplicitAny(args) { // Error: Parameter 'args' implicitly has an 'any' type.
    console.log(args);
  }
برای رفع این مشکل می‌توان نوع args را به صورت صریحی مشخص کرد:
  noImplicitAnyArgs(args: string[]) { // ok with the type information
    console.log(args);
  }


یک نکته‌ی تکمیلی
اگر از دستور ng build --watch برای ساخت برنامه‌های Angular استفاده می‌کنید، تغییرات فوق زمانی تاثیر داده خواهند شد که یکبار این برنامه را بسته و مجددا اجرا کنید.
مطالب
پیکربندی electron packager
یکی از ابزارهایی که برای این بسته تولید شده‌است و به شما کمک می‌کند تا بسته بندی راحت‌تری داشته باشید و یک نوع ویزارد را در CLI به شما نشان می‌دهد، ابزار electron-packager-interactive است که به طریق زیر آن را نصب می‌کنیم:
npm install -g electron-packager-interactive
سپس با وارد کردن دستور زیر
electron-packager-interactive
یا خلاصه تر
epi
آن را اجرا میکنیم و سوال‌های زیر به ترتیب از شما پرسیده و طبق پاسخ آن، بسته بندی صورت می‌گیرد:
? Overwrite output directory ? Yes
? Use asar source packaging ? Yes
? Select Electron app source directory: E:\Projects\electron\dbtest
? Select Electron app output directory: E:\Projects\electron\dbtest\releases
? Select Application name: myapp
? Select App Bundle Id (optional): 12
? Select App Version(optional): 0.0.1
? Select Electron icon file:
? Select Electron version release: 0.34.1
? Select platforms: all
? Select architecture: all


پیکربندی از طریق packages.json
شما می‌توانید برای بسته بندی از طریق این فایل، یک پروفایل ایجاد کنید و بر اساس اطلاعات هر پروفایلی که دوست دارید، بسته بندی را انجام دهید؛ یا مثلا دوست دارید برای هر پلتفرم تنظیمات خاصی را داشته باشید. برای اینکار شما می‌توانید به تعداد دلخواهی از خصوصیت build را مانند کد زیر داشته باشید:
"scripts": {
    "start": "./node_modules/.bin/electron .",
    "test":"eslint .",
    "build":"electron-packager . myapp --platform=all --arch=all --overwrite --ignore=node_modules/dev-dependency --asar",
    "build:win32":"electron-packager . myapp --platform=win32 --arch=ia32 --overwrite --ignore=node_modules/dev-dependency --asar",
    "build:win64":"electron-packager . myapp --platform=win64 --arch=x64 --overwrite"
  },
در کد بالا من سه نوع پیکربندی را برای build تعریف کرده‌ام. در اولین پیکربندی بسته بندی برنامه برای همه پلتفرم‌ها و معماری‌ها انجام می‌گیرد و در دومین پیکربندی فقط برای سیستم عامل ویندوز نسخه 32 بیتی آن و  در سومین پیکربندی، نسخه 64 بیتی مد نظر است که البته ویژگی asar و فلگ ignore را مانند دو پیکربندی قبلی به همراه ندارد. برای صدا زدن آن‌ها در CLI هم باید به شکل زیر عمل کنید:
npm run build
npm run build:win32
npm run build:win64

افزودن فایل‌های ایستا به بسته بندی
یکی از مشکلاتی که هنگام بسته بندی به آن برخوردم این بود که فایل sql.txt به بسته نهایی اضافه نشده بود و برنامه به همین علت terminate میشد. برای اینکه به این مشکل دچار نشوید، بهتر هست این موارد را داخل یک دایرکتوری قرار داده تا بعد از بسته بندی، دایرکتوری را به راحتی به بسته نهایی کپی کنید. با توجه به صحبت‌هایی که با یکی از تولیدکنندگان پکیج داشتم، ایشان متذکر شدند با اینکه این بسته حاوی یک لیست سیاه برای انتقال فایل‌هاست، ولی فایلی مثل sql.txt مشکلی ندارد. اما با این حال اگر به مشکل برخورد کردید، این مورد را خودتان دستی انجام دهید.
نظرات مطالب
نوشتن TagHelperهای سفارشی برای ASP.NET Core
تگ جدید list-group صرفا server side است و در زمان ارائه‌ی نهایی View به صورت HTML، با منطق پیاده سازی شده‌ی در متد Process جایگزین می‌شود.
اشتراک‌ها
ارتقاء در WPF و Sql Connectivity در نسخه 4.6.1 .net Framework

Microsoft's .NET Fundamentals Team a few weeks ago announced a new version of .NET Framework 4.6.1. It includes a number of streamline improvements to Windows Presentation Foundation and SQL Connectivity, to name a few. And just recently, the team also re-emphasized end of support for versions of .NET Framework versions older than 4.5.1.  

ارتقاء در WPF و Sql Connectivity  در نسخه 4.6.1 .net Framework
اشتراک‌ها
NET Core 3.1. در آذرماه به پایان پشتیبانی خود می‌رسد
The long-term-support (LTS) version 3.1 of Microsoft .NET Core Framework is slated to go out of support on December 13th, 2022. Microsoft recommends upgrading .NET Core 3.1 applications to .NET 6.0 to stay supported for the future, while the developers have mixed feelings about the .NET support policy.
NET Core 3.1. در آذرماه به پایان پشتیبانی خود می‌رسد
اشتراک‌ها
Cake v1.0.0 منتشر شد

This version is the 112th release of Cake, but just not any release - we've finally hit 1.0 🎉 In this blog post, we will go through some of the major new features of 1.0, which platforms are supported, what to consider when upgrading to Cake 1.0. 

Cake v1.0.0 منتشر شد
مطالب
نگاهی به درون سیستم Binding در WPF و یافتن مواردی که هنوز در حافظه‌اند
در WPF، زیر ساخت‌های ComponentModel توسط کلاسی به نام PropertyDescriptor، منابع Binding موجود در قسمت‌های مختلف برنامه را در جدولی عمومی ذخیره و نگهداری می‌کند. هدف از آن، مطلع بودن از مواردی است که نیاز دارند توسط مکانیزم‌هایی مانند INotifyPropertyChanged و DependencyProperty ها، اطلاعات اشیاء متصل را به روز کنند.
در این سیستم، کلیه اتصالاتی که Mode آن‌ها به OneTime تنظیم نشده است، به صورت اجباری دارای یک valueChangedHandlers متصل توسط سیستم PropertyDescriptor خواهند بود و در حافظه زنده نگه داشته می‌شوند؛ تا بتوان در صورت نیاز، توسط سیستم binding اطلاعات آن‌ها را به روز کرد.
همین مساله سبب می‌شود تا اگر قرار نیست خاصیتی برای نمونه توسط مکانیزم INotifyPropertyChanged اطلاعات UI را به روز کند (یک خاصیت معمولی دات نتی است) و همچنین حالت اتصال آن به OneTime نیز تنظیم نشده، سبب مصرف حافظه بیش از حد برنامه شود.
اطلاعات بیشتر
A memory leak may occur when you use data binding in Windows Presentation Foundation

راه حل آن هم ساده است. برای اینکه valueChangedHandler ایی به خاصیت ساده‌ای که قرار نیست بعدها UI را به روز کند، متصل نشود، حالت اتصال آن‌را باید به OneTime تنظیم کرد.


سؤال: در یک برنامه بزرگ که هم اکنون مشغول به کار است، چطور می‌توان این مسایل را ردیابی کرد؟

برای دستیابی به اطلاعات کش Binding در WPF، باید به Reflection متوسل شد. به این ترتیب در برنامه جاری، در کلاس PropertyDescriptor به دنبال یک کلاس خصوصی تو در توی دیگری به نام ReflectTypeDescriptionProvider خواهیم گشت (این اطلاعات از طریق مراجعه به سورس دات نت و یا حتی برنامه‌های ILSpy و Reflector قابل استخراج است) و سپس در این کلاس خصوصی داخلی، فیلد خصوصی propertyCache آن‌را که از نوع  HashTable است استخراج می‌کنیم:
 var reflectTypeDescriptionProvider = typeof(PropertyDescriptor).Module.GetType("System.ComponentModel.ReflectTypeDescriptionProvider");
var propertyCacheField = reflectTypeDescriptionProvider.GetField("_propertyCache",
BindingFlags.Static | BindingFlags.NonPublic);


اکنون به لیست داخلی Binding نگهداری شونده توسط WPF دسترسی پیدا کرده‌ایم. در این لیست به دنبال مواردی خواهیم گشت که فیلد valueChangedHandlers به آن‌ها متصل شده است  و در حال گوش فرا دادن به سیستم binding هستند (سورس کامل و طولانی این مبحث را در پروژه پیوست شده می‌توانید ملاحظه کنید).


یک مثال: تعریف یک کلاس ساده، اتصال آن و سپس بررسی اطلاعات درونی سیستم Binding

فرض کنید یک کلاس مدل ساده به نحو ذیل تعریف شده است:
namespace WpfOneTime.Models
{
    public class User
    {
        public string Name { set; get; }
    }
}
سپس این کلاس به صورت یک List، توسط ViewModel برنامه در اختیار View متناظر با آن قرار می‌گیرد:
using WpfOneTime.Models;
using System.Collections.Generic;

namespace WpfOneTime.ViewModels
{
    public class MainWindowViewModel
    {
        public IList<User> Users { set; get; }

        public MainWindowViewModel()
        {
            Users = new List<User>();
            for (int i = 0; i < 1000; i++)
            {
                Users.Add(new User { Name = "name " + i });
            }
        }
    }
}
تعاریف View برنامه نیز به نحو زیر است:
<Window x:Class="WpfOneTime.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:ViewModels="clr-namespace:WpfOneTime.ViewModels"        
        Title="MainWindow" Height="350" Width="525">
    <Window.Resources>
        <ViewModels:MainWindowViewModel x:Key="vmMainWindowViewModel" />
    </Window.Resources>
    <Grid DataContext="{Binding Source={StaticResource vmMainWindowViewModel}}">        
        <ListBox ItemsSource="{Binding Users}">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <TextBlock Text="{Binding Name}" />
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>
    </Grid>
</Window>
همه چیز در آن معمولی به نظر می‌رسد. ابتدا به ViewModel برنامه دسترسی یافته و  DataContext را با آن مقدار دهی می‌کنیم. سپس اطلاعات این لیست را توسط یک ListBox نمایش خواهیم داد.
خوب؛ اکنون اگر اطلاعات HashTable داخلی سیستم Binding را در مورد View فوق بررسی کنیم به شکل زیر خواهیم رسید:


بله. تعداد زیادی خاصیت Name زنده و موجود در حافظه باقی هستند که تحت ردیابی سیستم Binding می‌باشند.
در ادامه، نکته‌ی ابتدای بحث را جهت تعیین حالت Binding به OneTime، به View فوق اعمال می‌کنیم (یک سطر ذیل باید تغییر کند):
 <TextBlock Text="{Binding Name, Mode=OneTime}" />
در این حالت اگر نگاهی به سیستم ردیابی WPF داشته باشیم، دیگر خبری از اشیاء زنده دارای خاصیت Name در حال ردیابی نیست:


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


چطور از این نکته برای پروفایل یک برنامه موجود استفاده کنیم؟

کدهای برنامه را از انتهای بحث دریافت کنید. سپس دو فایل ReflectPropertyDescriptorWindow.xaml و ReflectPropertyDescriptorWindow.xaml.cs آن‌را به پروژه خود اضافه نمائید و در سازنده پنجره اصلی برنامه، کد ذیل را فراخوانی نمائید:
 new ReflectPropertyDescriptorWindow().Show();
کمی با برنامه کار کرده و منتظر شوید تا لیست نهایی اطلاعات داخلی Binding ظاهر شود. سپس مواردی را که دارای HandlerCount بالا هستند، مدنظر قرار داده و بررسی نمائید که آیا واقعا این اشیاء نیاز به valueChangedHandler متصل دارند یا خیر؟ آیا قرار است بعدها UI را از طریق تغییر مقدار خاصیت آن‌ها به روز نمائیم یا خیر. اگر خیر، تنها کافی است نکته Mode=OneTime را به این Bindingها اعمال نمائیم.

دریافت کدهای کامل پروژه این مطلب
WpfOneTime.zip