پاسخ به بازخورد‌های پروژه‌ها
تنظیم چندین OverallSummarySettings برای ستون های مختلف
ممنون، ولی متاسفانه در حالت Landscape هم جواب گوی کار ما نیست و تغییر سایز کاغذ نیز امکان پذیر نیست.
اگر راهنمایی کنید که در سورس کد چه تفاوتی بین سلول مقدار جمع و سایر سلول‌ها هست که 'n\' را پردازش نمی‌کند، تا خودمان با تغییر سورس این مشکلمان را حل کنیم ممنون میشم.
با سپاس
پاسخ به بازخورد‌های پروژه‌ها
اضافه کردن Indentation به ابتدای محتوای یک سلول
از نحوه‌ی عملکرد قالب پیش فرض نمایشی یک سلول خشنود نیستید؟ سفارشی‌اش کنید:
«ایجاد قالب‌های سفارشی ستون‌ها و فرمت شرطی اطلاعات در PdfReport»
یک مثال دیگر: نمایش مبلغ به صورت سفارشی
پاسخ به بازخورد‌های پروژه‌ها
قراردادن فیلد Hyperlink
بله. از قالب سلول مخصوص به آن استفاده کنید:
columns.AddColumn(column =>
                {
                    //...
                    column.ColumnItemsTemplate(template =>
                    {
                        template.Hyperlink(foreColor: System.Drawing.Color.Blue, fontUnderline: true);
                    });
                });
حالت پیش فرض، استفاده از TextBlock است؛ اگر چیزی تنظیم نشود:
columns.AddColumn(column =>
                {
                    //...
                    column.ColumnItemsTemplate(template =>
                    {
                        template.TextBlock();
                    });
                });
فایل‌های پروژه‌ها
PdfRpt-1.6.zip
- متد FlushInBrowser اضافه شد؛ جهت سهولت تولید فایل‌های PDF درون حافظه‌ای برنامه‌های وب
Generate(data => data.FlushInBrowser(fileName))
- قالب سلول MonthCalendar اضافه شد؛ برای نمایش تقویم ماهیانه شمسی و میلادی. مثالی در این مورد: (^)
نظرات مطالب
تغییر عملکرد و یا ردیابی توابع ویندوز با استفاده از Hookهای دات نتی
سورس پروژه قابل دریافت هست و به عنوان یک قالب برای این نوع کارها میشه ازش استفاده کرد.
برای مثال در این قالب جایی که هوک تعریف میشه به این صورت تغییر خواهد کرد:
                _getHostByNameHook = LocalHook.Create(
                                        InTargetProc: LocalHook.GetProcAddress("ws2_32.dll", "gethostbyname"),
                                        InNewProc: new GetHostByNameDelegate(getHostByNameHooked),
                                        InCallback: this);
delegate آن چنین تعریفی خواهد داشت (توضیحات آن در متن فوق هست؛ قسمت (ج) نوشتن هوک):
        [UnmanagedFunctionPointer(CallingConvention.StdCall, CharSet = CharSet.Ansi, SetLastError = false)]        
        private delegate IntPtr GetHostByNameDelegate(string name);
و جایی که نهایتا درخواست‌های DNS دریافت می‌شوند به صورت زیر تعریف خواهد شد:
        private static IntPtr getHostByNameHooked(string name)
        {
            // redirect ...
            //if (name.StartsWith("www.google.com"))
            //{
            //    return Native.GetHostByName("127.0.0.1");
            //}            

            return Native.gethostbyname(name);
        }
در اینجا می‌شود درخواست‌های DNS را تغییر جهت داد (مثلا گوگل را بلاک کرد)، یا همان تابع اصلی ویندوز را اجرا کرد و یا name دریافتی را در یک فایل مثلا لاگ کرد.
مطالب
برنامه نویسی موازی - بخش اول - مفاهیم

