درباره unicode

[tdkhakpur]

بسیاری از تاپیکهای ارسال شده در این مورد بوده که چرا بعضی از نسخه های دلفی از unicode پشتیبانی نمیکنند و یا اینکه چرا بعضا علامت سوال داخل کنترلها نمایش داده میشود؟
در بسیاری از جاها و مطالب بیان میشود که یک نسخه از Unicode پشتیبانی میکندو در نسخه ای دیگر پشتیبانی نمیکند که این مطلب کاملا اشتباه بوده و وجه کاربردی ندارد!!
جواب و نتیجه این سوال خیلی راحت هست و بسیاری این سوال را تبدیل به مقاله میکنند در صورتی که در بعد نرم افزاری و کاری بسیار راحت تر از نئوری میتواند بیان شود.
شما به فرض دو نسخه 2007 و 2009 از دلفی را درنظر بگیرید که اولی از unicode پشتیبانی نمی کند ولی دیگری از این نوع پشتیبانی میکند.
مثال برای 2007


Button1: TButton;

در حالت فوق اگر کلاس Button را بصورت زیر در نظر بگیرید


type
TButton = class(TButtonControl)
private
public:
Caption: AnsiString;
و غیره
end;

در فوق می بینید که caption از نوع ansistring بود و اگر ساختار داخلی ansistring را مشاهده کنید خواهید دید که داده ها در بازه 0 تا 255 را در خود ذخیره و سایر اعمال را روی این بازه انجام میدهند
ولی اگر 2009 بصورت زیر در نظر داشته باشید که تعریف ان به شکل زیر باشد:


Button1: TButton;

به فرض اگر Button موجود در 2009 به شکل زیر ساخته شده و از بونیکد حمایت کرده باشد


type
TButton = class(TButtonControl)
private
public
Caption: WideString;
و غیره
end;

در دو حالت فوق تغییر در خود داده موجود در caption روی داده است(البته با ارتقاء نسخه قابلیتها هم افزایش پیدا میکند.)
شما میتوانید در هر نسخه از دلفی قابلیت حمایت از unicode را به کنترلها بیفزایید مثال زیر حمایت از unicode را با مشتق از button رجیستر شده موجود در پلت فرم را بصورت زیر بیان می کند


MyUnicodeButton = class(TButton)
private
function GetCaption: WideString;
procedure SetCaption(const Value: WideString);
public
published
property Caption: WideString read GetCaption write SetCaption; // یا تعریف خاص خودتان
end;

procedure MyUnicodeButton.SetCaption(const Value: WideString);
begin
GetCaption; // اینجا باید کپشن دریافتی را به یونیکد تبدیل و ارسال کنید
end;
//---------------------------------
function MyUnicodeButton.GetCaption: WideString;
begin
Result := محتوای کپشنی که بصورت یونیکد درامده است
end;

کدهای فوق الگوریتم این تغییر هست که شما میتوانید انجام بدید.
با توجه به مطالب و کدهای الگوریتمی فوق میتوان نتیجه گرفت که خود کامپوننت میتواند این امکان را برای تمامی نسخه ها فراهم آورد.

[vcldeveloper]

در بسیاری از جاها و مطالب بیان میشود که یک نسخه از Unicode پشتیبانی میکندو در نسخه ای دیگر پشتیبانی نمیکند که این مطلب کاملا اشتباه بوده و وجه کاربردی ندارد!!اتفاقا مطلب صحیحی هست.



در دو حالت فوق تغییر در خود داده موجود در caption روی داده است(البته با ارتقاء نسخه قابلیتها هم افزایش پیدا میکند.)
شما میتوانید در هر نسخه از دلفی قابلیت حمایت از unicode را به کنترلها بیفزایید مثال زیر حمایت از unicode را با مشتق از button رجیستر شده موجود در پلت فرم را بصورت زیر بیان می کنداگر به همین راحتی بود که تیم توسعه دلفی این همه سال برای پشتیبانی از یونیکد معطل نمی کرد!
در این راهکار شما چند مشکل عمده وجود داره:
اولا، در همچین روشی، شما باید کلیه فیلدهای string همه کامپوننت ها را باز-تعریف کنید، که این خودش کار کمی نیست! به فرض هم که این کار رو کردید، باز کد شما با کد کامپوننت های سایر شرکت ها که نصب می کنید، سازگار نیست، مگر اینکه هر کامپوننتی نصب می کنید، بشینید و یکی یکی همه فیلدهای string اون رو باز تعریف کنید.

