PDA

View Full Version : انتقال داده ها میان فرم ها چه جوری میباشد؟



am_abbas65
شنبه 30 تیر 1386, 18:05 عصر
سلام میخواستم بدونم که چطور میتونم محتوای یک text box رو از فرم A به text box فرم B انتقال دهم ؟

اَرژنگ
شنبه 30 تیر 1386, 18:28 عصر
سلام میخواستم بدونم که چطور میتونم محتوای یک text box رو از فرم A به text box فرم B انتقال دهم ؟
در فرم ب یک متد باپلیک تعریف کنید که یک استرینگ را بگیره، و نشان بده، از فرم آ این متد را با مقدار تکست باکس صدا بزنید

jafari_m246
پنج شنبه 04 مرداد 1386, 06:55 صبح
سلام
می خواستم ببینم می شه یک کم بیشتر در مورد راه حلی که گفتید توضیح بدید؟

shotshat
پنج شنبه 04 مرداد 1386, 08:24 صبح
یکی از راه ها اینه که Text اون TextBox رو به عنوان پارامتر به فرم دومت پاس بدی برای این منظور باید سازنده فرم دومت رو هم عوض کنی

کد:
string text="";public Form2(string temp){ text=temp; InitializeComponent();}
موقع فراخوانی فرم دومت محتوای TextBox رو به اون پاس بده

کد:
f2=new Form2(TextBox1.Text);f2.showdialog();