برنامه نویسی موازی، نقطه‌ی متقابل برنامه نویسی سریال که حتی گاها با برنامه نویسی سریال به سبک Asynchronous به اشتباه گرفته می‌شود، به سبکی از برنامه نویسی گفته می‌شود که در آن برنامه نویس قابلیت اجرای بخش‌های موازی برنامه را از طریق چندین Thread و به طور همزمان ایجاد کرده باشد. نکاتی که در این سبک برنامه نویسی بسیار مهم است، مهارت‌های برنامه نویس در درک قسمت‌های موازی برنامه و مجزا سازی این بخش‌ها از یکدیگر است تا کمترین ارتباط را با هم داشته باشند. مشخصا تمامی یک برنامه قابلیت موازی سازی را نخواهد داشت؛ اما مفهومی به عنوان درجه‌ی موازی سازی در هر برنامه وجود دارد که ایده آل موازی سازی، رسیدن به این درجه‌ی از موازی سازی است.
در برنامه نویسی موازی، قسمت‌هایی از برنامه که به Thread‌های مجزایی برای اجرا محول شده‌اند، می‌توانند تقریبا در یک زمان شروع به اجرا کنند و اینگونه است که سرعت اجرای عملیات افزایش پیدا می‌کند. به عنوان مثال فرض کنید برنامه‌ای داریم که ۱۰۰ رکورد از پایگاه داده واکشی می‌کند و بررسی‌ای بر روی یکی از فیلدهای آن انجام می‌دهد که ۳ ثانیه زمان گیر است و در صورت وجود شرایط خاصی، آن رکورد را لاگ می‌کند. در برنامه نویسی سریال، برسی ۱۰۰ رکورد، به ۳۰۰ ثانیه زمان برای انجام احتیاج دارد؛ ولی با فرض انجام همین عملیات با دو Thread به صورت موازی، این زمان تقریبا به نصف کاهش پیدا خوهد کرد.


چرا و در چه زمانی باید به سراغ برنامه نویسی موازی رفت !؟


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


در اجرای موازی بخش‌های مختلف برنامه، ترتیب انجام هر بخش نباید در نتیجه‌ی کلی تاثیر گذار باشد. در عملیات جمع یک مجموعه می‌توان آن را به چند Thread مجزا محول کرد تا هر بخش از مجموعه را یک Thread جمع بزند و در نهایت نتیجه‌ی کل Thread‌ها با هم جمع شود. در این عملیات ترتیب اتمام کار هر Thread، نتیجه‌ای بر Thread‌های دیگر و نتیجه‌ی نهایی، نخواهد داشت. اما در شکل بالا بعد از اتمام انجام عملیات تبدیل حروف کوچک به بزرگ توسط هر Thread، گارانتی‌ای برای چاپ آنها به همان ترتیبی که از سورس خوانده شده‌اند، وجود ندارد. به عبارتی ممکن است در ابتدا وظیفه‌ی 2 Thread تمام شده باشد و بعد 1 Thread که باعث خواهد شد در خروجی، ابتدا کاراکترهای "CD" و سپس "AB"  نمایش داده شود. البته این یک مثال ساده برای درک موضوع است.


مفهوم Thread Safe

Thread Safe یک مفهوم مرتبط به زبان‌های برنامه نویسی با قابلیت اجرای چند ریسمانی می‌باشد؛ بدین مفهوم که Thread safe فقط در نرم افزارهایی که به صورت Multi Thread نوشته شده‌اند معنا پیدا می‌کند.
درک مفهوم Thread Safe و تکنیک‌های مرتبط با آن، در نرم افزار‌های چند ریسمانی بسیار حائز اهمیت می‌باشد. چرا که باعث بروز برخی خطاهای منطقی در عملکرد سیستم خواهد شد که بعضاً ردگیری آن‌ها نیز بسیار دشوار است. به طور کلی هنگامیکه thread‌‌های مختلفی در یک برنامه در حال کار همزمان می‌باشند، رخ دادن دو اتفاق شایع زیر دور از ذهن نیست:


1- Dead Lock

