Я начинающий программер C# и хотел бы получить ответ на такой вопрос: насколько целесообразно углубленно изучать WinApi для программирования на C#?
У меня есть небольшой опыт использования WinApi-функций с помощью аттрибута dllimport. Главная проблема, на мой взгляд, — это отсутствие указателей в C#, а ведь большинство WinApi-функций используют указатели в качестве параметров. Проблемой, к примеру, был вызов CreateProcess, которой нужно примерно 10 параметров (просто не знал, что в .NET есть аналогичная функция Process.Start(), — с ней работать гораздо проще).
Может быть, все-таки можно обойтись в подавляющем большинстве случаев библиотеками базовых классов .NET? Извиняюсь за ламерские вопросы.
Здравствуйте, pus, Вы писали:
pus>Я начинающий программер C# и хотел бы получить ответ на такой вопрос: насколько целесообразно углубленно изучать WinApi для программирования на C#?
в идеале абсолютно нецелесообразно
pus>У меня есть небольшой опыт использования WinApi-функций с помощью аттрибута dllimport. Главная проблема, на мой взгляд, — это отсутствие указателей в C#, а ведь большинство WinApi-функций используют указатели в качестве параметров. Проблемой, к примеру, был вызов CreateProcess, которой нужно примерно 10 параметров (просто не знал, что в .NET есть аналогичная функция Process.Start(), — с ней работать гораздо проще). pus>Может быть, все-таки можно обойтись в подавляющем большинстве случаев библиотеками базовых классов .NET? Извиняюсь за ламерские вопросы.
указатели в с# есть, а вот на счет остального ты прав, лучше пользоваться библиотекой базовых классов ...
Здравствуйте, pus, Вы писали:
pus>Я начинающий программер C# и хотел бы получить ответ на такой вопрос: насколько целесообразно углубленно изучать WinApi для программирования на C#? pus>У меня есть небольшой опыт использования WinApi-функций с помощью аттрибута dllimport. Главная проблема, на мой взгляд, — это отсутствие указателей в C#, а ведь большинство WinApi-функций используют указатели в качестве параметров. Проблемой, к примеру, был вызов CreateProcess, которой нужно примерно 10 параметров (просто не знал, что в .NET есть аналогичная функция Process.Start(), — с ней работать гораздо проще). pus>Может быть, все-таки можно обойтись в подавляющем большинстве случаев библиотеками базовых классов .NET?
Лучше направь свои силы на изучение классов, неймспейсов NET. WinAPI редко когда требуется, в 99% можно без них обойтись. А когда уж понадобится тогда и прочитаешь пару конкретных страниц в МСДН.
GIV>Лучше направь свои силы на изучение классов, неймспейсов NET. WinAPI редко когда требуется, в 99% можно без них обойтись. А когда уж понадобится тогда и прочитаешь пару конкретных страниц в МСДН.
А уж когда понадобится, глядишь и Windows Longhorn выйдет, можно будет окончательно забить
Благодарю всех откликнувшихся — Вы оправдали мои надежды. Вот только вопросик: а что за указатели есть в C# (в MSDN я сам найду, подскажите ключевые слова)?
Здравствуйте, pus, Вы писали:
pus>Благодарю всех откликнувшихся — Вы оправдали мои надежды. Вот только вопросик: а что за указатели есть в C# (в MSDN я сам найду, подскажите ключевые слова)?
Здравствуйте, mihailik, Вы писали:
M>А уж когда понадобится, глядишь и Windows Longhorn выйдет, можно будет окончательно забить
Думаю еще лет 10 забыть нельзя будет. Лонгхорн все равно будет в основании АПИ-шные вещи иметь. То что его не будут развивать еще не значит, что его не будет вообще.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
M>>А уж когда понадобится, глядишь и Windows Longhorn выйдет, можно будет окончательно забить
VD>Думаю еще лет 10 забыть нельзя будет.
Эхо войны
Вообще-то я говорил "забить", а не "забыть".
VD>Лонгхорн все равно будет в основании АПИ-шные вещи иметь. То что его не будут развивать еще не значит, что его не будет вообще.
Я надеюсь, WinAPI будет затухать в своей узкой нише, а начинающие программисты смогут его благополучно игнорировать. Примерно как сейчас субклассирование окон или расширенные функции вывода на консоль.
Здравствуйте, pus, Вы писали:
pus>Благодарю всех откликнувшихся — Вы оправдали мои надежды. Вот только вопросик: а что за указатели есть в C# (в MSDN я сам найду, подскажите ключевые слова)?
pus>Благодарю всех откликнувшихся — Вы оправдали мои надежды. Вот только вопросик: а что за указатели есть в C# (в MSDN я сам найду, подскажите ключевые слова)?
Указатели есть в режиме unsafe (это ключевое слово).
Использовать указатели можно не очень свободно. Во-первых, часто приходится "пиновать" или "фиксировать" указатели, чтобы очистка Garbage Collect не передвинула их. Во вторых, всё чисто только когда работаешь со структурами, а с объектами начинаются оговорки.
Ещё есть IntPtr, которые помянул Sergino1. Они, вообще говоря, совсем не имеют свойств указателей. Просто тип данных, в котором может быть записано численное значение указателя. Так сказать, указатели, одетые в наручники. Но методы класса Marshal позволяют по по этим "арестованным" указателям получать разные значения: все виды строк, массивы, целые числа разной длины и пр. IntPtr в сочетании с классом Marshal можно использовать и не в режиме unsafe.
Таким образом, рекомендованные темы: unsafe, fixed, System.Runtime.InteropServices.Marshal
Можешь также поискать насчёт "verifiable" сборок. Это подробности, что стоит за словом unsafe. А если уж совсем разберёт жажда знаний, смотри System.Reflection.Pointer и System.TypedReference. Хотя это уже некоторый изврат.
Здравствуйте, mihailik, Вы писали:
M>Я надеюсь, WinAPI будет затухать в своей узкой нише, а начинающие программисты смогут его благополучно игнорировать. Примерно как сейчас субклассирование окон или расширенные функции вывода на консоль.
Авалоновское окно — это обычное Win32-окно. И оно даже позволяет хостить Win32-контролы. Вот родные авалоновские конролы те уже рисуются сами, но опять же вся их отрисовка попадает в общее авалоновское окно. Т.е. реально все топлевел-окна обычные Win32. И вряд ли к релизу это исправится.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Авалоновское окно — это обычное Win32-окно. И оно даже позволяет хостить Win32-контролы. Вот родные авалоновские конролы те уже рисуются сами, но опять же вся их отрисовка попадает в общее авалоновское окно. Т.е. реально все топлевел-окна обычные Win32.
Здравствуйте, AndrewVK, Вы писали:
AVK>Будет. В Аэро. Которого пока нет.
Не. Уже. Просто они его хотят на D3D посадить. А пока он через GDI скорее всего работает. Но шустро.
AVK>Ну и в свинге тоже самое — все примитивы рисует не свинг, а AWT, который по большей части на JNI написан.
Здается мне что ты ошибаешся. Я вроде бы встречал инфрормацию, что AWT Свингу ненужна. Да и судя по дичайшим тормозам они все рисуют в память.
VD>>Ну, и качество значительно выше.
AVK>Качество чего?
Результата. Свинговый интерфейс всегда выдает кривота. Все почти как настоящее пока мышку не двинул.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Ну и в свинге тоже самое — все примитивы рисует не свинг, а AWT, который по большей части на JNI написан.
VD>Здается мне что ты ошибаешся. Я вроде бы встречал инфрормацию, что AWT Свингу ненужна.
Агашазблин.
VD>Да и судя по дичайшим тормозам они все рисуют в память.
M>>Я надеюсь, WinAPI будет затухать в своей узкой нише, а начинающие программисты смогут его благополучно игнорировать. Примерно как сейчас субклассирование окон или расширенные функции вывода на консоль.
VD>Авалоновское окно — это обычное Win32-окно. И оно даже позволяет хостить Win32-контролы. Вот родные авалоновские конролы те уже рисуются сами, но опять же вся их отрисовка попадает в общее авалоновское окно. Т.е. реально все топлевел-окна обычные Win32. И вряд ли к релизу это исправится.
Интерестные данные
А если форме указать BackBrush, или как там оно называется, с нерегулярной полупрозрачностью. К примеру, текстурка с полупрозрачными "дырами". Потянет оно с виндовыми контролами такой изврат?
Сейчас вот в Win2K/XP я не видал ни разу нерегулярной полупрозрачности. Разве что в тенях хинтов и менюшек края более прозрачные, чем середина. Но как такое в своих окнах реализовать — не знаю.
