بله چون در رندر شون همچین موردی در نظر گرفته نشده.
از OpenGL و DirectX و هر موتور سه بعدی دیگری که سراغ دارید. WPF قابلیت سه بعدی قدرتمندی نداره اما برای استفاده از قابلیت های سه بعدی محدودش هم خودش که مستقیم در WinForms استفاده نمیشه، خروجی WPF تون رو بصورت کنترل ای در WinForms نمایش می دهید. فکر کنم قبلا هم در مورد WindowsFormsIntegration و ElementHost صحبت کردیم که یک کنترل WPF رو داخل WinForms نمایش بده.
سوالی نیست که مربوط به این تاپیک باشه.
ممنون استاد علی
Microsoft.OneGet.Utility.Platform.ShellLink shellLink = new Microsoft.OneGet.Utility.Platform.ShellLink(@"E:\Project\Visual Studio\C#.Net\Saved Project\0 WPF Practice\WPF Practice\bin\Debug\WPF Practice.exe");
shellLink.TargetPath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop);مشکل از اینجا است که شما مسیر یک فایل اجرایی رو دادید به ShellLink و گفتید این یک لینک (فایل lnk) ئه و فراخوانیش کن. خوب معلومه نمیتونه.
حدسی که نباید برای خودتون کار متد رو تفسیر کنین، از روی چه مستنداتی اینطوری متوجه شدید که filename مسیر فایلی است که میخواهید برایش میانبر بسازید؟ اصلا این متد سازنده که اجرا می کنید برای ساختن میانبر ئه؟ مسیر فایل میانبر ئه. در ضمن همون Microsoft.OneGet.Utility.Platform.ShellLink مگه متد static ئه CreateShortcut نداره؟
workingdirectory مسیری است که موقع شروع اجرا به عنوان مسیر فعلی بکار میره. یعنی ()System.IO.Directory.GetCurrentDirectory . وقتی در Command Prompt در یک مسیر فولدری قرار دارید و از اونجا برنامه ای در مسیر دیگری رو اجرا می کنید workingdirectory مسیری است که در اون قرار دارید، نه مسیری که فایل اجرایی در اون قرار داره.آها اشتباه کردم
پسوند فایل های میانبر که lnk هستن ، این کلمه مخفف link هه . بنابراین جایی که گفتش linkFileName یعنی مسیر فایل میانبر با پسوند lnk رو که میخوایم ایجاد کنیم رو بهش بدیم (مثلا در دسکتاپ و ...) و آرگومان دوم که targetFileName هست را باید مسیر فایلی که قصد میانبر ساختن ازش رو داریم بدیم (مثلا فایل exe و ...) .
description هم توضیح برای زمان tooltip هست
workingdirectory و argument رو نمیدونم برای چیه
مستنداتش اون نیست البته. مستنداتش اون MSBuild Extension Pack Help.chm ای است که در فولدر کنار MSBuild.ExtensionPack.dll قرار داره.
شما از Wrapper استفاده می کنید ولی نه با کد #C اش کاری دارید و نه لازمه کد #C اش رو داشته باشید. اینکه کتابخانه یا کلاسی هم بصورت گسترده از API استفاده کنه برای اینکه Wrapper محسوب بشه کافی نیست، Wrapper همیشه یک نمونه میخواد که برای اون Wrapper باشه و تا حد امکان ساختار و تعاریف نمونه اصلی رو حفظ می کنه، نه قابلیت خاصی بهش اضافه می کنه و نه بجز موارد ضروری تغییراتی میده. اغلب توابع API ساختارشون ساخت یافته است و بر پایه کد زبان C ئه که اصلا شیء گرایی نداره و کلاس نداشتند که حالا براشون Wrapper ای ایجاد بشه. وقتی یک مجموعه از متد های مرتبط تحت عنوان یک کلاس در NET. وجود داره به ندرت نمونه Unmanaged ای داشته که برای اون Wrapper ای باشه، یک ساختار جدید ئه، کاملا متکی به API هم باشه باز هم Wrapper محسوب نمیشه.
E:\Project\Visual Studio\C#.Net/Saved Project/Windows Update Disabler/Windows Update Disabler/bin/Debug/Windows Update Disabler.exeکلا رجیستر شدن مختص کتابخانه های COM ئه، همون ActiveX ها که Interop دارند، DLL های Native که ActiveX نیستند یا DLL هایی که NET. میسازه مثل COM نیستند که GUID و مشخصاتشون ثبت بشه، چیزی برای رجیستر شدن در بخش COM ندارند. مشخصات اسمبلی های NET. میتونه در GAC ثبت بشه ولی جهت استفاده اشتراکی و مدیریت نسخه، نه الزاما برای اینکه بتونه اجرا بشه.
هیچ تضمینی نیست که خروجی اتوپلی با یک کلیک اجرا بشه و بخاطر رجیستر نبودن یک موردی کرش نکنه. برنامه تحت NET. ای هم ممکنه داخلش انواع کتابخانه ها بکار برده باشه که نیاز به نصب شدن داشته باشند یا نداشته باشند. قبلا هم در این مورد صبحت کردید و پاسخ مفصل دادم. بهتره بجای گفتگوی دوباره مطالب قبلی رو مرور کنید.
ویروس کامپیوتری یک تعریف و قابلیت مشخصی داره، ویروس ذاتا قابلیت آلوده کردن سایر فایل ها رو داره، بنا بر این برای آلوده کردن یک فایل اجرایی یا بقول شما ادغام شدنش نیازی به یک نرم افزار Setup ساز نداره.
شما مشکلات و محدودیت های اتوپلی رو نمی توانید بدون پلاگین نویسی دور بزنید، اتوپلی به هیچ وجه بدون استفاده از پلاگین هاش نمی تونه با یک شیء خارجی ارتباط برقرار کنه، شما با یک جستجوی ساده می توانید هزاران کنترل ActiveX در اینترنت یا مواردی در کامپیوتر خودتون پیدا کنید که حتی در ویژوال بیسیک 6 هم قابل استفاده باشند، ولی اتوپلی بدون پلاگین مناسب و خاص اون کنترل نمی تونه ازش استفاده کنه. این که ربطی به Managed و Unmanaged و #C و ActiveX و COM نداره، محدودیت خود اتوپلی ئه. محیط برنامه نویسی که نیست، باید در حد توانایی های خودش انتظار داشته باشید. بحث محدودیت های اتوپلی رو بیخودی قاطی #C نکنید، شما پلاگینی نساختید که هم حالا سر ارتباطش با #C راهنمایی بخواهید. ارتباط بین اتوپلی و یک کنترل ActiveX مثل کنترل Windows Media Player یک ارتباط مستقیم که نیست، با پلاگین خودش ارتباط برقرار می کنه. بدون اون پلاگین که با ActiveX ارتباطی نداره.
خیلی از الگوریتم ها کاربرد های محدودی دارن در یکسری موضوعات خاص و تعدادشون هم خیلی زیاده. برای همین هر چقدر با الگوریتم های بیشتری آشنا بشید، به توانایی تون در کد نویسی کمک می کنه، اما صرفا در موضوعات خاصی که اون الگوریتم ها کاربرد دارند. اگه نمیدونید میخواهید برای چه موضوعی کد نویسی کنید لزومی نداره برای یادگیری الگوریتم هایی وقت بذارید که شاید یکروز بدرد بخورند یا شاید نخورند. با اینجور کتابها مثل مرجع رفتار کنید، حفظ شون نکنید، وقت برای مطالعه شون صرف نکنید، لازم نیست الگوریتم هایی که الان در این لحظه لازم ندارید رو حفظ کنید یا مرور کنید، هر وقت به الگوریتمی نیاز داشتید به اینجور کتاب ها مراجعه می کنید و اون یک الگوریتم خاص که مناسبه رو از داخلش برمیدارید، همین.