مفهوم بن بست در علوم کامپیوتر، یکی ار رایج‌ترین مفاهیم است که از سطح سیستم عامل تا سیستم‌های توزیع شده، تعمیم داده می‌شود. Dead Lock  زمانی رخ می‌دهد که Thread‌های مختلف، با منابع مشترکی کار می‌کنند. بدین صورت که Thread شماره ۱، منبع A را در اختیار دارد و منتظر منبع B است. همزمان Thread شماره دو، منبع B را در اختیار دارد و منتظر منبع A است. به این شرایط، بن بست می‌گویند. شبیه سازی این اتفاق را در کد #C زیر می‌توانید ببینید:
public static void Function_A()
{
 lock (resource_1)
 {
   Thread.Sleep(1000);
   lock (resource_ 2)
   {
   }
 }
}

public static void Function_B()
{
 lock (resource_2)
 {
   Thread.Sleep(1000);
   lock (resource_1)
   {
   }
 }
}

static void Main()
{
  Thread thread_A = new Thread((ThreadStart)Function_A);
  Thread thread_B = new Thread((ThreadStart)Function_B);

  thread_A.Start();
  thread_B.Start();

  while (true)
  {
   // Stare at the two threads in deadlock.
  }
}

2- Race conditions

زمانی رخ می‌دهد که دو یا چند thread به یک مقدار مشترک دسترسی داشته باشند و تلاش کنند که در یک زمان، مقدار آن را تغییر دهند. مشکل از جایی رخ می‌دهد که شما به عنوان یک برنامه نویس نمی‌دانید، در یک زمان یکسان، برای تغییر یه مقدار مشترک بین thread‌ها، اولویت با کدام thread است. این اولویت بندی و جابجایی بین threadها وظیفه‌ی الگوریتم زمان بندی thread‌ها است که در هر زمان می‌تواند بین thread‌های مختلف سوییچ کند. این اولویت بندی می‌تواند روی عملکرد کد شما تاثیر گذار باشد؛ مخصوصا در بخش‌هایی که مقدار مشترکی برسی می‌شوند؛ مانند مثال زیر:
if (x == 5) 
{
   y = x * 2; 
}

اگر بلافاصله بعد از بررسی مقدار متغیر x توسط یک thread ،thread دیگری این مقدار را تغییر دهد، دیگر نتیجه‌ی این بلاک کد، منطقی نخواهد بود و جواب، ۱۰ نخواهد شد.

با توجه به مفاهیم عنوان شده، بررسی Thread safe بودن یک کد، با معیارهای زیر انجام می‌شود:
۱- قفل گذاری روی منابع باید به شکلی باشد که باعث بروز Dead Lock نشود.
۲- استفاده از مقادیر مشترک باید به گونه‌ای باشد که منجر به Race-conditions نشود.

حال اگر در هر برنامه، مقادیر مشترکی بین thread‌‌ها وجود داشته باشد، چه از نوع struct, class, static و ...  باید به این نکته توجه کرد که ذاتا این مقادیر Thread Safe هستند یا نه !؟ در بخش بعدی، راهکارهای قفل گذاری را برای استفاده از مقادیری که ذاتا thread safe نیستند، بررسی می‌کنیم.
نظرات مطالب
ObservableCollection در Entity Framework
من در winform یک BindingSource دارم و این رو به گرید می‌دم. گرید به یک BindingSource بایند شده، اگه مقادیری رو تغییر بدم یا اضافه کنم در گرید (در واقع به BindingSource پشت صحنه) ، ChangeTracker تشخیص می‌ده و می‌تونم کار رو هندل کنم اما اگه سطری رو از BindingSource (یا همون گرید) حذف کنم ChangeTracker متوجه نمی‌شه و وضعیتشون Unchanged می‌مونه! (Local هم فایده نداره) و نمی‌تونم کل تغییرات رو ذخیره کنم با صدا زدن SaveChanges
در ChangeTracker ایتم هایی با State‌های Add, Modified رو می‌تونم ببینم ولی اگه ایتمی رو Delete کنم نمی‌تونم ببینمش و کاری انجام بدم! مشکل از کجاست؟
اینا مربوط به Context هست برای بررسی وضعیت تغییرات:
  public bool HasChanges()
        {
            return this.ChangeTracker.Entries().Any(e => e.State != EntityState.Unchanged);
        }

        public void RejectChanges()
        {
            foreach (var entry in this.ChangeTracker.Entries())
            {
                switch (entry.State)
                {
                    case EntityState.Modified:
                        entry.State = EntityState.Unchanged;
                        break;

                    case EntityState.Added:
                        entry.State = EntityState.Detached;
                        break;
                }
            }
        }
