اگه DialogResult ای در کار نباشه نه، دلیلی نداره دکمه ای که کدی نداره فرمی رو ببنده، بالاخره یا OnClick و متد های مشابه کاری انجام میدن، یا رخداد Click و موارد مشابه رو جایی مدیریت کردید یا جاهایی خودتون فرم رو می بندید که فراموش کردید یا DialogResult ای در کار ئه. بالاخره یه جایی این اتفاق می افته. کد تون رو در حال اجرا Trace کنید محل اش پیدا میشه.
با چی جابجا بشه؟ اون بخشی که باهاش میشد جابجا بشه رو حذف می کنید و فقط بخش Client می مونه که اصولا قرار نیست تو این مورد دخالتی داشته باشه.
public partial class Form1 : Form
{
private const int WM_NCLBUTTONDOWN = 0xA1;
private const int HT_CAPTION = 0x2;
[DllImport("user32.dll")]
private static extern bool ReleaseCapture();
[DllImport("user32.dll")]
private static extern int SendMessage(IntPtr hWnd, int Msg, int wParam, int lParam);
private void Form1_MouseDown(object sender, MouseEventArgs e)
{
if (e.Button == MouseButtons.Left)
{
ReleaseCapture();
SendMessage(Handle, WM_NCLBUTTONDOWN, HT_CAPTION, 0);
}
}
public Form1()
{
InitializeComponent();
}
}این 25 درصد که میگید معیار دقیقی از توان مصرفی پروسه شما در هسته نیست، یک معیار کلی، تخمینی و ظاهریه. صحبت وضعیت یک کسری از ثانیه است، نه کل زمان. همونطور که شما یکسره روبرو تون رو نمی بینید و پلک می زنید، سیستم عامل هم مدام منبعش رو از پروسه شما پس می گیره و دوبار تخصیص میده.
از این موارد زیاد ئه، یک جاهایی بجای Resume و Suspend از Begin و End و ... هم استفاده میشه. روال کلی اینه، کارهایی هست که باید در واکنش به یکسری تغییرات حتما انجام بشه، فرضا اگه آیتمی به لیست اضافه می شه یا محتوای آیتم تغییری می کنه، باید لیست از نو رسم بشه. یا اگه اندازه کنترل ای تغییر کنه، محتویات داخلش بر اساس تغییرات ابعاد از نو جابجا بشن و ... زمانی که تغییرات فقط یکی دو تا مورد ئه، اشکالی نداره که برای هر کدوم یکبار از نو کار ها انجام بشه، ولی در اغلب موارد تغییراتی که میدید، یکی دو تا نیست و زیاده. فرضا صد تا آیتم داره یکی یکی به لیست اضافه میشه یا یک کنترل چندین تغییر مشخصه پی در پی پیدا می کنه. اگه قرار باشه برای هر کدوم یکبار اون کارها که باید انجام میشد، تکرار بشه، فرضا از نو رسم صورت بگیره، ممکنه خیلی سر بار ایجاد کنه، روال بیخودی کند بشه یا موقع نمایش کنترل پر پر بزنه. برای اینجور موارد سعی می کنند یک همچین متد هایی رو طراحی کنند، که اعلام کنید میخواهم یکسری تغییرات رو یکجا بدم، از فلان جای کد تا زمانی که اعلام می کنید تلاشی در واکنش به تغییرات انجام نشه، یعنی فرضا روال رسم مجدد غیر فعال بشه. زمانی که تغییرات تون تموم شد با متد دوم اعلام می کنید که کار من تمام شد و حالا فقط یکبار اون روال که لازمه انجام میشه. استفاده از اینها برای افزایش کارایی ئه. که هی برای یک تغییر کوچیک یک روال تکراری انجام نشه چون تغییرات بعدی در راه اند و فعلا نیازی به نمایش تغییرات نیست.
ممنون استاد علی
منظورم از اینکه پروژه ام 25 درصد رو توی پردازنده ی 4 هسته ای استفاده میکنه ، اصلا این نبود که یک هسته رو کاملا قبضه کنه . توضیحات رو در بالا دادم و میدونم ممکنه هر لحظه ، در یک نخ و یا حتی یک هسته اجرا بشه
ممنون
موازی سازی میتونه روی یک هسته انجام بشه، اما لازمه اش اینه که اولا کد هایی که همزمان اجرا میشن مناسب اینکار باشه و ثانیا هسته توانایی اینکار رو داشته باشه و ثالثا کد برای اجرای موازی نوشته شده باشه. مثل اینه که از کاربر بپرسیم آیا مطمئنی میخوای این فایل رو حذف کنی و بعد اگه پاسخ Yes بود فایل رو حذف کنیم. این کد باید ترتیبی اجرا بشه، برای موازی سازی مناسب نیست. این کد رو موازی اجراش کنیم چی میشه؟ فایل رو حذف کنیم و همزمان از کاربر بپرسیم آیا رضایت داشتی که فایل رو حذف کردیم یا دلخور شدی؟ نمیشه که. هسته برای افزایش کارایی فرمان هایی رو موازی اجرا می کنه که مستقل از هم هستند و نتیجه شون روی هم تاثیری نداره. در ضمن توانایی سخت افزاری پردازنده هم ملاک ئه، فرضا فقط یک فرمان مرتبط با حافظه رو همزمان با یک فرمان مربوط به محاسبات اعشاری انجام میده، چون بخش های سخت افزاری شون مستقل ئه. نه اینکه دو فرمان مرتبط با حافظه یا دو فرمان مرتبط با محاسبات اعشاری رو همزمان اجرا کنه. هدفش هم اینه که بخش مرتبط با حافظه یا محاسبات اعشاری اش بیکار نمونه. ممکنه در یک لحظه همچین شرایطی برای اجرای موازی باشه و یک زمانی نباشه. در هر صورت اینها کاملا مرتبط با معماری و خصوصیات یک پردازنده خاص هستند، نمیشه برای همه پردازنده ها یک حکم قطعی داد. و در نظر بگیرید که خیلی تفاوته بین اجرای موازی کد های دو نخ از یک پروسه و اجرای موازی کد های دو پروسه متفاوت. سوئیچ بین دو پروسه سربار داره، پس خیلی مطلوب نیست، اما این سربار از بیکار بودن یک بخش از هسته بهتره.
چطور اینکار رو بکنه؟ فکر می کنید ویژوال استدیو فقط یک کاری رو انجام میده که کاملا مستقل ئه و نه نیازی به ورودی داره و نه خروجی و بی وقفه میتونه به کارش ادامه بده و معطل موردی نشه؟
Image img = ((DataObject)e.Data).GetImage();
MessageBox.Show(img.ToString());قبلا اشاره کردم و رفرنس هم بهتون دادم، نامحدود ئه. انواع محدودی در کار نیست.
یک کنترلی منبع Drag ئه، فعلا نه میدونه مقصد کجاست و نه میدونه قبول می کنه یا نه. فقط داده ای با فرمت دلخواهش رو همراه Drag ایجاد می کنه، متد DoDragDrop برای اینکار ئه. مقصد هم یک کنترل دیگه است که دکمه ماوس رو روش رها می کنید، میتونه Drop رو قبول بکنه و یا نکنه. منطق ثابت و مشخصی هم نداره، چون خودتون دارید Drag می کنید داده و نوعش رو هم خودتون مشخص می کنید، به هر طریقی که دوست دارید. سایر برنامه ها هم ممکنه اصلا قابلیت استقاده داده اش رو نداشته باشند یا بطرز نامناسبی تفسیر اش کنند. در مورد Clipboard هم همینطوره.
معمولا نه، ولی نه به این دلایل که میگید، الان دیگه NET. یک مورد جدید نیست که خیلی بحث پیش نیازش مطرح باشه، NET 2. برای ویندوز های Vista به بعد از ابتدای نصب شدن ویندوز آماده استفاده هست. اما کلا ویروس تعریف خاص خودش رو داره، برنامه ای که فایل های دیگه رو آلوده نکنه ویروس نیست. ویروسی هم که به سادگی شناسایی بشه ویروس خوبی نیست. طبیعتا کسی هم که ویروس طراحی می کنه یا اونقدر مهارت داره که با چی بنویسه برایش مطرح نیست، یا یه مبتدی ئه که از ابزار های آماده استفاده می کنه و اصلا کاری با زبان پایه اش نداره.بعد یه سئوال دیگه اینکه ، ویروس ها (حالا مثلا ویروس های حرفه ای) رو با سی شارپ و کلا زبان های تحت دات نت نمینویسن . درسته؟ چون باید اولا اون نسخه از دات نت فریم ورک توی سیسم کاربر نصب باشه (مثلا به کاربر بگن لطفا برای اجرای این ویروس ، اول دات نت را نصب کن
درسته؟
protected override bool ProcessDialogKey(Keys keyData)
{
if (keyData == Keys.Tab)
return false;
return base.ProcessDialogKey(keyData);
}Ctrl Alt Del رو نه. در سیستم عامل های قدیمی میشد ولی چون یک ترکیب کلیدی سیستمی ئه دیگه به برنامه ها اطلاع داده نمیشه.
رویداد Click یک رخداد خارجیه، باید جایی فراخوانی بشه تا اتفاق بیافته، باید Invoke بشه. و Invoke شدنش هم توسط OnClick یا هر متد دیگه ای که اینکار رو بکنه انجام میشه، نه خود به خودی.
سلام. ممنون
int b = 300000;
Button[] a = new Button[b];
for (int i = 0; i < a.Length; i++)
{
a[i] = new Button();
}
for (int i = 0; i < a.Length; i++)
{
a[i] = null;
}
a = null;
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect(); private void FormTest_Click(object sender, EventArgs e)
{
MessageBox.Show("FormTest_Click");
} private void button19_Click(object sender, EventArgs e)
{
MessageBox.Show("button19_Click");
} protected override void OnClick(EventArgs e)
{
MessageBox.Show("OnClick in override");
base.OnClick(e);
}باز هم ناقصه و چیزی نیست که شما میخواهید، گرچه دلیل موجهی برای استفاده ازش نخواهید داشت ولی توضیحش اینه، GC داره مستقل برای خودش کار می کنه، دوره ای و به تدریج اشیاء بلا استفاده رو از روی تعداد ارجاع ها شناسایی می کنه و آزاد شون می کنه. پروسه اش هم مستقل ئه و به پروسه برنامه شما کاری نداره. حالا وقتی شما درخواست Collect می کنید، GC تلاش می کنه که مواردی که تا اون لحظه شناسایی شده رو آزاد کنه و به این معنی نیست که برای شناسایی موارد جدید وقت صرف کنه و به این معنی هم نیست که Collect نخ برنامه شما رو متوقف کنه تا وقتی که کارش تموم بشه. اون WaitForPendingFinalizers اینجا نقش اش اینه که تا وقتی که GC در حال کاری مثل Collect هست نخ برنامه شما رو منتظر نگه داره. نه به این معنی ئه که GC رو مجبور به تلاش خاص اضافه ای بکنه و نه به معنی آزاد کردن حافظه های بیشتری ئه. فقط از این جهت کاربرد داره که آماری که میخواهید بعد از Collect رو بگیرید، بعد از این WaitForPendingFinalizers بگیرید تا اگه GC داشت کاری انجام میداد، آمار شامل اونها هم بشه. صرفا همینه. در حالت عادی وقتی شما Collect رو اجرا می کردید و بعد آمار می گرفتید فرصت خاصی نداده بودید که اول Collect تموم بشه و بعد آمار بگیرید، ولی وقتی WaitForPendingFinalizers اجرا شد منتظر میمونید تا کار تموم بشه. اون Collect دومی هم که نوشتید یه مورد اضافه و مستقل ئه که ربطی به این روال و توضیحات نداره. اگر شیء ای در Collect اول آزاد نشد احتمالا دلیلی برای آزاد شدن در Collect دومی هم نداره.
شما کلیک روی پنجره دکمه button19 رو مرتبط میدونید با کلیک روی پنجره فرم؟ خوب اینا که اصلا ربطی بهم ندارند. پنجره هاشون سوا است، رخداد هاشون سواست، Message هاشون سوا است. مادامی که دکمه Enable باشه یا بصورت فنی پنجره ای کلیک پذیر باشه پنجره زیرینش کلیک رو دریافت نمی کنه.