ثانیا، اگر شما موفق می شدید فیلدهای string همه کامپوننت های نوشته شده برای دلفی را هم باز-تعریف کنید؛ باز کامپوننت های مربوطه همگی سازگار با یونیکد نمی شدند؛ چون؛ شما از طریق Inheritance (ارث بری) فقط به خصوصیات و فیلدهای protected، public و published دسترسی دارید، در نتیجه اگر همه فیلدها و خصوصیات قابل دسترسی را هم به این شکل باز-تعریف کنید، همچنان کامپوننت مربوطه 100% یونیکد نمیشه، چون در ساختارهای درونی خودش همچنان از رشته های ANSI استفاده کرده، و کافی هر کدوم از این خصوصیات و فیلدهای شما داده های یونیکدشان داخل یکی از این فیلدهای داخلی قرار بگیره، تا کل اطلاعات یونیکدش از بین بره.

ثالثا، دلفی خودش یک کتابخانه زمان-اجرا بزرگ داره که در بخش های مختلف آن از داده های string استفاده شده، به علاوه انواع توابع کار با string؛ در برنامه شما، اگر همه کامپوننت ها هم بر فرض یونیکد باشند، اگر در حین کار با داده ها هر یک از کدهای RTL دلفی که به نوعی با داده string سر و کار دارند، روی این داده های یونیکد شما کاری انجام بدند، داده یونیکد شما از بین میره! پس باید بخش های زیادی از RTL دلفی را هم بازنویسی کنید!



Caption: WideString;توی دلفی 2010 فیلدها و خصوصیات string به صورت WideString تعریف نشدند! بلکه از یک نوع داده جدید با نام UnicodeString استفاده می کنند.
نوع داده WideString در دلفی با string سازگار هست، ولی از نظر پیاده سازی و قابلیت معادل string یونیکد شده نیست! نوع داده WideString یک نوع داده مخصوص COM هست، که توسط COM در ویندوز هم مدیریت میشه؛ به همین دلیل هم کارایی اون نسبت به AnsiString یا UnicodeString بسیار پایین تر هست. برای همین هم در دلفی 2009 یا دلفی 2010 از نوع داده جدید UnicodeString برای نگهداری رشته های یونیکد استفاده میشه، نه از نوع داده WideString. حالا اگر تیم توسعه دلفی میخواست هر جا که از string استفاده شده، از WideString استفاده کنه، باید منتظر کاهش سرعت اجرای بسیاری از کدهای برنامه نویسان هم می شد!

[tdkhakpur]

اتفاقا مطلب صحیحی هست.

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

توی دلفی 2010 فیلدها و خصوصیات string به صورت WideString تعریف نشدند! بلکه از یک نوع داده جدید با نام UnicodeString استفاده می کنند.
برای همین هم در دلفی 2009 یا دلفی 2010 از نوع داده جدید UnicodeString برای نگهداری رشته های یونیکد استفاده میشه، نه از نوع داده WideString.

من نسخه را برای مثال عرض کرده بودم!


اگر به همین راحتی بود که تیم توسعه دلفی این همه سال برای پشتیبانی از یونیکد معطل نمی کرد!


من به کمپانی کاری ندارم کسانی هستند که کامپوننتهای دست ساز میسازند که خارج از محدوده قوانین پلت فرمهاست و برای نسخه پایینتر از 2010 مانند 2006 هم کامپوننتهای طراحی شده که از unicode پشتیبانی مییکند.