توضیحات بیشتر:
چرا مثل Add , Modify عمل Delete در Entity‌ها و ChangeTracker بصورت خودکار شنیده نمی‌شه؟! من یک کتابخانه‌ی مستقل تهیه کردم که گرید ،‌خودش یک کنترل BindingSource داره و اصلا نباید به EntityFramework و سرویسهایی که با Entity‌ها کار می‌کنن در ارتباط باشه ، BindingSource باید بتونه CurrentItem اش رو Remove کنه در حافظه مثل کاری که برای Add,Update انجام می‌ده و در انتها من (بعنوان کاربر نهایی) در لایه نمایش تصمیم بگیرم که تمام تغییرات انجام شده در گرید (Add, Modify, Delete) رو ذخیره یا لغو کنم.
******* شاید بشه با کمک رویداد BindingSource.ListChanged به نحوی حل کرد ولی اصلا جالب نمی‌شه چون BindingSource من یک POCO Entity هست و فقط و فقط چنتا property داره و اصلا از وضعیت خودش خبر نداره و قرار هم نیست بیشتر از این باشه و من نمی‌تونم وضعیتش رو تغییر بدم در این رویداد چون همچین چیزی نداره اصلا!
مطالب
React reconciliation
در پروژه‌های React، نقطه‌ی آغازین فرآیند rendering، قطعه کد زیر میباشد که درون فایل index.js قرار دارد:
ReactDOM.render(<App />, document.getElementById('root'));
 
توسط متد ReactDOM.render یک وهله از کامپوننت App ایجاد شده و منجر به فراخوانی متد render کامپوننت مربوطه خواهد شد. درون متد ذکر شده ممکن است چندین کامپوننت تعریف شده باشند. در نتیجه به ازای هر کامپوننت، متد render متناظر با آن فراخوانی خواهد شد. در نهایت یک ساختار سلسله مراتبی از عناصر HTML تشکیل شده و توسط آرگومان دوم متد فوق، درون عنصری با آی‌دی root درج خواهند شد. 
برای مثال کامپوننت‌های زیر را در نظر بگیرید که هر کدام درون فایل مربوط به خودشان هستند:
// List.js
import React, { Component } from 'react';
import { ActionButton } from './ActionButton';
export class List extends Component {
    constructor(props) {
        super(props);
        this.state = {
            items: [
                { id: 1, title: "Item 1" },
                { id: 2, title: "Item 2" },
                { id: 3, title: "Item 3" },
                { id: 4, title: "Item 4" },
                { id: 5, title: "Item 5" },
            ]
        };
    }

    reverse = () => {
        this.setState({ items: this.state.items.reverse() });
    }

    render() {
        console.log("Render List Component");
        return (
            <div className="list-container">
                <ActionButton callback={this.reverse} />
                <ul>
                    {this.state.items.map(item => {
                        return <li key={item.id}>
                            {item.title}
                        </li>
                    })}
                </ul>
            </div>
        );
    }
}

// ActionButton.js
import React, { Component } from 'react';
export class ActionButton extends Component {
    render() {
        console.log("Render ActionButton Component");
        return (
            <button onClick={this.props.callback}>Click me</button>
        );
    }
}
در نهایت درون کامپوننت App.js نیز همچین ساختاری خواهیم داشت:
import React from 'react';
import './App.css';
import { List } from './List';

function App() {
  console.log("Render App Component");
  return (
    <div className="App">
      <h1>Reconciliation Process</h1>
      <List />
    </div>
  );
}

export default App;

 
درون متد render هر کدام از کامپوننت‌های فوق یک console.log نوشته شده است. با اجرای برنامه خروجی زیر در کنسول مرورگر قابل مشاهده است:
Render App Component
Render List Component
Render ActionButton Component