shotshat
پنج شنبه 04 مرداد 1386, 08:33 صبح
نمی دونم چرا کدهایی که می نویسم به هم میریزه چه جوری میشه یه کد سالم فرستاد؟:(
به هر حال کدش اینه. امیدوارم با اینکه پرانتزاش جابجا شده متوجه بشی
string text="";
public Form2(string temp)
{
text=temp;
InitializeComponent();
}
-----------------------------------------------
f2=new Form2(TextBox1.Text);
f2.showdialog();

jafari_m246
جمعه 05 مرداد 1386, 06:38 صبح
مرسی عزیزم
امتحان می کنم اگه جواب نداد دوباره مزاحمت می شوم
برای اینکه کد هات به هم نریزه دکمه حالت ÷یشرفته را این پایین امتحان کن و در اون پنجره می توانی کد ات را بین تگ هائی که مخصوص کد است بنویسی
دکمه # اون بالا

hdv212
جمعه 05 مرداد 1386, 12:28 عصر
یکی از بهترین راه های انتقال پارامترها به فرم های مختلف، ایجاد یه کلاسه که پارامترها رو در خودش نگه داره، برای این منظور یه کلاس Static بسازید و یه پارامتر هم نوعی که میخواید به فرم ها انتقال بدید از نوع static بسازید و خیلی راحت در زمان لازم پارامتر مربوطه رو از کلاس فراخوانی کنید و مقدار رو درش ذخیره کنید، و در جایی که میخواهید استفاده کنید دوباره فراخوانی کنید و مقدار رو ازش بگیرید. به این صورت دیگه لازم نیست از فرم هاتون توی همدیگه آبجکت بسازید و فضای رم رو اشغال کنید.

اَرژنگ
جمعه 05 مرداد 1386, 13:28 عصر
یکی از بهترین راه های انتقال پارامترها به فرم های مختلف، ایجاد یه کلاسه که پارامترها رو در خودش نگه داره، برای این منظور یه کلاس Static بسازید و یه پارامتر هم نوعی که میخواید به فرم ها انتقال بدید از نوع static بسازید و خیلی راحت در زمان لازم پارامتر مربوطه رو از کلاس فراخوانی کنید و مقدار رو درش ذخیره کنید، و در جایی که میخواهید استفاده کنید دوباره فراخوانی کنید و مقدار رو ازش بگیرید. به این صورت دیگه لازم نیست از فرم هاتون توی همدیگه آبجکت بسازید و فضای رم رو اشغال کنید.
با عرض پوزش ولی این این روش را به هیچ کس توصیه نمیکنم.
دلیلش هم این است که این همان روش استفاده از متغییر سراسری است ولی به جایه متغییر اینجا دارند از یک کلاس استفاده میکنند.
روش استفاده از یک تابع پابلیک که shotshat براش یک مثال زدند روش استاندرد شئی‌گراییست.

hdv212
جمعه 05 مرداد 1386, 14:25 عصر
با عرض پوزش ولی این این روش را به هیچ کس توصیه نمیکنم.
دلیلش هم این است که این همان روش استفاده از متغییر سراسری است ولی به جایه متغییر اینجا دارند از یک کلاس استفاده میکنند.

آرژنگ جان ممنون از توجهت، ولی این روش کاملا سازگار با منطق OOP است، اگر از ASP.Net استفاده کرده باشی، میبینی که کلاسی به نام Session داره که تقریبا از همین روش استفاده میکنه(البته منطق استفاده یکی هست ولی روشش کاملا فرق میکنه)، اصلا یکی از روشهای انتقال انتقالات که به برنامه نویسان asp.net پیشنهاد میشه، استفاده از یک کلاس برای انتقال اطلاعات (مثل نام، نام کاربری، پسورد، ایمیل و...)، بین صفحاته، البته من خودم هم قبلا از همون روشی که دوستان بیان کردن استفاده میکردم، ولی بعد دیدم با این روش خیلی ساده تر میشه پارامترهارو انتقال داد و اینکه کمتر کدنویسی و میکنی و .... .

اَرژنگ
جمعه 05 مرداد 1386, 15:17 عصر
آرژنگ جان ممنون از توجهت، ولی این روش کاملا سازگار با منطق OOP است، اگر از ASP.Net استفاده کرده باشی، میبینی که کلاسی به نام Session داره که تقریبا از همین روش استفاده میکنه(البته منطق استفاده یکی هست ولی روشش کاملا فرق میکنه)، اصلا یکی از روشهای انتقال انتقالات که به برنامه نویسان asp.net پیشنهاد میشه، استفاده از یک کلاس برای انتقال اطلاعات (مثل نام، نام کاربری، پسورد، ایمیل و...)، بین صفحاته، البته من خودم هم قبلا از همون روشی که دوستان بیان کردن استفاده میکردم، ولی بعد دیدم با این روش خیلی ساده تر میشه پارامترهارو انتقال داد و اینکه کمتر کدنویسی و میکنی و .... .
ASP.Net استفاده کردم وهمانطوری که خودتان هم گفتید روشش کاملا فرق میکنه به این دلایل
۱ـ سشن در ای‌اس‌پی‌ دات نت برایه محیط بدانه استیت هستش.
۲ـ دلیلی استفاده از سشن در ای‌اس‌پی‌ دات نت دلیل بر شئیگرایی بودن این روش نیست، راه درست‌تر رد و بدل اطلاعات در ای‌اس‌پی‌ دات نت استفاده از کوئری استرینگهاست ولی سشن این کار را به صورت خودکار انجام میده، درست که دسترسی به متغییرات را آسان میکنه، ولی این آسانی ربطی به اصول شئیگرایی نداره.
اگر این روش در ای‌اس‌پی‌ دات نت کار میکنه به این دلیل است معمولا وقتی که یک صفحه یک مقداری را در سشن ست میکنه صفحه‌ای که میخواد به آن مقدار دسترسی کنه یا خود همان صفحه است و یا صفحه‌ای بلافاصل بعدی.
حالا مشکل این کار چیه؟ مشکل این است که هر کی قابلیت دسترسی به این سشن را داره، و اگر پروژه بزرگ باشد (از ۲ صفحه بیشتر!) هیچ گارانتی‌ای نیست که مقدار را ابجکت دیگری عوض نکنه. یعنی همان مشکل که با گلوبال واریبل بود.
حالا اگر هردو فرم از یک ابجکت استفاده کنند. و این ابجکت را پاس بدند این با استفاده از روشهایه استاتیک فرق داره.
چونکه یک فرم وظیفه‌اش را میداند که با چه ابجکتی به چه نحوه‌ای برخورد کند، وگرنه همینطوری یک واریبل را یکجا ست کردند و انتظار داشتن که ابجکتی که قراره این مقدار را دریافت کند را نمیشه گارانتی کرد.
شئیگرائی فقط استفاده کردن از اشییا نیست بلکه با روش درست استفاده کردن ازاشیاست.
این لینک یک شروعی برایه اشکالات این روش است:
http://hem.passagen.se/erinyq/industrial/IndustrialStrength.e.html

در ای‌اس‌پی دات نت برایه اکثر پروژه‌ها استفاده از سشن هیچ اشکالی نداره ولی ویندوز فرمز داستان دیگری‌است.

Behrouz_Rad
جمعه 05 مرداد 1386, 16:24 عصر
راه درست‌تر رد و بدل اطلاعات در ای‌اس‌پی‌ دات نت استفاده از کوئری استرینگهاست ولی سشن این کار را به صورت خودکار انجام میده،

راه درست بستگی به مورد کاربرد داره!
استفاده از Query String تنها یکی از راه های انتقال هست.


اگر این روش در ای‌اس‌پی‌ دات نت کار میکنه به این دلیل است معمولا وقتی که یک صفحه یک مقداری را در سشن ست میکنه صفحه‌ای که میخواد به آن مقدار دسترسی کنه یا خود همان صفحه است و یا صفحه‌ای بلافاصل بعدی.

خیر اینطور نیست!
اگر صفحه ای قرار باشه از اطلاعات خودش استفاده کنه، این مقدار رو در ViewState قرار میده مگر اینکه نوعی باشه که قابلیت ذخیره در ViewState برای اون وجود نداشته باشه.
ممکنه من بخوام نام کاربری رو در Session ذخیره کنم و در تمامی صفحات پروژه اون رو نمایش بدم... ذکر واژه ی "معمولا" صحیح نیست.


حالا مشکل این کار چیه؟ مشکل این است که هر کی قابلیت دسترسی به این سشن را داره، و اگر پروژه بزرگ باشد (از ۲ صفحه بیشتر!) هیچ گارانتی‌ای نیست که مقدار را ابجکت دیگری عوض نکنه. یعنی همان مشکل که با گلوبال واریبل بود.

خیر به هیچ وجه اینطور نیست آرژنگ عزیز.
هیچ کاربری نمیتونه مقدار Session رو اگر امکانش توسط برنامه نویس فراهم نشده باشه تغییر بده.

موفق باشید.

Sajjad1364
جمعه 05 مرداد 1386, 16:32 عصر
با سلام
روشی که hdv212 گفت کاملا با اصول برنامه نویسی شئ گرا تطبیق داره چون تمام کلاسهای استاتیک اعضای ایستا دارند پس اگر در این کلاسها پارامترهایی ایجاد کنیم این پارامترها به منزله صفت (که در کلاسهای عادی صفت اند ,صفت)نیستند چون کلاس در بر گیرنده آنها هیچوقت نمونه سازی نمیشود پس هیچگاه این پارامترها از داخل اشیاء به عنوان صفت استفاده نمی شوند. در نتیجه اگر به آنها دسترسی مستقیم به عنوان متغیر سراسری داشته باشیم هیچگونه مغایرتی با OOP ندارد.

اَرژنگ
جمعه 05 مرداد 1386, 17:06 عصر
راه درست بستگی به مورد کاربرد داره!
استفاده از Query String تنها یکی از راه های انتقال هست.

منتها این روش به صریحی ( Explicit
اعلام میکنه که چه اطلاعاتی به چه صفحاتی قراره فرستاده بشند، یکی از خصوصیات کد خوب این است که داد میزنه چکاری انجام میده و جایه برایه گمان زدن نمییزاره که ممکنه که چه کاری انجام بده، برایه همین ریختن یک سری متغییر و امید داشتن به اینکه که تا موقعی که فرمی که قراره از این متغیرها استفاده کند کسی (منظور از کسی کاربر نیست بلکه یک برنامه نویس دیگر با کدش یا یک کد دیگر در جایه دیگراست) این متغییرها را عوض نکند .
سشن اینکار را به طریق تلویحا فهمانده شده (implicit
انجام میده و اگر برنامه نویس بیادش نگه نداره که یک متغییر بخصوص مقداری داره که قراره ازش استفاده بشه و تغییرش بده مشکل ایجاد میکنه. البته میشه گفت که چرا برنامه نویس یادش نگه نداره و یا اینکه قبل از مقدار دادن دوباره به متغییر چک نکنه که قبلا استفاده شد؟ ولی اینها مشکلاتی هستند که با استفاده از اینگونه روشها بوجود میاند، و از اول نداشتن مشکلات از بعدا حل کردنشان بهتر است.




خیر اینطور نیست!
اگر صفحه ای قرار باشه از اطلاعات خودش استفاده کنه، این مقدار رو در ViewState قرار میده مگر اینکه نوعی باشه که قابلیت ذخیره در ViewState برای اون وجود نداشته باشه.
ممکنه من بخوام نام کاربری رو در Session ذخیره کنم و در تمامی صفحات پروژه اون رو نمایش بدم... ذکر واژه ی "معمولا" صحیح نیست.


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




خیر به هیچ وجه اینطور نیست آرژنگ عزیز.
هیچ کاربری نمیتونه مقدار Session رو اگر امکانش توسط برنامه نویس فراهم نشده باشه تغییر بده.

موفق باشید.

منظور از " هر کی قابلیت دسترسی به این سشن را داره" ، در اینجا هر کی کاربر نیست، بلکه کد بود، باید میگفتم در هر جایه پروژه میشه مقادیر را به راحتی زیاد عوض کرد (راحتی زیاد به معنی اینکه انکپسولیشن نداره!). بازهم میگم که ریختن یک سری متغییرات در یک کلاس که هیچ گارنتی‌ای نیست که بین زمانی که مقادیر بهش داده میشند تا زمانی که مقادیر دوباره ازش خوانده میشند به شئگرئی ربطی نداره ولی راحتی استفاده‌اش خصوصا در ای‌اس‌پی دات‌نت در اکثر پروژه‌ها به شکستن اصول شئیگرایی میارزه.

مخلصیم:لبخندساده:

اَرژنگ
جمعه 05 مرداد 1386, 17:54 عصر
با سلام
روشی که hdv212 گفت کاملا با اصول برنامه نویسی شئ گرا تطبیق داره چون تمام کلاسهای استاتیک اعضای ایستا دارند پس اگر در این کلاسها پارامترهایی ایجاد کنیم این پارامترها به منزله صفت (که در کلاسهای عادی صفت اند ,صفت)نیستند چون کلاس در بر گیرنده آنها هیچوقت نمونه سازی نمیشود پس هیچگاه این پارامترها از داخل اشیاء به عنوان صفت استفاده نمی شوند. در نتیجه اگر به آنها دسترسی مستقیم به عنوان متغیر سراسری داشته باشیم هیچگونه مغایرتی با OOP ندارد.

نتیجه‌ای که گرفتید : " نتیجه اگر به آنها دسترسی مستقیم به عنوان متغیر سراسری داشته باشیم "
این روش مغایر با OOP است چونکه انکپسولیشن را نقض میکنه.

به این لینکها هم یک نگاهی بندازید :

تعریف متغیر سراسری (http://barnamenevis.org/forum/showthread.php?t=69995)
مقاله: Static در C# (http://barnamenevis.org/forum/showthread.php?t=70019)


البته استفاده از کلاسهآیه استاتیک دلیلهایه دیگر داره ولی به "انتقال داده ها میان فرم ها چه جوری میباشد؟ (http://barnamenevis.org/forum/showthread.php?p=371257#post371257)" هیچ ربطی ندارند.

در ضمن : استفاده از صفت و فعل و ... روش کتابهایه قدیمی است که سعی میکردند طرزه تفکر در OOP را به این طریق یاد بدند که الان طرزه دیدهایه جدیدتری آمده، یکی از روشهایه جدید در این کتاب اشاره شده:
Design Patterns Explained: A New Perspective on Object-Oriented Design
http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0201715945

برایه آگاهی به مشکلاتی که استفاده از استاتیک میتواند بیافریند به این صفحه یک نگاه بندازید:
http://www.developer.com/java/other/article.php/1025601
اگرچه برایه جاوا ‌است ولی بیشتر دلیل‌ها در سی‌شارپ هم صادق هستند.

Sajjad1364
شنبه 06 مرداد 1386, 15:32 عصر
نتیجه‌ای که گرفتید : " نتیجه اگر به آنها دسترسی مستقیم به عنوان متغیر سراسری داشته باشیم "
این روش مغایر با OOP است چونکه انکپسولیشن را نقض میکنه.


1-خیر با انکپسولیشن مغایر نیست چون عناصر استاتیک فقط بوسیله نام کلاس در دسترس قرار می گیرند.و همانطور که گفتم چون عناصر استاتیک در هیچ یک از نمونه های ساخته شده از یک کلاس وجود ندارند پس هرگز هیچ شی ای این عناصر را در داخل خود نمی بیند.
Encapsulation برای امنیت اشیاء و قرار نگرفتن شئ در وضعیتی نا مطلوب صفات را مشمول قوانین خود میسازد برای مثال فرض کنیم که در یک فرروشگاه شیی بنام آیتم داریم این شئ
در داخل خود متغیری بنام تخفیف دارد, مقداری از 0 تا 100( که مقدار تخفیف است)رادر برمیگیرد .اگر متغیر تخفیف را در تعریف کلاس عمومی در نظر بگیریم,کاربر می تواند مقدار تخفیف را بیشتر از 100تعیین کند که در اینصورت خریدار به ازای خرید آن جنس پولی هم دریافت میکند.این نوع دسترسی شئ را در وضعیت نامطلوب و نادرستی قرار میدهد.هرچند شئ هیچگونه اشتباهی انجام نداده اما بوسیله داده های اشتباه که بدلیل عدم رعایت قوانین Encapsulation است در وضعیت کاملا اشتباهی قرار گرفته است.اما اعضای استاتیک در وضعیت شئ هیچگونه دخالتی ندارند(چون در اشیاء وجود ندارند)پس استفاده از آنها ناقض Encapsulation نیست.


2-از طرفی اگر فیلد مورد نظر را در یک کلاس استاتیک قرار بدهیم این کلاس فقط دربرگیرنده عناصر استاتیک خواهد بود وبس و نیز با توجه به تعریف کلاس ها در برنامه نویسی شئ گرای خالص که از مفاهیم متا کلاس نشات میگیرد ,خود کلاس ها نیز شئ محسوب میشوند.در نتیجه یک کلاس استاتیک را میتوان با توجه به تعریف خالص تر آن در مفاهیم متا کلاس ,یک شئ استاتیک نام برد.از طریق دسترسی اشتباه به یک شئ میتوان آن شئ را دروضعیت نامطلوب و خلاف واقع قرار داد اما اشیاء استاتیک بدلیل اینکه همیشه دارای وضعیت ثابت و مستقل هستند پس به ازای هر داده ای در وضعیت نامطلوب قرار نمی گیرند و دسترسی به اعضای استاتیک هیچگونه خللی در کار آنها بحساب نمی آید.


در ضمن : استفاده از صفت و فعل و ... روش کتابهایه قدیمی است که سعی میکردند طرزه تفکر در OOP را به این طریق یاد بدند که الان طرزه دیدهایه جدیدتری آمده.

صفت در برنامه نویسی شئ گرا مفهوم محسوب میشوند نه یک اصطلاح یا واژه که از طریق آن برنامه نویسی شئ گرا را تعلیم داد.اگر شما مایل بودید میتوانم صفت وهر چیزی که شما آنرا قدیمی می پندارید توضیحاتی چند صفحه ای ارایه کنم.
راستی اگر امکان دارد بجای مثلا صفت یا خاصیت کلمه ای مناسب برای این مفاهیم که در کتابهای جدید وجود دارند در اختیار من بگذارید.
ممنون..

اَرژنگ
شنبه 06 مرداد 1386, 19:31 عصر
1-خیر با انکپسولیشن مغایر نیست چون عناصر استاتیک فقط بوسیله نام کلاس در دسترس قرار می گیرند.و همانطور که گفتم چون عناصر استاتیک در هیچ یک از نمونه های ساخته شده از یک کلاس وجود ندارند پس هرگز هیچ شی ای این عناصر را در داخل خود نمی بیند.
Encapsulation برای امنیت اشیاء و قرار نگرفتن شئ در وضعیتی نا مطلوب صفات را مشمول قوانین خود میسازد برای مثال فرض کنیم که در یک فرروشگاه شیی بنام آیتم داریم این شئ
در داخل خود متغیری بنام تخفیف دارد, مقداری از 0 تا 100( که مقدار تخفیف است)رادر برمیگیرد .اگر متغیر تخفیف را در تعریف کلاس عمومی در نظر بگیریم,کاربر می تواند مقدار تخفیف را بیشتر از 100تعیین کند که در اینصورت خریدار به ازای خرید آن جنس پولی هم دریافت میکند.این نوع دسترسی شئ را در وضعیت نامطلوب و نادرستی قرار میدهد.هرچند شئ هیچگونه اشتباهی انجام نداده اما بوسیله داده های اشتباه که بدلیل عدم رعایت قوانین Encapsulation است در وضعیت کاملا اشتباهی قرار گرفته است.اما اعضای استاتیک در وضعیت شئ هیچگونه دخالتی ندارند(چون در اشیاء وجود ندارند)پس استفاده از آنها ناقض Encapsulation نیست.


2-از طرفی اگر فیلد مورد نظر را در یک کلاس استاتیک قرار بدهیم این کلاس فقط دربرگیرنده عناصر استاتیک خواهد بود وبس و نیز با توجه به تعریف کلاس ها در برنامه نویسی شئ گرای خالص که از مفاهیم متا کلاس نشات میگیرد ,خود کلاس ها نیز شئ محسوب میشوند.در نتیجه یک کلاس استاتیک را میتوان با توجه به تعریف خالص تر آن در مفاهیم متا کلاس ,یک شئ استاتیک نام برد.از طریق دسترسی اشتباه به یک شئ میتوان آن شئ را دروضعیت نامطلوب و خلاف واقع قرار داد اما اشیاء استاتیک بدلیل اینکه همیشه دارای وضعیت ثابت و مستقل هستند پس به ازای هر داده ای در وضعیت نامطلوب قرار نمی گیرند و دسترسی به اعضای استاتیک هیچگونه خللی در کار آنها بحساب نمی آید.



صفت در برنامه نویسی شئ گرا مفهوم محسوب میشوند نه یک اصطلاح یا واژه که از طریق آن برنامه نویسی شئ گرا را تعلیم داد.اگر شما مایل بودید میتوانم صفت وهر چیزی که شما آنرا قدیمی می پندارید توضیحاتی چند صفحه ای ارایه کنم.
راستی اگر امکان دارد بجای مثلا صفت یا خاصیت کلمه ای مناسب برای این مفاهیم که در کتابهای جدید وجود دارند در اختیار من بگذارید.
ممنون..

موضوِع استفاده از استاتیک و یا غیره استاتیک نیست، موضوع این است که یک متغییر را یکجا ست میکنید، و بعدش
همینطوری از جاهایه دیگر برنامه استفاده میکنید. حالا فرق این روش با استفاده از متغییر سراسری چی هست؟
اگر این روش درست است پس استفاده از نتایج سراسری هم درست است ( که معلوما نیست و نتیجتا این روش برایه رد و بدل اطلاعات بین دو فرم اشتباه است).

صفت فقط به خودی خود یک مفهوم کامل در برنامه نویسی شئیگرا نیست، مفهومات دیگر هم وجود دارند که در جایه خودشان ارجعیت میگریند، کتابی را که لینک دادم در این مورد مطلب دارد.

حالا به فرض هم بگییم که این روش ، روش شئئیگراست. اآیا استفاده از این روش که مانند استفاده از متغییر سراسریست درست است؟
من در مورد شئیگرا بودن و یا نبودن این روش چیزی ندارم که به بحث اضافه کنم، ولی در مورد درست بودن و یا نبودن این روش برایه رد و بدل اطلاعات بین دو فرم میتوانم ادامه بدم.


مخلصیم

Sajjad1364
شنبه 06 مرداد 1386, 21:49 عصر
موضوِع استفاده از استاتیک و یا غیره استاتیک نیست، موضوع این است که یک متغییر را یکجا ست میکنید، و بعدش
همینطوری از جاهایه دیگر برنامه استفاده میکنید. حالا فرق این روش با استفاده از متغییر سراسری چی هست؟
اگر این روش درست است پس استفاده از نتایج سراسری هم درست است ( که معلوما نیست و نتیجتا این روش برایه رد و بدل اطلاعات بین دو فرم اشتباه است).

البته از این نظر که شما میگویید فرقی بین استفاده از این دو روش وجود ندارد تقریبا درست میگویید.تنها فرق بین این دو روش این است که کلاسها در این موضوع درگیر شده اند.

صفت فقط به خودی خود یک مفهوم کامل در برنامه نویسی شئیگرا نیست، مفهومات دیگر هم وجود دارند که در جایه خودشان ارجعیت میگریند، کتابی را که لینک دادم در این مورد مطلب دارد.

به نظر من صفت بعد از مفهوم شئ ,کاملترین مفهوم در برنامه نویسی شئ گراست.اگر بخواهیم به برنامه نویسی شئ گرا با استفاده از طبیعت بنگریم آنگاه OOP را فقط در دنیایی از صفات می بینیم.


حالا به فرض هم بگییم که این روش ، روش شئئیگراست. اآیا استفاده از این روش که مانند استفاده از متغییر سراسریست درست است؟

ظاهرا سوء تفاهم شد.
من هم با نظر شما در تاپیک قبلی که گفتید این روش شئ گرا نیست موافقم.اما بحثی که من کردم فقط در مورد این بود که اگر از متغیر استاتیک در کلاسی استاتیک استفاده کنیم, چون کلاس استاتیک در برنامه نویسی شئ گرا جایی ندارد پس Encapsulationدر این مورد نمیتواند تعیین کند که آیا این روش شئ گرا هست یا خیر.اما من از این نظر با شما موافقم که
این روش اصلا شئ گرا نیست.(البته از دیدگاه کلی برنامه نویسی شئ گرا نهEncapsulation)


من در مورد شئیگرا بودن و یا نبودن این روش چیزی ندارم که به بحث اضافه کنم، ولی در مورد درست بودن و یا نبودن این روش برایه رد و بدل اطلاعات بین دو فرم میتوانم ادامه بدم.

من روشی شئ گرا برای ارائه دارم.
ابتدا باید متغیری را که می خواهیم مقدار آن را در تمام طول اجرای برنامه داشته باشیم در فرم مورد نظر تعریف کنیم(مثلا a) سپس متعاقب آن یک Property را با همان نام ایجاد میکنیم


public

partial classForm1 : Form


{
private static int a;
public static int A
{
get { return Form1.a ; }
}
public Form1()
{
InitializeComponent();
}
}





بعد تعریف کلاسی مناسب با یک سازنده استاتیک.این سازنده یک مقدار اولیه را مثلا از Form1 دریافت میکند و بعد ما میتوانیم از طریق خصوصیت ReturnValue به این مقدار ثابت دسترسی داشته باشیم.به این ترتیب هم متغیر سراسری تعریف نمیشود و هم Encapsulation نقض نمیشود.




class





MyClass


{
static private int returnValue;
public static int ReturnValue
{
get { return MyClass.returnValue; }
}
static MyClass()
{
returnValue = Form1.A;
}
}





ما بیشتر...

Asad.Safari
یک شنبه 07 مرداد 1386, 01:56 صبح
هیچکدام از روش های شما به درد pass message نمی خوره !
برای اینکه بتونید به راه حل برسید در داخل MSDN دنبال Pass Message between forms بگردید !

در اونجا خودش یه مثال جالبی دارد.


موفق باشید

اَرژنگ
یک شنبه 07 مرداد 1386, 04:29 صبح
هیچکدام از روش های شما به درد pass message نمی خوره !
برای اینکه بتونید به راه حل برسید در داخل MSDN دنبال Pass Message between forms بگردید !

در اونجا خودش یه مثال جالبی دارد.


موفق باشید
اگر منظورتان http://msdn2.microsoft.com/en-us/library/ms993020.aspx
است برایه کارهایه نوع دیگری به کار میاد. .

jafari_m246
یک شنبه 07 مرداد 1386, 08:29 صبح
سلام
می شه یک کم زیردیپلم بگیدتامن بی سواتم بفهمم
مثلا اگر می شه بگید اون دو تا کدی که آقای shotshat گفته اند را باید کجا بنویسیم

البته من با این کدها مشکل اصلی ام را حل کردم


mainfrm mnfrm = newmainfrm();
this.Hide();
mnfrm.Show();
mnfrm.Owner = this;
mnfrm.Text =textBox1.Text.Trim ();


ولی حالا که می خوام شرط بگذارم بلد نیستم
کد زیر هم جواب نمی دهد



mainfrm mf=newmainfrm ();
if (mf.Text == "ali".Trim())
{
MessageBox.Show("شما اجازه دسترسی به این قسمت راندارید");
}
else
{
defineuser dfusr = newdefineuser();
dfusr.Show();
}

تو این کد برای همه فرم بعدی را باز می کنه