ثانیا، اگر شما موفق می شدید فیلدهای string همه کامپوننت های نوشته شده برای دلفی را هم باز-تعریف کنید؛ باز کامپوننت های مربوطه همگی سازگار با یونیکد نمی شدند؛
لازم به این همه دقت نیست فقط کافی چرخه نیاز پیغامها را تنظیم و داده ها را به درستی تغییر بدید.
مخصوصا این قسمت


property Caption: WideString read GetCaption write SetCaption;

[vcldeveloper]

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


من نسخه را برای مثال عرض کرده بودم!
شما مثل اینکه متوجه نشدید، من چی گفتم! در نسخه های قدیمی دلفی، شما فقط WideString دارید، و WideString هم مشکل Performance داره. پس شما باید یک Data Type جدید داشته باشید که هم یونیکد باشه، و هم Performance hit نداشته باشه.


من به کمپانی کاری ندارم کسانی هستند که کامپوننتهای دست ساز میسازند که خارج از محدوده قوانین پلت فرمهاست و برای نسخه پایینتر از 2010 مانند 2006 هم کامپوننتهای طراحی شده که از unicode پشتیبانی مییکند.
کسانی که کامپوننت می سازند، با کسانی که از کامپوننت استفاده می کنند؛ خیلی فرق دارند. کسی که خودش کامپوننت می نویسه، میتونه کامپوننت خودش را از پایه طوری طراحی کنه که در نسخه های قدیمی دلفی، همواره از WideString به جای string استفاده کنه، و مواطبت کنه که در کدش از توابع API یونیکد استفاده کنه، و از توابع RTL ایی که ممکنه رشته های یونیکدش را از بین ببرند، استفاده نکنه. این محدود به کامپوننت خودش هست، و در محدوده کامپوننت خودش، دستش بازه. این همون کاری هست که فرضا کامپوننت هایی مثل FastReport یا مجموعه dbGo در نسخه های قدیمی دلفی انجام میدند.

کاری که شما دارید انجام می دید، با کاری که اون کامپوننت نویس ها انجام میدند، زمین تا آسمان فرق میکنه! شما دارید برای کامپوننت های دیگران، که روی آنها کنترل کاملی ندارید، یک Wrapper ساده می نویسید، و در آن بعضی از خصوصیات و فیلدهای string را تبدیل به WideString می کنید؛ و فکر می کنید که تونستید کامپوننت را یونیکد کنید! در حالی که هیچ کنترلی روی عملکرد فیلدها و متدهای private اون کلاس ها ندارید.

حتی برای همون کدی که نوشتید، پیاده سازی مربوط به GetCaption و SetCaption ایی که در پست اول نوشتید رو قرار ندادید. اون متدهای SetCaption و GetCaption داده مورد نظر رو کجا ذخیره می کنند؟ در خصوصیت Caption مربوط به کلاس والد (TButtonControl)؟ اون خصوصیت که خودش AnsiString هست، و اگر داده یونیکد درش ریخته بشه، اطلاعات یونیکد از بین میره! یا اینکه میخواید به ازاء هر خصوصیت string در کامپوننت تان، خودتان یک فیلد WideString هم تعریف کنید، و به جای استفاده از خصوصیت مربوطه در کلاس والد، از این فیلد استفاده کنید؟! در اون صورت هم متدهای Internal اون کلاس با فیلد شما کار نخواهند کرد، و فیلد AnsiString خودش را میشناسه. یا اینکه میخواید خودتون یک Encoding خاص رو برای نگهداری داده یونیکد در همون فیلد Caption کلاس والد استفاده کنید؟

تازه این فقط مربوط به کنترل ها ست، و همانطور که گفتم، بحث توابع RTL جدا ست، و بسیاری از اونها باید بازنویسی بشند!

همونطوری که می بینید، برخلاف تصور شما، این کار ساده ایی نیست؛ حتی گروه هایی مثل تیم توسعه TNT Components هم وقتی از WideString به جای String استفاده کردند، مجبور شدند که برای همه کامپوننت های استاندارد یک Wrapper بنویسند، و بسیاری از چیزها را - بخصوص تعداد زیادی از کلاس ها و توابع RTL دلفی را - خودشان پیاده سازی کنند.