دلیل آن نیز این است که با اجرای اپلیکیشن، React از تمامی کامپوننت‌ها درخواست فراخوانی متد renderشان را خواهد کرد. به محض اینکه محتوای HTML درون صفحه نمایش داده شد، اپلیکیشن در وضعیتی تحت عنوان reconciled قرار خواهد گرفت؛ در این مرحله، خروجی نمایش داده شده با state کامپوننت‌ها سازگار است. React منتظر خواهد بود تا تغییری رخ دهد که در بیشتر اپلیکیشن‌ها این تغییر توسط کاربر انجام خواهد گرفت که در نهایت منجر به فراخوانی متد setState میشود. متد setState در واقع state dataی یک کامپوننت را بروزرسانی میکند؛ اما اینکار کامپوننت را stale یا کهنه میکند. یعنی محتوای HTMLی نمایش داده شده به کاربر قدیمی خواهد شد و با تنها یک رخداد ممکن است چندین state data تغییر کنند. این کار باعث خواهد شد که متد render برای تمامی کامپوننت‌های تغییر کرده فراخوانی شود. اما از آنجائیکه بروزرسانی DOM عملی هزینه‌بر است، در نتیجه React محتوای قبلی (کش شده با عنوان Virtual DOM) را با محتوای جدید مقایسه میکند تا کمترین میزان بروزرسانی DOM را داشته باشد. به این فرآیند Reconciliation گفته میشود.
برای درک بهتر این فرآیند، درون کامپوننت List یک آی‌دی به عنصر ul اضافه خواهیم کرد:
<ul id="list">
    {this.state.items.map(item => {
        return <li key={item.id}>
            {item.title}
        </li>
    })}
</ul>

اکنون در حالیکه پروژه در حال اجرا است، کد زیر را درون کنسول مرورگر اجرا کنید:
document.getElementById("list").classList.add("message")

همانطور که مشخص است کد فوق کلاسی با نام message را به عنصر ul اضافه کرده است:

.message {
  border: 1px solid green;
  padding: 2rem;
}


اکنون وقتی بر روی دکمه Click me کلیک کنیم، محتوای درون کامپوننت فوق تغییر پیدا میکند، اما عنصر ul همچنان دارای کلاس message است؛ دلیل آن نیز همانطور که عنوان شد این است که React محتوای تولید شده توسط کامپوننت List را با Virtual DOM خودش مقایسه میکند و چون از لحاظ ساختار DOM با هم برابر هستند تغییری در ساختار خروجی کامپوننت ایجاد نمیکند و فقط قسمت‌هایی را که تغییر کرده‌اند، بروزرسانی خواهد کرد.


اکنون کامپوننت فوق را اینگونه تغییر خواهیم داد:

import React, { Component } from 'react';
import { ActionButton } from './ActionButton';
export class List extends Component {
    constructor(props) {
        // as before
    }

    reverse = () => {
        this.setState({ items: this.state.items.reverse(), wrapInDiv: true });
    }

    generateElement = () => {
        const list = <ul id="list">
            {this.state.items.map(item => {
                return <li key={item.id}>
                    {item.title}
                </li>
            })}
        </ul>;

        return this.state.wrapInDiv ? <div>{list}</div> : list;
    }

    render() {
        console.log("Render List Component");
        return (
            <div className="list-container">
                <ActionButton callback={this.reverse} />
                {this.generateElement()}
            </div>
        );
    }
}

  در اینجا اگر مجدداً کلاس ذکر شده را به عنصر ul اضافه کنیم و سپس بر روی دکمه کلیک کنیم، خواهیم دید که کلاس message از عنصر ul حذف خواهد شد. دلیل آن نیز این است که ساختار HTML با Virtual DOM یکی نیست و React کامپوننت موردنظر را با تغییرات جدید مجدداً رندر خواهد کرد. 

نکته: برای مشاهده تغییرات DOM می‌توانید قابلیت Paint flashing را در مرورگر Chrome از قسمت Developer Tool > More tools > Rendering فعال کنید و تغییرات را به صورت visual ببینید.