Здравствуйте, TK, Вы писали:
TK>То, что нынешнего Win32 API не будет совсем — на это, наверное, не стоит рассчитывать (например с момента выхода Windows 3.x прошло уже больше 10-ти лет, а до сих пор в WinXP есть поддержка Win16...)
Там даже поддержка DOS FCB file IO есть, хотя этим уже давно никто не пользуется, со времен DOS 2.0
TK>Про вырезание — в этом я тоже несколько сомневаюсь. Скорее всего развитие Win32 API просто остановится и в дальнейшем все развитие будет сосредоточенно на longhorn api.
Думаю, что да. Примерно так же, как в свое время продвинули Win32. Common controls в Win16 не реализовали.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>И через пять лет чтения, я таки понял эти "25 интерфейсов" Правда не понял этот вопрос на вопрос.
Тогда должен представлять сколько там лишних действий.
OLEDB обладает дичайшей избыточностью. Да и с точки зрения производительности структуры данных OLEDB довольно плохи.
КД>OLEDB (с точки зрения реализации) проигрывает ADO.NET провайдеру только в тех позициях, где .NET выигрывает у COM. И наоборот. Все остальные измышления — бесполезный бред и трата времени, которые обусловлены толщиной и длиной шворцев.
Да нет, OLEDB в первую очередь проигрывает алгоритмически. Куча виртуальных КОМ-мовских вызовов конечно тоже замедляют работу, но не думаю, что больше чем просто ваозня с ACCESSOR-ами и т.п.
КД>Формально, в крупном приложении по-барабану через что работать — что через OLEDB напрямую (но только не для начинающих и только не через ATL.OLEDB и только не явно через интерфейсы), что через ADO (здесь проще, но есть нюансы), что через .NET-провайдер.
Реально чтобы работать с OLEDB напрямую нужно быть не всвоем уме. И начинающий или нет тут в общем-то без разницы. Хотя специалист конечно просто не имеет права на такие ошибки. OLEDB — это убогий низкоуровневый стандарт созданный явно не для прямого использования.
Вообще зачем было нужно лепить такого монстра как OLEDB я вообще не понимаю. Но это уже отдельная филосовская тема.
КД>Но пять лет назад, с точки зрения масштабируемости архитектуры конечного приложения, OLEDB был самым оптимальным выбором (правда начальная стоимость очень высокая).
С точки зреня масштабируемости, OLEDB и сейчас неплохо выглядит. Впрочем, как и доисторический ODBC.
КД> И на текущий момент, лично для меня, ничего не поменялось. Правда основная херня в том что MS не предоставила шлюз OLEDB провайдер<->OLEDB.NET провайдер, как это было сделано для ADODB в виде незадокументированных интерфейсов конструирования. Но, слава Богу, не первый год замужем
Я не знаю как эти слова относятся к тому о чем коворил я:
IP>вот это _очень_ сильно. только сильно сомневаюсь что сам этот юкон будет managed.
А тут и сомневаться нечено. Конечно... не будет. Но от этого ничего не меняется. Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих. Так что...
КД>В любом случае, глядя на свой провайдер, скажу, что нормальный драйвер (OLEDB/NET) "на ура" написать не реально.
Я не знаю что такое OLEDB/NET. Но знаю что оба типа провайдера пишутся. Только OLEDB с большим гемороидальным трахом, а дотнетный довольно просто. Собственно оных уже море и ни про какие проблемы не слышно.
КД> И постепенно уровень сложности реализации станет такого уровня, что один два лишних вызова (слоя) — это даже не копейки. Спрашиваете "почему"? Да потому, что драйвер (перешедший на промышленный уровень) однозначно будет состоять из двух уровней — того, с которым вы общаетесь наверху, и того, который общается с БД. А между этими двумя уровнями будут лежать абстрактные интерфейсы
Факты... батенька, факты... Банальные испытания показывают, что управляемый провадер для MSSQL работает отровенно быстрее нэйтивного OLEDB-провайдера. И тому есть простое обяснение. OLEDB — явно переусложненный стандарт рожденный от чего угодно, но только не от большого ума.
КД>Только для зрителей нашего телеканала, часть списка файлов OLEDB-провайдера для FireBird:
...
Спасибо, я не люблю читать ужастики перед сном. Кстати, управляемый провайдер для MSSQL занимает совсем чуть-чуть. И это правильно!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Блудов Павел, Вы писали:
БП>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.
Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.
Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
БП>>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.
VD>Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.
Во тут интересно — что с ним не так то? Оно ведь просто отражает реализацию. Если API кажется кривым, то ровно от того, что описываемая им область криво спроектирована, либо просто кривая по определению
Здравствуйте, mefrill, Вы писали:
M>Ну так, насколько я помню, есть же такая найтивная для SQl Server вещь как DB Library? Как утверждается в документации, все остальные интерфейсы поверх нее реализованы.
Можно привести цитатату?
Насколько мне извесно OLEDB реализован напрямую. Да и дотнетный провайдер тоже. Он использует тольок очень низкоуровневую библиотеку для чтения сырого потока данных. Далее закат солнца вручную.
M>Но, я так понял, что ты имел ввиду хорошую и быструю логику обработки абстракций (типов, данных и т.д.) через управляемый интерфейс? Хлтя и здесь мы ведь имеем дело с плоскими массивами данных.
OLEDB это еще тот монстр. Так чт и да, и нет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Блудов Павел, Вы писали:
БП>>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.
VD>Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.
VD>Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.
вот мне тоже интересно в чем конкретно кривость? единственное что можно поставить в вину винапям так это то что оно частично само себя дублирует (иногда не по разу), его использование имеет побочные эффекты иногда. мелочи вроде наличия нескольких стандартов обращения/передачи параметров опустим. что еще?
Здравствуйте, aik, Вы писали:
aik>Во тут интересно — что с ним не так то?
Кривизна, сложность и неудобсность в использовании.
aik> Оно ведь просто отражает реализацию. Если API кажется кривым, то ровно от того, что описываемая им область криво спроектирована, либо просто кривая по определению
Иногда случается и так. Но то что обертывание в менеджед обертки зачастую координально упрощает использование ВыньАПИ указывает именно на кривость реализации.
Простой пример который мне пришлось опробывать на своей шкуре совсем недавно. Функция SystemParametersInfo. Попробуй, например, с ее помощью сменить режим сглаживания шрифта на ClearType.
А как тебе интерфейсы OLEDB? А Защиты в СOM? Да куда не копни убогие и дико переусложненные интерфейсы.
А reserved-апраметры напиханные там и тут? А названия методов выбираемые рандомом (например, перечисли все методы вывода текста на экран в Windows).
Просто те кто этим ужасом пользуются сильно привыкли и не замечают маразма ситуации.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, aik, Вы писали:
aik>Раньше любая новая фича сопровождалась 2 уровнями API — winapi + надстройка в виде .net. Теперь от нас будут умышленно прятать winapi, хотя реально то он вряд ли куда то денется. Довольно неумный шаг в продвижении дотнета.
Вот Indigo и Avalon ничего не прячют. Они и есть исходное АПИ. Где-то в глубине недр они конечно обращаются к низкоуровневым АПИ ОС, но используя эти АПИ получить тот же результат просто не удастся. И сделано это не в целях продвижения дотнета (что это самоцель, что ли?), а в целях упрощения разработки и поддержки. Ну, и с целью уменьшения оверхэда создаваемого интеропом.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IPv6, Вы писали:
IP>вот мне тоже интересно в чем конкретно кривость? единственное что можно поставить в вину винапям так это то что оно частично само себя дублирует (иногда не по разу), его использование имеет побочные эффекты иногда. мелочи вроде наличия нескольких стандартов обращения/передачи параметров опустим. что еще?
. Сделай что там описано, и или поймшь все сам, или хотя бы будет предмет для разговора. Пока что говорить с тобой бесполезно. Нормального АПИ ты явно не видел, так что для тебя ВыньАПИ — это нормально. Для меня тоже оно было нормально... до тех пор покая не увидел, что бывает куда лучше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
КД>>И через пять лет чтения, я таки понял эти "25 интерфейсов" Правда не понял этот вопрос на вопрос.
VD>Тогда должен представлять сколько там лишних действий. VD>OLEDB обладает дичайшей избыточностью. Да и с точки зрения производительности структуры данных OLEDB довольно плохи.
Вот избыточности, кстати, я там не видел. Просто много интерфейсов, которые позволяют подстраиваться под клиентов с разным уровнем "интеллекта".
Хотя нет... IRow и IRowChange были созданы, когда кого-то в MS запарило работать с аксессорами
VD>Да нет, OLEDB в первую очередь проигрывает алгоритмически. Куча виртуальных КОМ-мовских вызовов ...
Вызовов не очень много, а вот предварительной работы — достаточно
VD>Реально чтобы работать с OLEDB напрямую нужно быть не всвоем уме.
Я и написал — напрямую не выйдет. Только через ADO. Я работаю без напрягов через свою плюсовую библиотеку
Насчет убогости — это ты зря. Просто сложная для понимания вещь. Но только дураки постоянно с ней живут.
В реальности, визуальные ActiveX компоненты гораздо сложнее. Я помню как тебя терроризировал относительно UserForm
VD>Вообще зачем было нужно лепить такого монстра как OLEDB я вообще не понимаю. Но это уже отдельная филосовская тема.
По-моему это внутренности MSSQL. Причем родил эту спецификацию явно человек с оторванным сознанием Многие вещи я понял только недавно, а он это родил еще в 98
VD>С точки зреня масштабируемости, OLEDB и сейчас неплохо выглядит. Впрочем, как и доисторический ODBC.
Ну, это, ставить ODBC рядом с OLEDB, это все равно что котенка сравнивать с тигром
КД>> И на текущий момент, лично для меня, ничего не поменялось.
VD>Я не знаю как эти слова относятся к тому о чем коворил я: VD>
IP>>Но от этого ничего не меняется. Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих. Так что...
Это нужно интерпретировать так — я понимаю откуда растут ноги
КД>> И постепенно уровень сложности реализации станет такого уровня, что один два лишних вызова (слоя) — это даже не копейки.
VD>Факты... батенька, факты... Банальные испытания показывают.
Факты? Только на основе своего провайдера. Когда я в него встроил парсер SQL запросов, я понял что про милое детство можно забыть
Кстати, страшно боялся что это отразиться на скорости работы системы в целом. К счатью, тормоза остались те же И даже когда я переписал этот парсер, заменил мьютексы на критические секции, оптимизировал конвертирование текстовых данных (из кодировки БД в кодировку клиента), вылизал все алгоритмы — скорости в целом это не прибавило. Хотя тесты — это да — IBP v3 проходит их в два раза быстрее чем IBP v2. Ну и ху$и ??? Меня это не радует абсолютно.
Так вот у меня тормозит в основном сервер, куда отправляются запросы, клиент, который эти запросы посылает и управляющие VB-скрипты, которые помогают клиенту генерировать эти запросы. Утрировано, конечно, но смысл такой — подозреваю что доля провайдера в общем объеме затрат CPU — ГОРАЗДО меньше 10%
И если раньше я жался насчет каждого вызова к провайдеру/сервер, типа "не дай бог использовать автоматическое формирование определений параметров!", то сейчас мне на это положить. Гораздо ценнее глобальная оптимизация системы Хотя, по старинке, продолжаю в работать только через SQL запросы.
VD>Кстати, управляемый провайдер для MSSQL занимает совсем чуть-чуть. И это правильно!
Я тоже люблю маленькие машины, но внедорожники нравятся гораздо больше — им что в гору ехать, что с горы — по-барабану
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Хотя нет... IRow и IRowChange были созданы, когда кого-то в MS запарило работать с аксессорами
Эксессоры сами по себе ужасны и избыточны.
КД>Я и написал — напрямую не выйдет. Только через ADO. Я работаю без напрягов через свою плюсовую библиотеку
С тем же успхом она могла бы работать напрямую с датастримом (как АДО.НЭТ). Так что приемущество от ОЛЕДБ тут только в его стандартности. Но ведь ОДБЦ был сто лет назад, и я уверен, что для твоей обертки работать с ним было бы куда проще.
КД>Насчет убогости — это ты зря. Просто сложная для понимания вещь. Но только дураки постоянно с ней живут.
Под убогостью я и понимаю сложность и неуклюжесть. С воможностями то там все ОК. Но все тоже самое делается куда проще. Просто не нужно было добиваться супер универсальности.
КД>В реальности, визуальные ActiveX компоненты гораздо сложнее. Я помню как тебя терроризировал относительно UserForm
А это тоже пример дебилизма АПИ. Только я все же ActiveX отношу к АПИ КОМ-а. Но по сути это тоже ВыньАПИ.
Честно говоря ActiveX и ОЛЕ2 проектировали тоже не вполне разумные люди. Я в этой каше года два разбирался, но вопросы остались. По сравнеию с этими технологиями ВыньФормс и их контролы — это супер гладкая архитектура и приятнейший АПИ. Жаль что только по сранвению.
КД>По-моему это внутренности MSSQL.
Я тоже так думал. Но когда копнул глубже, то оказалось, что и ОЛЕДБ, и ДБЛИБ, и ОДБЦ работают через практически одно и то же низкоуровневое АПИ и друг-друга не используют. А узнал я это как раз когда разбирался с тем как написан управляемый провайдер.
КД> Причем родил эту спецификацию явно человек с оторванным сознанием Многие вещи я понял только недавно, а он это родил еще в 98
По-моему, раньше, но может я тут ошибаюсь. Не, не ошибаюсь. Рядом, в коридоре, валяется справочник по ОЛЕДБ 1.1 дебильно переведенный "Русской редакцией" в 1997 году. Стало быть 1.0 было где-то в 1996-ом.
А сделан ОЛЕДБ был вроде бы как когда делали внешние запросы в сиквеле. Но думаю, планы были наполеоновскими. А ОЛЕ там появилось, так как в это время в МС все пытались переписать на КОМ.
КД>Ну, это, ставить ODBC рядом с OLEDB, это все равно что котенка сравнивать с тигром
Хм. ОЛЕДБ это тигр, или котенок? Для котенка очень уже жирный и огромный, а для тигра не поворотливый и опять же жирный.
Кстати, что тебе не хватает в ОДБЦ по сравнению с ОЛЕДБ?
КД>Ну и ху$и ??? Меня это не радует абсолютно.
Это, за мат здесь банят. Даже за такой. Так что в этот раз я не заметил. Но в следующий, не обессудь.
КД>Так вот у меня тормозит в основном сервер, куда отправляются запросы, клиент, который эти запросы посылает и управляющие VB-скрипты, которые помогают клиенту генерировать эти запросы. Утрировано, конечно, но смысл такой — подозреваю что доля провайдера в общем объеме затрат CPU — ГОРАЗДО меньше 10%
Я и не утверждаю, что скорость интерфейса может существенно замедлить прилоежение. Я всего лишь, сказал, что то что Юкон не менеджед не мешает с ним эффекивно работать, и привел обоснование. А тут дескуссия вокруг ОЛЕДБ организовалась.
КД>И если раньше я жался насчет каждого вызова к провайдеру/сервер, типа "не дай бог использовать автоматическое формирование определений параметров!", то сейчас мне на это положить. Гораздо ценнее глобальная оптимизация системы Хотя, по старинке, продолжаю в работать только через SQL запросы.
VD>>Кстати, управляемый провайдер для MSSQL занимает совсем чуть-чуть. И это правильно!
КД>Я тоже люблю маленькие машины, но внедорожники нравятся гораздо больше — им что в гору ехать, что с горы — по-барабану
Ох уж эти аналогии. И почему ты ОЛЕДБ к внедорожникам отнес? Работает ОЛДБ при доступе к сиквелу медленее. Используется наверно уже тоже реже чем нэйтивный провайдер. Так о чем разговор то?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Функция SystemParametersInfo. Попробуй, например, с ее помощью сменить режим сглаживания шрифта на ClearType.
Лехко! А я то думал там будет что либо сложное... Обычный косяк в MSDN... Ну не указали они что надо значение вместо указателя пхать. У меня их кста 2 шт (MSDN-а) так в одном написано что надо передавать указатель на значение а в другом что надо передавать значение в uiParam.
Так что тут надо дать по голове пьяным индусам из микрософт
#include <windows.h>
// Эти константы надо потому, что у меня дома 6-я старая вижуалка в .h которой этих определений нету#define FE_FONTSMOOTHINGCLEARTYPE 0x0002
#define SPI_SETFONTSMOOTHINGTYPE 0x200B
void main ()
{
DWORD smoothType = FE_FONTSMOOTHINGCLEARTYPE;
SystemParametersInfo (SPI_SETFONTSMOOTHING, TRUE, NULL, 0);
SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, (void*)FE_FONTSMOOTHINGCLEARTYPE, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
MessageBox (NULL,"Cleartype включен.","Мессага",MB_OK);
SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
SystemParametersInfo (SPI_SETFONTSMOOTHING, FALSE, NULL, 0);
MessageBox (NULL,"Фу! Cleartype + CRT моник = уродская картинка. Нафиг этот Cleartype","Мессага",MB_OK);
}
. Сделай что там описано, и или поймшь все сам, или хотя бы будет предмет для разговора. Пока что говорить с тобой бесполезно. Нормального АПИ ты явно не видел, так что для тебя ВыньАПИ — это нормально. Для меня тоже оно было нормально... до тех пор покая не увидел, что бывает куда лучше.
Дык вся проблема то не в том что API другой, а в том, что новый API гвоздями прибит к Managed C++. Вот это как раз и не нравится многим. Я например жутко не люблю когда меня вынуждают что то делать чего мне сильно не хочется. И считаю позицию мелкомягких "мы так решили а вы никуда не денетесь!" неуважением к программерам, которые пишут под вынь.
Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет?
Здравствуйте, CreatorCray, Вы писали:
CC>Лехко! А я то думал там будет что либо сложное...
Что же я изверг что ли?
Время то засек?
CC> Обычный косяк в MSDN...
Ой, МСДН-а ли? У меня в МСДН-е все ОК. Но вот назвать это нормальным я не могу.
CC> Ну не указали они что надо значение вместо указателя пхать. У меня их кста 2 шт (MSDN-а) так в одном написано что надо передавать указатель на значение а в другом что надо передавать значение в uiParam. CC>Так что тут надо дать по голове пьяным индусам из микрософт
Это ты заметил. А ты не обратил внимание на маразматичность ситуации когда нужно значение приводить к указаетелю? Ты считашь это нормальным?
CC>
CC>#include <windows.h>
CC>// Эти константы надо потому, что у меня дома 6-я старая вижуалка в .h которой этих определений нету
CC>#define FE_FONTSMOOTHINGCLEARTYPE 0x0002
CC>#define SPI_SETFONTSMOOTHINGTYPE 0x200B
CC>void main ()
CC>{
CC> DWORD smoothType = FE_FONTSMOOTHINGCLEARTYPE;
CC> SystemParametersInfo (SPI_SETFONTSMOOTHING, TRUE, NULL, 0);
CC> SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, (void*)FE_FONTSMOOTHINGCLEARTYPE, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
CC> MessageBox (NULL,"Cleartype включен.","Мессага",MB_OK);
CC> SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
CC> SystemParametersInfo (SPI_SETFONTSMOOTHING, FALSE, NULL, 0);
CC> MessageBox (NULL,"Фу! Cleartype + CRT моник = уродская картинка. Нафиг этот Cleartype","Мессага",MB_OK);
CC>}
CC>
А запоминать исходный вариант кто будет? Да и во втором случае ты не включашь стандартное сглаживаение, ты выключаешь его вовсе.
А вот как выглядит тоже самое на базе АПИ которое спроектировано более размуно:
// Запоминаем исходное значение настроек сглаживания.
FontSmoothingType initialFontSmoothingType = SysInfo.FontSmoothingType;
foreach (FontSmoothingType value in Enum.GetValues(typeof(FontSmoothingType)))
{
SysInfo.FontSmoothingType = value;
MessageBox.Show("Режим сглаживания - " + value + ".", "Мессага");
}
SysInfo.FontSmoothingType = initialFontSmoothingType;
Его конечно не сложно повторить и на С++, но почему-то это не делается. Вместо этого вот такие приколы с приведением констант к указателям на void. Причем зачем это было делать когда у метода есть целочисленный параметр? Да и вообще зачем деалать универсальную функцию в которую можно подсунуть все что угодно? Почему не сделать две специализированные? Это ведь позволило бы вообще не иметь проблем у программистов. Ну, и последнее... Зачем было вводить включение режима сглаживания и переключения типов сглаживания? Ведь проще было ввести тип сглаживания — None.
К сожалению, чтобы из убогого ВыньАПИ-стиля сделать то что я продемонстрировал приходится писать вот такие вот обертки:
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;
using System.Windows.Forms;
using System.Drawing;
using System.Diagnostics;
using Microsoft.Win32;
namespace Rsdn.Windows.Forms
{
/// <summary>
/// <b>FontSmoothingTypes</b> Specifies fontsmoothing/antialiasing.
/// </summary>public enum FontSmoothingType : uint
{
None = 0,
/// <summary>FE_FONTSMOOTHINGSTANDARD</summary>
Standard = 1,
/// <summary>FE_FONTSMOOTHINGCLEARTYPE</summary>
ClearType = 2
}
public class VideoAdapterInfo
{
public VideoAdapterInfo(string name, Rectangle bounds)
{
_name = name;
_bounds = bounds;
}
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
string _name;
public string Name
{
get { return _name; }
}
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
Rectangle _bounds;
public Rectangle Bounds
{
get { return _bounds; }
}
}
/// <summary>
/// <b>ClearTypeController</b> Wrapper class for Win32 IsFontSmoothingEnabled API.
/// Use Redraw() to perform instant changes.
/// </summary>public class SysInfo
{
#region Импорт API-шных функций
#region Константы
enum RDW : uint
{
Invalidate = 1, // 0x1;
InternalPaint = 2, // 0x2;
Erase = 4, // 0x4;
AllChildren = 128, // 0x80;
UpdateNow = 256, // 0x100;
EraseNow = 512, // 0x200;
Frame = 1024, // 0x400;
}
enum SPI : uint
{
GetFontSmoothing = 74, // 0x004A;
SetFontSmoothing = 75, // 0x004B;
GetFontSmoothingType = 8202, // 0x200A;
SetFontSmoothingType = 8203, // 0x200B;
GetFontSmoothingContrast = 8204, // 0x200C;
SetFontSmoothingContrast = 8205, // 0x200D;
}
enum SPIF : uint
{
UpdateInifile = 1, // 0x1;
SendChange = 2, // 0x2;
SendWininiChange = 2, // 0x2;
TELLALL = UpdateInifile | SendWininiChange, // 0x1 | 0x2;
}
#endregion
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool RedrawWindow(IntPtr hWnd, int lprcUpdate,
int hrgnUpdate, [MarshalAs(UnmanagedType.U4)] RDW flags);
// SPI_SETFONTSMOOTHING
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SystemParametersInfo(SPI uiAction, bool uiParam,
IntPtr pvParam, SPIF fWinIni);
// SPI_GETFONTSMOOTHING
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
out bool pvParam, SPIF fWinIni);
// SPI_SETFONTSMOOTHINGTYPE && SPI_SETFONTSMOOTHINGCONTRAST
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
IntPtr pvParam, SPIF fWinIni);
// SPI_GETFONTSMOOTHINGTYPE && SPI_GETFONTSMOOTHINGCONTRAST
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
out int pvParam, SPIF fWinIni);
// SPI_GETFONTSMOOTHINGTYPE
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
out FontSmoothingType pvParam, SPIF fWinIni);
enum Monitor : uint
{
DefaultToNull = 0,
DefaultToPrimary = 1,
DefaultToNearest = 2,
}
/// <summary>
///
/// </summary>
/// <param name="hwnd">handle to a window</param>
/// <param name="dwFlags">determine return value</param>
/// <returns></returns>
[DllImport("user32.dll")]
private static extern IntPtr MonitorFromWindow(IntPtr hwnd, Monitor flags);
[StructLayout(LayoutKind.Sequential)]
public struct RECT
{
public int left;
public int top;
public int right;
public int bottom;
public RECT(Rectangle r)
{
this.left = r.Left;
this.top = r.Top;
this.right = r.Right;
this.bottom = r.Bottom;
}
public RECT(int left, int top, int right, int bottom)
{
this.left = left;
this.top = top;
this.right = right;
this.bottom = bottom;
}
public static RECT FromXYWH(int x, int y, int width, int height)
{
return new RECT(x, y, x + width, y + height);
}
public int Width { get { return right - left; } }
public int Height { get { return bottom - top; } }
public Rectangle ToRectangle()
{
return new Rectangle(left, top, Width, Height);
}
public Size Size { get { return new Size(right - left, bottom - top); } }
}
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto, Pack = 4)]
class MONITORINFOEX
{
public MONITORINFOEX()
{
cbSize = Marshal.SizeOf(typeof(MONITORINFOEX));
}
private const int szDeviceSize = 0x20;
public int cbSize;
public RECT rcMonitor;
public RECT rcWork;
public int dwFlags;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = szDeviceSize)]
public string Device;
}
//[DllImport("user32.dll")]
//static extern bool GetMonitorInfo(IntPtr hMonitor, MONITORINFOEX lpmi);
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern bool GetMonitorInfo(IntPtr hmonitor,
[In, Out] MONITORINFOEX info);
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto, Pack = 4)]
class DISPLAY_DEVICE
{
internal DISPLAY_DEVICE()
{
cb = Marshal.SizeOf(typeof(DISPLAY_DEVICE));
}
private const int DeviceNameSize = 32;
private const int OtherSize = 128;
int cb;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = DeviceNameSize)]
internal string DeviceName;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = OtherSize)]
internal string DeviceString;
internal uint StateFlags;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = OtherSize)]
string DeviceID;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = OtherSize)]
internal string DeviceKey;
};
[DllImport("user32.dll", CharSet = CharSet.Auto)]
static extern bool EnumDisplayDevices(string lpDevice, int iDevNum,
[In, Out] DISPLAY_DEVICE lpDisplayDevice, uint dwFlags);
#endregion
#region Font smoothing information
/// <summary>
/// Gets or sets a value indicating whether font smoothing is enabled.
/// </summary>public static bool IsFontSmoothingEnabled
{
get
{
bool fontSmoothing;
Verify(SystemParametersInfo(SPI.GetFontSmoothing, 0,
out fontSmoothing, 0));
return fontSmoothing;
}
set
{
Verify(SystemParametersInfo(SPI.SetFontSmoothing, value, IntPtr.Zero,
SPIF.SendWininiChange | SPIF.UpdateInifile));
}
}
/// <summary>
/// Gets or sets the current type of font smoothing.
/// </summary>public static FontSmoothingType FontSmoothingType
{
get
{
FontSmoothingType fontSmoothingType;
if (!IsFontSmoothingEnabled)
return FontSmoothingType.None;
Verify(SystemParametersInfo(SPI.GetFontSmoothingType, 0,
out fontSmoothingType, 0));
return fontSmoothingType;
}
set
{
bool isFontSmoothing = value != FontSmoothingType.None;
IsFontSmoothingEnabled = isFontSmoothing;
if (isFontSmoothing)
Verify(SystemParametersInfo(SPI.SetFontSmoothingType, 0,
(IntPtr)value, SPIF.SendWininiChange | SPIF.UpdateInifile));
}
}
/// <summary>
/// Gets or sets the font smoothing contrast value used in ClearType
/// smoothing.
/// The value must be betwin 1000 and 2200. Default value 1400.
/// </summary>public static int FontSmoothingContrast
{
get
{
int fontSmoothingContrast;
Verify(SystemParametersInfo(SPI.GetFontSmoothingContrast, 0,
out fontSmoothingContrast, 0));
return fontSmoothingContrast;
}
set
{
if (value > 2200 || value < 1000)
throw new ArgumentException(
"The value must be between 1000 and 2200.");
Verify(SystemParametersInfo(SPI.SetFontSmoothingContrast, 0,
(IntPtr)value, SPIF.SendWininiChange | SPIF.UpdateInifile));
}
}
#endregion
#region Video Adapter information
public static VideoAdapterInfo GetVideoAdapterInfo(IWin32Window wnd)
{
IntPtr hMonitor = MonitorFromWindow(wnd.Handle, Monitor.DefaultToNearest);
Verify(hMonitor != IntPtr.Zero);
// Получаем описание монитора
MONITORINFOEX monitorInfoEx = new MONITORINFOEX();
Verify(GetMonitorInfo(hMonitor, monitorInfoEx));
// Ищем описание адаптера...string adapterDevName = monitorInfoEx.Device;
string adapterName = "";
// Перебираем все адаптеры и ищем среди них адаптер имя которого
// совпадает с adapterDevName (полученным ранее из монитора).for (int i = 0; ; i++)
{
DISPLAY_DEVICE displayDevice = new DISPLAY_DEVICE();
if (!EnumDisplayDevices(null, i, displayDevice, 0))
break;
if (adapterDevName == displayDevice.DeviceName)
{
adapterName = displayDevice.DeviceString;
break;
}
}
return new VideoAdapterInfo(adapterName,
monitorInfoEx.rcMonitor.ToRectangle());
}
#endregion
#region Processor information
public static string GetProcessorName()
{
using (RegistryKey hKey = Registry.LocalMachine.OpenSubKey(
@"Hardware\Description\System\CentralProcessor\0"))
{
string processor = (string)hKey.GetValue(
"ProcessorNameString", "unknown");
int mhz = Convert.ToInt32(hKey.GetValue("~MHz", 0));
if (mhz > 0)
processor += string.Format(" ({0} MHz)", mhz);
return processor;
}
}
#endregion
#region Вспомогательные методы
/// <summary>
/// Проверяет значение параметра <paramref name="test"/> и возбуждает
/// исключение Win32Exception если оно равно false.
/// </summary>
[DebuggerHidden]
private static void Verify(bool test)
{
if (!test)
throw new Win32Exception();
}
/// <summary>
/// Redraw the Windows desktop area and active windows. Returns true on
/// success and false if it fails.
/// </summary>public static bool Redraw()
{
bool status = RedrawWindow(IntPtr.Zero, 0, 0,
RDW.Erase | RDW.Frame | RDW.AllChildren | RDW.InternalPaint
| RDW.Invalidate | RDW.EraseNow | RDW.UpdateNow);
return status;
}
#endregion
}
}
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Дык вся проблема то не в том что API другой, а в том, что новый API гвоздями прибит к Managed C++.
К дотнету.
CC> Вот это как раз и не нравится многим. Я например жутко не люблю когда меня вынуждают что то делать чего мне сильно не хочется. И считаю позицию мелкомягких "мы так решили а вы никуда не денетесь!" неуважением к программерам, которые пишут под вынь.
А тебя не напрягает, что в дотнете доступны горы кода нре доступные в С++? WinFX — это управляемая библиотека. Этим все сказано.
CC>Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет?
Когда как. Вот WinFX в основном реализован на C# (частично на МС++). Только на низком уровне используются неуправляемый код (для отрисовки примитивов).
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.