متاسفانه در اموری که اطلاعات کافی از آنها ندارید، اظهار نظر می کنید؛ و زمانی هم که کسی اشتباه تان را بهتون گوشزد میکنه، سریع با اظهار نظرهای عجیب و غریب، جبهه گیری می کنید!

[tdkhakpur]

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

[vcldeveloper]

خب برادر جان وقتی ویندوزی که الان دم دست داری و میتوانی در انواع نسخه های دلفی کار کنی (به قول خودت یکی unicode داره و دیگری نه) چرا قبول نمیکنی که این کار عملی هست و به نسخه ارتباطی ندارد؟
خب عقل اون تیم نرم افزاری دیرتر پی برده که باید unicode را هم به پروژه هایش اضافه کنه.
در پست قبل توضیح دادم که درباره اموری که اطلاع کافی ازش ندارید، اظهار نظر می کنید!
برای اینکه زبان برنامه نویسی شما تشکیل شده از یک کامپایلر + یک کتابخانه کلاس ها و توابع؛ کتابخانه کلاس ها و توابع مربوطه هم توسط شما نوشته نشده، بلکه توسط دیگران نوشته شده، و شما هم کنترل کاملی روی آن ندارید؛ اینها مفهوم هست؟! حالا یکی می تونه بیاد مثل شما، فکر بکری از خودش ارائه بده، و بگه، بیایم همه این کتابخانه کلاس ها و توابع را باز نویسی کنیم؛ اینطوری ما در نسخه های قدیمی دلفی هم یونیکد خواهیم داشت! خب مشکلش چی هست؟ مشکلش این هست که اولا اون دیگران مثل شما وقت اضافه ندارند که یک کتابخانه ایی که در طول 15 سال توسعه داده شده را خودشان مجددا بازنویسی کنند. همچنین اون دیگران دوست ندارند که هر زمان که نسخه جدیدی از زبان برنامه نویسی شان عرضه شد، و تغییراتی در آن ایجاد شد، کتابخانه باز نویسی شده خودشان را با سازگاری با تغییرات مربوطه بازنویسی کنند. همچنین، اون دیگران علاقه ندارند (و اصلا حق ندارند) که اگر از کامپوننت سایر شرکت ها برای کار خاصی استفاده کردند، بشینند که و کل آن کامپوننت را هم برای سازگاری با تغییرات خودشان ویرایش کنند.
حالا اگر کسی بیکار بود، و نشست کل VCL و کل RTL دلفی را با یونیکد سازگار کرد، و همه اون دردسرهای بالا را هم به جان خرید، باز به یک مشکل دیگه بر میخوره، اون هم افت سرعت در کل برنامه، به خاطر استفاده وسیع از WideString؛ حالا برای اینکه نخواد از WideString در حد گسترده استفاده کنه، باید خودش یک نوع داده پایه جدید تعریف کنه، خب برای اینکه این نوع داده پایه را تعریف کنه، باید کامپایلر دلفی رو تغییر بده. به سورس کامپایلر دلفی که دسترسی نداره، پس باید یک کامپایلر تازه هم بنویسه.

اینه که میگم درباره چیزی اطلاع ندارید، اظهار نظر می کنید.



