Comments 94
А я вот думаю, статью по HiDPI на WINAPI дописать, да всё думаю что никому не надо может.
WinAPI — своеобразный низкий уровень для написания приложений под Windows. Все, даже кроссплатформенное, даже Qt в своей основе (именно для Windows) упирается именно в WinAPI. Поэтому, знать его, я считаю, необходимо хоть в какой-то степени. И статьи по нему также полезны и интересны.
Хотел сначала Вас раскритиковать, мол негоже в 2018 году опираться на апи не самой лучшей ос, зачем так усложнять и т.п. Потом подумал и решил, что Вы правы, учитывая, да
где-то внутри него сидят эти самые мерзкие вызовы. Подобное полезно для понимания процессов, реверс-инженеринга, и вообще для общего развития.
Сам помню, как познакомился с Delphi и офигевал что простая програмулька после сборки веси 300-400 кб. В том же делфи писал с применением WinAPI (из *.dpr, с функцией WinMain определенной в прототипах хе-хе) и получал уже 10-15 кб.
Полезно. Но не для практической разработки, а для повышения грамотности и понимания количества и состава внутренних шестерен приложения для вин.
Плюс
даже Qt в своей основе (именно для Windows)
где-то внутри него сидят эти самые мерзкие вызовы. Подобное полезно для понимания процессов, реверс-инженеринга, и вообще для общего развития.
Сам помню, как познакомился с Delphi и офигевал что простая програмулька после сборки веси 300-400 кб. В том же делфи писал с применением WinAPI (из *.dpr, с функцией WinMain определенной в прототипах хе-хе) и получал уже 10-15 кб.
Полезно. Но не для практической разработки, а для повышения грамотности и понимания количества и состава внутренних шестерен приложения для вин.
Плюс
Даже в 2018 негоже использовать многомегабайтный Qt или аналоги если тебе надо вывести диалог с десятком кнопок. Голый апи имеет свою нишу.
Голый апи имеет свою нишу
имеет очень узкую нишу, ограниченную одной единственной ОС, занимающей мизерную долю в общей массе устройств
Среди десктопов — да. Но среди всех устройств — уже нет, т.к. десктопов в сравнении с мобилками не очень много нынче. В итоге с формальной точки зрения придраться к формулировке maisvendoo сложно. Вот так вот и манипулируют рекламщики да политики.
Но среди всех устройств — уже нет, т.к. десктопов в сравнении с мобилками не очень много нынче.Не так давно равенство было. Сейчас ещё разница меньше, чем вдвое. Всё-таки когда говорят о «мизерной доле», то речь не идёт обычно о 40%.
Опять же… манипулировать статистикой очень просто. В приведенной сслыке идёт про использование web-а, а не про количество устройств. Я вот и сам всё ещё хабр с десктопа по старинке читаю, хотя телефонов и планшетов у меня на порядок больше, чем десктопов.
телефонов и планшетов у меня на порядок больше, чем десктопов.Зачем вам 10 телефонов и планшетов???
Для разных целей, включая тестирование. Я то, конечно, не типичный пользователь, но вполне очевидно, что сейчас телефон есть почти у каждого, включая бабушек и детей, что не скажешь про десктоп. А если брать развивающиеся страны, то там даже программируют на телефонах: https://habrahabr.ru/company/everydaytools/blog/345232/
А ещё в современном мире тот же Android пихают везде от принтеров и часов до унитазов и автомобилей. Так что мир "устройств" очень большой.
Хоть с формальной, хоть с неформальной. Массовый потребитель теряет интерес к десктопу, и чем дальше, тем больше будет терять. А там, извините, правит бал уже не винда
Эмм, а что, Андроид АПИ принципиально лучше, чем ВинАПИ?
Да. Уже хотя бы тем, что там у каждого приложения своя песочница. UWP, конечно, ничем не хуже, только вот беда: все те сотни тысяч (миллионы?) приложений для Windows, из-за которых ей продолжают пользоваться — ни разу не UWP…
Эмм, а что, Андроид АПИ принципиально лучше, чем ВинАПИ?
Вы свой вопрос поняли вообще сами?
15 мегабайт — мизерная цена за возможность просто взять и реализовать свою функциональность вместо многочасового ковыряния в библиотечной ерунде или в скелете приложения.
а потом в результате такого мышления получаем скайп в 300 мб, и мессенджеры по 133 мб (WhatsApp), лишь бы только не ковыряться (ключевое слово никогда)
Ну так вы С++ с Qt не путайте с другими решениями (Delphi, Java и прочее).
Посмотрел, две базовые библиотеки Qt для окошек на моих никсах весят 4.5Мб (QtCore) и 6.5 (QtWidgets). Этого достаточно, чтобы быстро, надежно и без геморроя написать приложение с окошками.
Потом, Qt — не шаблонная библиотека, она не раздувает код. А также не тащит с собой виртуальные машины, райтаймы и т.д. Вот прям сейчас под рукой простенькое приложение на 10 окошек с сетью и БД занимает 300кБ в релизе. Размер смешной, чтобы его считать хоть сколько-то значимым.
Посмотрел, две базовые библиотеки Qt для окошек на моих никсах весят 4.5Мб (QtCore) и 6.5 (QtWidgets). Этого достаточно, чтобы быстро, надежно и без геморроя написать приложение с окошками.
Потом, Qt — не шаблонная библиотека, она не раздувает код. А также не тащит с собой виртуальные машины, райтаймы и т.д. Вот прям сейчас под рукой простенькое приложение на 10 окошек с сетью и БД занимает 300кБ в релизе. Размер смешной, чтобы его считать хоть сколько-то значимым.
две базовые библиотеки Qt...
Этого недостаточно. Посмотри (и проверь на чистой системе) размер полного деплоя, особенно для Qt5.
А шаблоны несущественно раздувают код.
В целом, Кьют сравнимо с дНЕТ и вполне терпимо на сегодняшний день.
Кстати, Дельфи/БСБ дают меньший оверхед для голой ВЦЛ
Этого недостаточно. Посмотри (и проверь на чистой системе) размер полного деплоя, особенно для Qt5.
Я последний раз что-то на Винде разворачивал еще во времена активной жизни Qt4, и не припомню, чтобы размеры как-то впечатляли. Если открыть официальный мануал, то речь идет о 15-20мб (или +27, если с ICU) для mingw. Если msvc собрать, меньше будет.
Если мы говорим о никсах, то все нужные либки Qt, как правило, есть в системе, поэтому о размере вообще думать не приходится.
А шаблоны несущественно раздувают код.
Еще как раздувают. Какая-нибудь жирная либа на шаблонах типа CGAL сделает прогу уровня хеллоуворлд в несколько мегабайт на старте.
В целом, Кьют сравнимо с дНЕТ и вполне терпимо на сегодняшний день.
Ну, если мы деплоим на винду, то там, как правило, весь рантайм и либы (для минимального приложения) лежат в системе, поэтому бинарники весят очень мало. Зато на никсы деплоить дотнет — тот еще геморрой.
Вот тут поподробнее дерево разрисовано. С введением QtQuick2 и своего GL-рендерера в Qt5 размер деплоя стал гораздо больше.
Приходилось работать с одной специфичной программой одного вендора (который и на Хабре что-то пописывает в свой корпоративный блог)… Программа выпускается только под Windows, о том, чтобы портировать её на другие ОС, я не слышал. Задачи, которая должна решать программа:
GUI используется только для «моргания иконкой» (сигнализация о процессе работы программы) в SystemTray и для задания настроек (окно с полями, где указываются хост-источник, хост-приемник, периодичность опроса источника, кнопки «OK» и «Cancel»)…
Размер каталога установленной программы составляет в районе 40 Мб. Я до сих пор не могу понять: зачем для такой программы нужно было использовать Qt (вендор её сделал полностью на Qt)?
Стабильностью работы программа не отличается (о чем иногда здесь пишут хабрапользователи в соответствующих тредах), жалобы/багрепорты отправляются вендоромв /dev/null на первую линию обороны техподдержки, которая никогда не называет сроков выпуска исправлений (не говорят даже магическое «Ошибка будет исправлена в ближайшем релизе/сборке»).
Все это привело к тому, что клиентам мы теперь ставим свое решение, написанное на WinAPI+COM, вместо этого «чудовища». Размер каталога установленного нашего решения составляет в районе 2 Мб, максимальное потребление памяти в районе 25 Мб (программа вендора может запросто отожрать 70 Мб, да еще и ядра процессора нагрузить до 70% и перестать реагировать на пользователя).
- Периодически обращаться к некоторому хосту в сети (где развернут веб-сервер) и скачивать оттуда некий XML-файл (до 10 Мб)
- Сконвертировать (обработать) этот XML в специфический формат
- Результат обработки залить на другой хост сети
GUI используется только для «моргания иконкой» (сигнализация о процессе работы программы) в SystemTray и для задания настроек (окно с полями, где указываются хост-источник, хост-приемник, периодичность опроса источника, кнопки «OK» и «Cancel»)…
Размер каталога установленной программы составляет в районе 40 Мб. Я до сих пор не могу понять: зачем для такой программы нужно было использовать Qt (вендор её сделал полностью на Qt)?
Стабильностью работы программа не отличается (о чем иногда здесь пишут хабрапользователи в соответствующих тредах), жалобы/багрепорты отправляются вендором
Все это привело к тому, что клиентам мы теперь ставим свое решение, написанное на WinAPI+COM, вместо этого «чудовища». Размер каталога установленного нашего решения составляет в районе 2 Мб, максимальное потребление памяти в районе 25 Мб (программа вендора может запросто отожрать 70 Мб, да еще и ядра процессора нагрузить до 70% и перестать реагировать на пользователя).
Чтобы «просто взять и реализовать» обычно достаточно разок почитать основы и далее при необходимости подсматривать в хелпы. ВынАпи достаточно последователен и работать с чем-то новым там не сложно. Да и для обычных задач быстро делаются шаблоны и дальше используются готовые куски. А для простых задач вообще можно слепить за пару минут диалоговое окошко любой сложности в конструкторе и юзать его. Это уже не говоря о том, что машинах слабее топовых разница в скорости работы того же Qt и голого апи заметна невооруженным глазом. Про чуть более старые машины вообще молчу.
А вот если вам нужно запилить мс-ворд с его сотней видов окошек, панелек и т.д. — то да, придётся тащить фреймворк.
А вот если вам нужно запилить мс-ворд с его сотней видов окошек, панелек и т.д. — то да, придётся тащить фреймворк.
для простых задач вообще можно слепить за пару минут диалоговое окошко любой сложностиОй ли любой? А как там с layout, по-прежнему любые динамические изменения размеров нужно реализовывать руками в WM_SIZE? Думаю, что да. И это, скорее всего, правильно. Но этот уровень программирования слишком низкий для написания приложений. Это уровень написания библиотеки для написания приложений.
Ваши мысли полностью аналогичны утверждению: «Программировать нужно на ассемблере.» Нет, я не могу с этим согласиться.
А как же WM_SIZING?
В свое время написал именно такую библиотеку, где кроме своей layout системы много еще разных (нужных мне) вещей, и которую периодически дополняю по мелочам. Сделал свой шаблон с ней для VS и создаю вполне себе приложения на чистом WinAPI за пару минут. Не спрашивайте зачем мне это. Просто почесать свое эго. :-)
В свое время написал именно такую библиотеку, где кроме своей layout системы много еще разных (нужных мне) вещей, и которую периодически дополняю по мелочам. Сделал свой шаблон с ней для VS и создаю вполне себе приложения на чистом WinAPI за пару минут. Не спрашивайте зачем мне это. Просто почесать свое эго. :-)
Делаете окно, в парент диалогу цепляете его и получаете обычное окно с с фиксированным фрагментом с контролами. Ну и ничего не мешает один раз сделать обработку размера и цеплять его шаблоном если уж так надо. Но первый вариант проще.
В свое время была проблема достать стоящую литературу по разработке на WinAPI, все что не было описано в книги, искали через файлы заголовков самого WinAPI. Вполне все было понятно.
Статическая линковка плюс правильные настройки компилятора/линкера — и размер будет на порядок меньше (в исполняемый файл будет включено только то, что реально используется).
> В том же делфи писал с применением WinAPI (из *.dpr, с функцией WinMain определенной в прототипах хе-хе) и получал уже 10-15 кб.
Для делфи еще была библиотека KOL, которая, сохраняя визуальный конструктор, уменьшала размер файла раз в 5-10.
Для делфи еще была библиотека KOL, которая, сохраняя визуальный конструктор, уменьшала размер файла раз в 5-10.
Особняком стоит WPF, который не использует WinAPI для отрисовки.
Да-да, больше систем независимых и разных. А потом поменял настройки вынды и у тебя в лучшем случае пачка разномастных окошек образовалась. А в худшем вообще треш и угар. Половину программ можно поломать (гуй имеется ввиду) просто изменив масштаб шрифта. Любая нестандартная отрисовка окон рано или поздно ломается. Проверено.
Сейчас уже не всё так плохо. За счёт того, что приложения используют фреймворки, а не голый API, проблем с масштабированием стало значительно меньше.
Проблем сейчас меньше не по этому, а потому, что за прошедшие годы все фреймворки по ним успели уже походить. Ну и речь даже не совсем об этом, а больше о том, что если надо делать не «весёленько» а нормальный рабочий интерфейс, то лучше использовать либо апи, либо фреймворк на родном апи. А то сейчас прямо как назад в 90е, когда в win95 все начали городить кастомные интерфейсы. В итоге нет 2х похожих программ. Причём если настройки родного интерфейса я хотя бы могу поменять, то неродные… Вот сейчас на работе: оракловый манагер — какая-то хрень на яве (дико тормозная, но речь не об этом) — это один. Ворд и прочие офисы со своими плоскими панельками — это второй. За однотонные окна без рамок автора хочется от… ть отдельно. иногда понять где заканчивается одно окно и начинается другое просто невозможно. Порой приходится сначала подвигать окно за заголовок, чтобы понять, где у него границы… И что это был не его заголовок, т.к. цветом он тоже не выделяется. VC — у него тоже своя атмосфера. Ну и родной интерфейс — это четыре. И этот салат реально бесит как по причине внешнего вида, так и по причине невозможности его исправить или необходимости настраивать отдельно в каждой программе (да и то что в них можно настроить кроме выбора темы?)
А, чуть не забыл. Есть ещё и наша софтина с отдельно у… дивительным интерфейсом (тоже какой-то фреймворк). Но это другая история.
А, чуть не забыл. Есть ещё и наша софтина с отдельно у… дивительным интерфейсом (тоже какой-то фреймворк). Но это другая история.
Только для отрисовки клиентской области, сами окна на WinAPI.
А вы уверены что Qt использует WinAPI для отрисовки кнопок?
Найти HWND кнопок и других элементов в приложениях Qt под Windows не получится.
Найти HWND кнопок и других элементов в приложениях Qt под Windows не получится.
Пишите, статей на эту тему крайне мало и подробные референсы на русском языке не помешали бы
Надо!!!
Мучительно ковыряю в данный момент эту тему, и понимаю что я многое упустил…
Пишите пожалуйста!
Мучительно ковыряю в данный момент эту тему, и понимаю что я многое упустил…
Пишите пожалуйста!
С интересом прочту про Per-Monitor DPI-Aware.
Примерно похожий минимальный каркас приложения создается в Dev-Cpp.
Когда то информация по winapi казалась чем-то очень новым, а теперь она подается как что-то очень старое, типа забытые знания древних цивилизаций:)
Вот только кто об этом знает и этим пользуется?
В это суровое время уже не модно читать MSDN? O tempora....
А есть ли смысл в наше время в данной статье? Зачем сейчас вообще тратить время на разработку на голом WinAPI? Лет 15 назад уже особо не видел чистого WinAPI, MFC использовали.
На собеседованиях я всегда показывал свою программу на апи. Часто она вызывает интерес и смею предположить поднимает уровень в глазах собеседников.
Это как минимум.
Как максимум — кто знает с чем придется иметь дело завтра.
Это как минимум.
Как максимум — кто знает с чем придется иметь дело завтра.
Вчегда считал, что важен конечный результат, а не используемый инструмент. Я показывал к примеру свой CGridCtrl для MFC, с попиксельным скроллом, in-place редактированием (и возможностью без проблем добавлять свои редакторы) и объединением ячеек. И на мой взгляд это важнее для среднестатистического работодателя. Изучать же полёт фантазии на собеседовании особого времени нет, да и особо никто не будет даже не в рамках собеседования это делать.
WinAPI — это как ассемблер. Пользоваться не обязательно, но знать совсем не повредит.
MFC ужасен. Тот же winAPI, только с еще большей кучей грязи и не самого лучшего стиля программирования. Уж если упрощать взаимодействие с GUI для разработчиков, то путём полнейшей инкапсуляции всяких HWND и прочей ереси.
Угу, VCL в Delphi/Builder был прекрасен. Я пытался перейти на MSVC, но от MFC меня просто тошнило. В итоге так и продолжал сидеть на Delphi/Builder, пока не вышел .NET с Windows Forms.
MFC ужасен. Тот же winAPI, только с еще большей кучей грязи и не самого лучшего стиля программирования. Уж если упрощать взаимодействие с GUI для разработчиков, то путём полнейшей инкапсуляции всяких HWND и прочей ереси.Так MFC на 90% и есть ВинАПИ с полнейшей инкапсуляцией всяких ХВНД и диспатчеров =)
Вы не совсем верно поняли мой комментарий. Про то, что это обёртка winAPI я итак в курсе… MFC был сделан давным давно, с использованием далеко не самых лучших практик. WinAPI там так и лезет на ружу. Хоть этот MFC и призван упростить разработку GUI приложений под Win, но он всё-равно придерживается концепций, принятых в голом winAPI, и эти все передачи всяких кодов, определенных константами целочисленного типа… Помимо этого — это уже морально устаревший код (какой-то СИ с классами, а не С++11/14/17). Да, там есть множество фич, по типу сплиттеров и Docked-окон. Но выполнено это всё в ужасной, по сегодняшним меркам, манере.
А я и не хвалю его, да, он ужасен. Но он позволял сэкономить очень много времени. WTL мы так и не дождались в те времена.
MFC действительно не отличаются качественным кодом или показательным стилем программирования, но они существенно упрощают создание программ на вин-апи. На предыдущей работе был большой виндовый проект, написанный с использованием MFC, занимался его разработкой с нуля около 7 лет. Никаких глюков или нестабильной работы за ним замечено не было, наоборот, система работала очень стабильно и при этом быстро. Однажды нас даже спросили «а почему она у вас так быстро работает?». При этом, систему можно запускать на компьютерах с частотой процессора ниже 1 ГГц и не замечать серьезного замедления (конечно, если работать с умеренным для такого компьютера объемом информации).
Да, создание интерфейса пользователя на MFC всегда требует дополнительной работы, если сравнивать с более современными технологиями. Но на начальном этапе пишутся требуемые классы (например, класс диалога, позволяющий перемещать/растягивать элементы при изменении размера диалога) или даже свои «контролы», и дальнейшая работа уже идет быстрее. При этом ты всегда знаешь, что если какого-то функционала нет, ты можешь напрямую использовать WinAPI. Да и исходники MFC доступны, можно зайти в них отладчиком, если нужно посмотреть, что и как там работает.
В итоге, при создании диалогов больше всего раздражало даже не то, что надо все писать руками, а их ужасный редактор в студии (под конец была 2012) — например, чтобы поменять порядок контролов (для правильной навигации клавишей Таб) было проще отредактировать файл ресурсов в фаре, чем жать Ctrl-D и по очереди тыкать в них мышкой. Также факт того, что все координаты и размеры в диалогах измеряются в DLU, не равных пикселям на «стандартном» разрешении в 96 DPI тоже сильно огорчает, делая редактирование диалогов в студии далеко не самой приятной задачей.
Да, создание интерфейса пользователя на MFC всегда требует дополнительной работы, если сравнивать с более современными технологиями. Но на начальном этапе пишутся требуемые классы (например, класс диалога, позволяющий перемещать/растягивать элементы при изменении размера диалога) или даже свои «контролы», и дальнейшая работа уже идет быстрее. При этом ты всегда знаешь, что если какого-то функционала нет, ты можешь напрямую использовать WinAPI. Да и исходники MFC доступны, можно зайти в них отладчиком, если нужно посмотреть, что и как там работает.
В итоге, при создании диалогов больше всего раздражало даже не то, что надо все писать руками, а их ужасный редактор в студии (под конец была 2012) — например, чтобы поменять порядок контролов (для правильной навигации клавишей Таб) было проще отредактировать файл ресурсов в фаре, чем жать Ctrl-D и по очереди тыкать в них мышкой. Также факт того, что все координаты и размеры в диалогах измеряются в DLU, не равных пикселям на «стандартном» разрешении в 96 DPI тоже сильно огорчает, делая редактирование диалогов в студии далеко не самой приятной задачей.
А сейчас на чём бы посоветовали писать GUI? Желательно ещё с хорошим и современным стилем программирования конкретно на C++11/14/17. Вот вот, кстати, должен выйти C++/winRT (обычный/стандарт С++17 без всяких модификаций, по типу C++/CLI, C++/CX), но это сугубо под Win 8.1 — 10. Короче, библиотека Windows Runtime во всей своей красе и без лишнего оверхэда, станет доступной в чистом С++17. Планируют включить её в VisualStudio 2017 v15.7.
WinRT это и есть оверхед. См например статью тут
Ну так там C++/CX, а тут C++17) Можете почитать здесь. Там же можно в статьях найти сравнение производительности с С++/CX и с C#, посмотреть выступление с конференции CPPCON2017, ну и почитать прочие подробности. Проект еще не вышел в свет. Пока доступен только инсайдерам.
А сейчас я занимаюсь более «системным» программированием — пишу сервисы или консольные утилиты, не использующие GUI. Для них использую «чистый» С++ и STL. Коллеги пишут интерфейсы на QT (т.к. надо и под винду, и под линукс), но не в восторге от него, хотя у нас по определенным причинам далеко не самая последняя версия (5.2). Другие коллеги пишут интерфейсные и веб-приложения на C#.
Поэтому, если речь идет о С++, я ничего не могу порекомендовать. Если бы лично передо мной встала задача написания GUI приложения, «по-старинке» начал бы с MFC, т.к., например, тенденции UI Windows 8/10 мне вообще не нравятся, когда речь идет о десктопном приложении.
Поэтому, если речь идет о С++, я ничего не могу порекомендовать. Если бы лично передо мной встала задача написания GUI приложения, «по-старинке» начал бы с MFC, т.к., например, тенденции UI Windows 8/10 мне вообще не нравятся, когда речь идет о десктопном приложении.
например, тенденции UI Windows 8/10 мне вообще не нравятся, когда речь идет о десктопном приложении.А, кстати, этот феномен кто-нибудь обьективно изучал? Насколько людям вообще современные интерфейсы нравятся?
Когда Windows 95 вышла, то народ был в восторге, и только доли процента говорили «всё переделали, ни черта непонятно» (хотя как раз для них в Windows95 есть ProgMan и можно за 5 минут вернуть старый интерфейс). «На спор» я это сам делал (хотя это было уже во времена XP), но практически я не видел никого, кто бы этим пользовался.
Против Windows XP протестов было уже больше, а возвращать старый интерфейс стали чаще. И чем дальше в лес, тем хуже: возрат старого интерфейса становился всё сложнее, но статей соответствующих публикуется всё больше.
Революция в интерфейсе GNOME была встречена с таким «воодушевлением», что доля Linux'а на десктопе опять упала после перехода на GNOME 3.x (народ начал возвращаться на Windows), был сделан fork, но по настоящему возврат начался только тогда, когда Windows 8 со своими экспериментами сделала невыносимым и существование в Windows тоже.
От новых версий iOS и Android'а тоже люди плюются (пока что недостаточно для того, чтобы разыскивать способы возращать старый дизайн целиком, но есть люди, которые ради блобов рутуют устройства).
Про всякие Skype и MS Office с Ribbon'ом я уже молчу — да, есть фанаты, но есть и люди, которые из-за Ribbon'а пользуются MS Office 2003!
Мир сошёл с ума или я чего-то не понимаю в современных интерфейсах? Зачем менять интерфейс, если это приведёт к тому, что люди будут ваш продукт избегать?
P.S. Разработчики новых интерфейсов, разумеется, проводят исследования, но это не совсем то. Как правило императивом там ставится «как нам заменить интерфейс так, чтобы не все пользователи сбежали». Варианта «выкинуть все изыскания к чёртовой матери и оставить всё как есть» обычно в таких исследованиях непредусмотрено (понятно почему: если так поступить, то уж точно ни бонусов, ни повышений не видать), но это, собственно, делает их почти бесполезными для оценки качества интерфейса (потому что ёжику понятно, что старый, привычный, интерфейс — наиболее реальная альтернатива, и если вы его игнорируете, то говорить о какой-либо обьективности нельзя).
P.P.S. С другой стороны когда в посторонней дискуссии встречается фразы типа есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим, то понимаешь, что у современных новомодных интерфейсов есть не только противники (их-то сразу видно на форумах), но и фанаты, которые обычно просто молчат (они и так уже побеждают, зачем им что-то говорить?), что, собственно, и порождает желание увидеть-таки независимое исследование…
В случае перехода к чему-то новому всегда есть консерватизм, тормозящий этот процесс, поэтому видя новый интерфейс не всегда понятно — действительно ли так плох этот интерфейс или же он просто непривычен.
Win 3.11 я особо не застал, т.к. компьютер появился только в 98-м году, а где до этого удавалось поработать с компьютерами, обычно был дос. Win 95 какого-либо дискомфорта при работе не вызывала, её интерфейс был изучен и казался вполне логичным на тот момент. Переход на Win XP был отложен, но совсем не по причине интерфейса — он как раз казался тогда очень даже красивым, а из-за того, что под Win 9х требовала меньше ресурсов и под нее был опыт написания драйверов vxd на асме, а я тогда как раз что-то писал.
Переход на 7-ку также был отложен до следующего апгрейда компьютера (когда перешел на 4-х ядерный процессор и купил 16 гб памяти). Её интерфейс не был принят так однозначно, однако после настройки «под себя» он оказался вполне удобным.
Переход на семейство 8-10 так и не состоялся по причине действительной убогости нового интерфейса (имхо). МС решили адаптировать десктопную винду для планшетов, чтобы можно было тыкать в нее пальцем — да действительно, если на планшете запустить классический интерфейс, то работать с ним получится с большим трудом, т.к. попасть пальцем в мелкую иконку tree expand действительно трудно. Но зато работать с мышкой в новом интерфейсе просто неудобно. Да и тенденция к сокращению количества цветов мне не по душе — я специально оставил себе офис 2010, т.к. он последний в нормальной цветовой гамме. На работе стоит как раз 2013, каждый раз плююсь при его запуске. Также плавность перемещения курсора в excel на мой взгляд делает работу с ним только хуже (может где можно отключить, не смотрел).
Тем не менее, есть люди, которым новый интерфейс 10-ки кажется очень логичным, красивым и удобным.
Win 3.11 я особо не застал, т.к. компьютер появился только в 98-м году, а где до этого удавалось поработать с компьютерами, обычно был дос. Win 95 какого-либо дискомфорта при работе не вызывала, её интерфейс был изучен и казался вполне логичным на тот момент. Переход на Win XP был отложен, но совсем не по причине интерфейса — он как раз казался тогда очень даже красивым, а из-за того, что под Win 9х требовала меньше ресурсов и под нее был опыт написания драйверов vxd на асме, а я тогда как раз что-то писал.
Переход на 7-ку также был отложен до следующего апгрейда компьютера (когда перешел на 4-х ядерный процессор и купил 16 гб памяти). Её интерфейс не был принят так однозначно, однако после настройки «под себя» он оказался вполне удобным.
Переход на семейство 8-10 так и не состоялся по причине действительной убогости нового интерфейса (имхо). МС решили адаптировать десктопную винду для планшетов, чтобы можно было тыкать в нее пальцем — да действительно, если на планшете запустить классический интерфейс, то работать с ним получится с большим трудом, т.к. попасть пальцем в мелкую иконку tree expand действительно трудно. Но зато работать с мышкой в новом интерфейсе просто неудобно. Да и тенденция к сокращению количества цветов мне не по душе — я специально оставил себе офис 2010, т.к. он последний в нормальной цветовой гамме. На работе стоит как раз 2013, каждый раз плююсь при его запуске. Также плавность перемещения курсора в excel на мой взгляд делает работу с ним только хуже (может где можно отключить, не смотрел).
Тем не менее, есть люди, которым новый интерфейс 10-ки кажется очень логичным, красивым и удобным.
У разных людей разное ощущение времени.
И время отклика программ важно чувства для комфорта определенной доли IT-персонала.
По этому программы на WinAPI, которые очень эффективно работают, всегда будут востребованы.
А следовательно и специалисты.
20 лет назад, учась в школе, вызывал функции WinApi на VisualBasic тогда это казалось крутой магией. Сейчас это кажется детством, теплым и безоблачным… Думал, что сейчас этого уже нет, ан нет
UFO just landed and posted this here
А можно чуть подробнее, в чем проблема заключается?
Закопался в исходники очень многолетней давности, нашел вполне себе ожидаемое
LRESULT CALLBACK WindowFunc(HWND hwnd, UINT message,WPARAM wParam, LPARAM lParam){
switch (message){
...
case WM_KEYDOWN: OnKey(hwnd,wParam,lParam);break;
...
default: return DefWindowProc(hwnd,message,wParam,lParam);
}
return 0;
}Вроде работало
Или речь о каком-то особенном диалоге?
Вся проблема возникает, когда в дело вступает IsDialogMessage. Как я уже писал, она нам дает преимущества в виде навигации в стиле диалогов, но при этом лишает возможности получать WM_KEYDOWN/KEYUP. Добавьте ее в цикл и WM_KEYDOWN у вас больше не придет. Вы можете ее не использовать явно, но если вы используете DialogBox/DialogBoxParam/DialogBoxParamIndirect — она будет вызываться (внутри этих функций).
В Вашем конкретном случае приведенный код — обычная процедура обработки для вашего собственного окна (LRESULT вместо INT_PTR, который у DlgProc и DefWindowProc вместо 'return 0'). И цикл обработки сообщений у Вас, скорее всего, IsDialogMessage не использует.
В Вашем конкретном случае приведенный код — обычная процедура обработки для вашего собственного окна (LRESULT вместо INT_PTR, который у DlgProc и DefWindowProc вместо 'return 0'). И цикл обработки сообщений у Вас, скорее всего, IsDialogMessage не использует.
Каждый разработчик под Win должен написать хотя бы одно приложение на чистом WinApi!
И потом больше никогда не пользоваться им :)
А как же маленькие и самодостаточные исполняемые файлы? ;-)
UFO just landed and posted this here
UFO just landed and posted this here
Программирование на WinApi вызывает боль, потому что даже для си оно написано крайне кандовым. Эти самые ресурсы и вызовы стоит использовать, если за разборки в этом аду будут платить.
DWORD BOOL VOID WINAPI CALLBACK LPVOID HIWORD TCHAR LPCTSTR STRADAY
PS: WinApi на C# — те же системные вызовы, но подружелюбнее.
Ага, щас. Оно было бы подружелюбнее если бы поддерживалось MS. Но ведь каждую используемую функцию нужно импортировать вручную, и никто автоматически не проверит ее сигнатуру…
UFO just landed and posted this here
А можно подробнее про утечки памяти на C#?
чёт вы тут напутали всё напрочь. Вы знаете о существовании итераторов, контейнеров vector, list, и прочих в С++ и об аналогах в С#. Вы знаете о том, что с массивами в голом виде не работают? Знаете о том, что в шарпе утечку памяти получить сложнее, чем в С++ (не используя умные указатели)? Знаете о существовании в С++ std::array и скором появлении std::dynarray и о том, что подобные штуки люди сами пишут?
я, если что, не придираюсь и т.п. Из вашего комментария не совсем ясно то, что конкретно вы подразумевали.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Эх, были времена. Помню изучал, дошел до примеров диалоговых окон на WinAPI. Плюнул и вернулся на MFC.
Но для графических приложений, типа игр — самое то.
Но для графических приложений, типа игр — самое то.
Только так и пишу. Никаких MFC или OWL! Может быть код и будет чуточку объёмней (и то не факт), зато конечный результат будет — супер. Приложения получаются компактней и быстрей. А у этих библиотек время от времени параметры в методах меняются. Я в своё время накололся на этом, когда у борланда сначала была библиотека owl1, а потом пошла owl2, и параметры в функциях поменялись. С тех пор зарёкся. И описание в таких библиотеках тоже остаётся желать лучшего. А описание функций WinAPI всегда можно найти. Поэтому автора заметки поддерживаю за здоровый консерватизм.
Кстати, объектный подход для окон хорошо ложится в код. Любую функцию обратного вызова можно переделать, как нужно. В своё время таким образом мне удалось сделать форматный ввод в окнах. Причём отладка много времени не заняла.
Кстати, объектный подход для окон хорошо ложится в код. Любую функцию обратного вызова можно переделать, как нужно. В своё время таким образом мне удалось сделать форматный ввод в окнах. Причём отладка много времени не заняла.
Там не на несколько статей, а на несколько книжек. Вон Фроловы, может помните таких, так те несколько книжек написали по Windows API. Хорошие книжки были с примерами, с разбором.
Лет 10 назад (может больше) я на WinAPI написал приложение для абонентского отдела АТС. Ничего там сложного не было, простой учёт оплаты и начисление. Плюс несколько интегрированных отчётов. СУБД Interbase. Работало всё мгновенно. 500 записей начисления оплаты одной командой SQL выполнялось меньше чем за секунду. Хотя там была по тем временам довольно таки посредственная машина с каким-то селерончиком. Уже не помню. Загрузочный модуль был, не поверите, 170 килобайт.
А сейчас пишут непонятно на чём, работает всё через пень-колоду, никаких процессоров и памяти не настачишь!
Лет 10 назад (может больше) я на WinAPI написал приложение для абонентского отдела АТС. Ничего там сложного не было, простой учёт оплаты и начисление. Плюс несколько интегрированных отчётов. СУБД Interbase. Работало всё мгновенно. 500 записей начисления оплаты одной командой SQL выполнялось меньше чем за секунду. Хотя там была по тем временам довольно таки посредственная машина с каким-то селерончиком. Уже не помню. Загрузочный модуль был, не поверите, 170 килобайт.
А сейчас пишут непонятно на чём, работает всё через пень-колоду, никаких процессоров и памяти не настачишь!
Sign up to leave a comment.
Окна на чистом WinAPI. Или просто о сложном