انهایه تمام مطالب شما را خوندم چیزی جز تئوری نیست من دارم با عملی این تئوریها چند سال هست کار میکنم و شما اومدید از نشدن این کار حرف میزنید. .
عجب! با عملی چی دارید کار می کنید؟ از کامپوننت های رایگان و اوپن سورس TNT در نسخه های ANSI دلفی استفاده می کنید، یا نهایتا خیلی همت کرده باشید، کامپوننت هایی مشابه کامپوننت های TNT برای خودتان نوشتید، و فکر کردید با این کار دلفی یونیکد شد؟! همون TNT Components رو اگر سورسش را می دیدید؛ متوجه می شدید که عملا مجبور شده کلاس های پایه کنترل های دلفی، و کلاس های کنترل استاندارد دلفی را به همراه توابع و کلاس های RTL مربوط به کار با string را بازنویسی کنه. برای اینکه متوجه بشی برای همین مقدار سازگاری با یونیکد در TNT Components چقدر کار شده، باید بدونی که بیش از 40 هزار خط کد برای همین مقدار کار نوشته شده، و بیش از 300 کلاس جدید تعریف شده؛ تازه این فقط مربوط به کنترل های رایج دلفی در دلفی 7 هست، یعنی کنترل های کمتر رایج در اون لحاظ نشدند، کامپوننت های استانداردی هم که در نسخه های جدیدتر دلفی اضافه شدند، شامل این مجموعه نمیشند، و این مجموعه تاثیری هم در یونیکد شدن کامپوننت های 3rd party نوشته شده توسط سایر شرکت ها نداره، و اونها باید جداگانه یونیکد بشند!

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

[tdkhakpur]

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

شما خودتان را سرور و سالار همه میدانید! بر خلاف شما من زیاد وقت ندارم که برای شما طوماری برای اثبات حقانیت بنویسیم.
میل خودتان هست هر طوری فکر میکنید به خودتان ارتباط دارد شما بحث را میپیچونید تا ثابت کنید که حق با شماست بالاخره هیچ کس مادر زادیی که برنامه نویس نشده که ندانستن مطلب برای شما کسر شان باشد.
به هر صورت شما ادعا داشتید یونیکد به نسخه ارتباط دارد و من هم گقتم ندارد و شما باعث این همه ارسال مطلب بیخود شدید.
ضمنا زیاد در مورد سواد دیگران نظر ندید چون خیلی چیزها هست که باید برید سراغ google و یا کتابهای دم دست تا یاد بگیرید که همیشه خودتان را یک قدم از دیگران عقب تر بدانید.

[vcldeveloper]

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

در بسیاری از جاها و مطالب بیان میشود که یک نسخه از Unicode پشتیبانی میکندو در نسخه ای دیگر پشتیبانی نمیکند که این مطلب کاملا اشتباه بوده و وجه کاربردی ندارد!!
توضیحاتی که داد شد، کاملا گویای این مطلب هستند که یونیکد کردن کامل دلفی حداقل مستلزم تغییرات گسترده در RTLو VCL دلفی هست، که برخلاف تصور شما که نوشتید:

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

کار سنگینی هست، و آخرین تلاش عمومی برای انجام این سازگاری روی بخشی از کدهای RTL و VCL منجر به نوشته شدن بیش از 40 هزار خط کد در پروژه TNT Components شد. این مبحث جدای از این هست که حتی در اون صورت هم شما یک نوع داده Unicode با کارایی معادل string نخواهید داشت، و کارایی WideString نسبت به AnsiString و UnicodeString به شدت پایین هست.

حالا در مقابل این توضیحات فنی که برای شما داده شد، نه تنها جوابی ارائه نکردید، بلکه صرفا یک سری ادعاهای شخصی و مضحک مثل:

شما خودتان را سرور و سالار همه میدانید!

شما بحث را میپیچونید تا ثابت کنید که حق با شماست

مطرح کردید.

مدعی شدید که دارید به شکل عملی با اون "تئوری ها"ی مد نظر خودتون کار می کنید؛ اما مشخص نکردید که از چی استفاده کردید. البته در پست قبلی برای شما توضیح داده شد که شما یا از TNT Components استفاده کردید، یا نهایتا یک مجموعه کامپوننت مشابه آن نوشتید که نقاط ضعف آن در پست قبلی توضیح داده شد، و جوابی هم از شما داده نشد. در پست اول تاپیک هم فقط خصوصیت Caption را تعریف کردید، و از پیاده سازی متدهای GetCaption و SetCaption در اون کد طفره رفتید! البته ما رو روشن نکردید که در برابر اون انتقاداتی که از پیشنهادتون شد؛ منظورتون از "فقط کافی چرخه نیاز پیغامها را تنظیم و داده ها را به درستی تغییر بدید"، که قراره به ادعای خودتان به راحتی برای همه کامپوننت ها این کار قابل انجام باشه؛ چی هست! یعنی در برابر توضیحات فنی که برای شما ارائه شد، فقط ادعا کردید، و بس!


ضمنا زیاد در مورد سواد دیگران نظر ندید چون خیلی چیزها هست که باید برید سراغ google و یا کتابهای دم دست تا یاد بگیرید که همیشه خودتان را یک قدم از دیگران عقب تر بدانید.
لازم نیست من نظری درباره سواد شما یا امثال شما بدم؛ سواد هر فرد در یک حوزه مشخص تا زمانی پنهان هست که فرد درباره مسئله ایی در اون حوزه مشخص اظهار نظر نکرده باشه؛ وقتی اظهار فضل کرد، آشکار میشه که چقدر در اون زمینه خاص سواد داره.

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

برای من اهمیتی نداره که شما چیزی رو قبول کنید یا نکنید؛ بلکه این مهم هست که در این سایت مطالب صحیح از ناصحیح مشخص بشند. مشکلات طرح مورد نظر شما هم به طور فنی مطرح شدند، و هر کس به این تاپیک رجوع کنه، میتونه مطالب را ببینه. شما خواستی قبول کن، خواستی نکن؛ کسی که خودش رو به خواب زده، نمیشه به زور بیدار کرد! هر وقت در برابر انتقادات فنی که از مطلبت شد، جواب فنی داشتی، بیا اینجا مطرح کن. ادعا و تهمت و اراجیفی مثل "شما خودتان را سرور و سالار همه میدانید" در یک محیط علمی و فنی ارزشی ندارند.

[tdkhakpur]

البته در پست قبلی برای شما توضیح داده شد که شما یا از TNT Components استفاده کردید، یا نهایتا یک مجموعه کامپوننت مشابه آن نوشتید که نقاط ضعف آن در پست قبلی توضیح داده شد، و جوابی هم از شما داده نشد. در پست اول تاپیک هم فقط خصوصیت Caption را تعریف کردید، و از پیاده سازی متدهای GetCaption و SetCaption در اون کد طفره رفتید

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

[vcldeveloper]

یک چیز دیگر اینکه بهترین برنامه نویس این نیست که زیاد از تئوری کار و یا این از کارهای آماده شده دیگران استفاده نکند و خودش از نو کد نویسی کند بلکه کسی هست که از برنامه های اماده و تست شده دیگران به نحو احسنت استفاده کند.
وقتی با مفاهیم چیزهایی که باهاش سر و کار داری آشنا نباشی، و تصور کنی که تعریف یک Proeprty در یک کلاس، و سپس ادعاهای مضحک کردن درباره آن برات کار عملی محسوب میشه؛ و همچنان نمیدونی که ابزاری که داری باهاش کار میکنی از چه اجزائی تشکیل شده و چطور کار میکنه، نتیجه اش میشه همین که ادعای به ظاهر فنی بکنی که بعدا خودت درش بمونی، مثل چند نمونه اخیرت؛ از ادعای اجرا نشدن پروسه های 32 بیتی در ویندوزهای 64 بیتی گرفته، تا نوشتن کد تغییر عناصر رابط کاربر در یک Worker thread، و حالا ادعای راه حل آسان سازگاری با یونیکد ات!


من الزاما کدها و راه پیشنهادی را برای اینکه بیان میکردید دلفی مثلا 7 نمیتواند از یونیکد پشتیبانی کند ارسال کردم
بله، راهی رو پیشنهاد کردی، و مشکلات و اشتباهات فنی پیاده سازی مورد نظرت هم بهت گفته شد. البته اگر سعی می کردی به شکل علمی و فنی از پیشنهادت دفاع کنی، و هر جا که متوجه شدی اشتباه کردی، بپذیری، بحثی نبود؛ اما متاسفانه به جای اینکه به اشتباهاتت بیشتر فکر کنی، سعی کردی با بیان ادعاهای واهی و مطالب بی ربط از پذیرش اشتباه فنی ات شانه خالی کنی.

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