API

← →
Post_ (2007-01-11 10:06) [0]

Какие API функции возвращают ширину и высоту экрана..??
Надо вавести окошко в правем нижнем углу....

← →
@!!ex © (2007-01-11 10:09) [1]

GetSystemMetrics

← →
DVM © (2007-01-11 10:10) [2]

function ScreenWidth : integer; begin Result := GetSystemMetrics(SM_CXSCREEN); end; //------------------------------------------------------------------------------ function ScreenHeight : integer; begin Result := GetSystemMetrics(SM_CYSCREEN); end; //------------------------------------------------------------------------------ function ScreenRect : TRect; begin Result.Left := 0; Result.Top :=0; Result.Right := GetSystemMetrics(SM_CXSCREEN); Result.Bottom := GetSystemMetrics(SM_CYSCREEN); end;

← →
Post_ (2007-01-11 10:13) [3]

> @!!ex © (11.01.07 10:09) [1]

> DVM © (11.01.07 10:10) [2]

ОК! Спас...!!!

← →
Anatoly Podgoretsky © (2007-01-11 11:41) [4]

> Post_ (11.01.2007 10:06:00) [0]

Screen.Width/Height

← →
homm © (2007-01-11 12:24) [5]

> [4] Anatoly Podgoretsky © (11.01.07 11:41)
> > Post_ (11.01.2007 10:06:00) [0]
>
> Screen.Width/Height

А**енная API функция. :-/

← →
DVM © (2007-01-11 12:34) [6]

> Anatoly Podgoretsky © (11.01.07 11:41) [4]

Между прочим, Screen.Width/Height глючная функция, как и весь объект Screen в мультимониторной среде. Да и не Win32 Api это.

← →
Anatoly Podgoretsky © (2007-01-11 12:36) [7]

> DVM (11.01.2007 12:34:06) [6]

Вот когда сможешь удалить модуль System из программы, тогда будешь и говорить об АПИ

← →
DVM © (2007-01-11 12:41) [8]

> Вот когда сможешь удалить модуль System из программы, тогда
> будешь и говорить об АПИ

Я буду говорить о чем захочу, когда захочу, я Вам как то об этом уже говорил. И модуль System тут не при чем, тем более что объект Screen объявлен не в нем.
Человек спрашивал API функцию - и ему ответили правильно. Вы, вероятно, не заметили слова API и дали неверный совет.

← →
Anatoly Podgoretsky © (2007-01-11 12:47) [9]

> DVM (11.01.2007 12:41:08) [8]

Чтож, твоими словами, я буду говорить о чем захочу, когда захочу, я Вам как то об этом уже говорил.
И не делай вывода о моем зрение, у тебя нет лицензии на врачебную практику.
А вот если ты не понял о чем я говорю, так это твоя проблема и я не врач тебе.

← →
DVM © (2007-01-11 12:54) [10]

Удалено модератором
Примечание: С данного момента вся личная переписка будет удаляться

← →
Lamer@fools.ua © (2007-01-11 16:28) [11]

>>DVM © (11.01.07 12:34) [6]

>Между прочим, Screen.Width/Height глючная функция, как и весь объект Screen в мультимониторной среде. Да и не Win32 Api это.
Угу. А самое глючное — свойство TScreen.Monitors.

← →
wicked © (2007-01-11 17:04) [12]

кстати, в мультимониторной среде GetSystemMetrics с параметрами SM_CXSCREEN и SM_CYSCREEN будет возвращать размерности primary дисплея...
чего, в общем то, хватает для 90% приложений

← →
DVM © (2007-01-11 18:24) [13]

> А самое глючное — свойство TScreen.Monitors.

Там ситуация такая. Если в процессе работы программы меняется количество мониторов или их разрешения, объект Screen не обновляет свои данные о мониторах. Они обновляются только при создании новой формы.
Неправильно Screen написан. Неудобно, точнее.

Выход есть. При получении сообщения об изменении разрешения/мониторов создавать объект Screen еще один, считывать данные из него и уничтожать нафиг. Это если с API возиться неохота.

← →
@!!ex © (2007-01-11 21:45) [14]

> DVM © (11.01.07 18:24) [13]

В вы уверены, что автору этого топика оно надо? :))

А вообще наезд на Анатолия не оправдан.
Так как автор не использовал сочетания Win API.
Да и вопрос задал не в форуме WinAPI, <=> вопрос к WinAPI не относится.
Стандартные функции Дельфи спокойно подходят под частное определение API.

← →
Eraser © (2007-01-11 22:21) [15]

там, где можно использовать VCL, нужно использовать VCL, а не API. imho.

← →
@!!ex © (2007-01-11 22:27) [16]

> Eraser © (11.01.07 22:21) [15]

Обоснуйте?

AFAIK там где можно использовать WinAPI без ощутимой потери времени разработки лучше использовать WinAPI.
ПРичины:
1) Сам программер абстрагируется от конкретного языка и переход на другой язык не будет для него проблемой.(На себе испытал. Елси пишеш без VCL, то пофиг на чем писать, на дельфе или на сях)
2) Прога абстрагируется от конкретного языка. И любая ее часть(или даже вся прога) без проблем переносится на другой язык.
3) VCL всегда был и остается избыточным там, где это обычно не нужно.
4) VCL зачастую написан очень хинтово.

Все перечисленне - применительно к первой строчке мессаги.

← →
Anatoly Podgoretsky © (2007-01-11 22:41) [17]

> @!!ex (11.01.2007 22:27:16) [16]

Для указаной функции это уже не относится, это уже заведомое замедление, поскольку потребуется вызов функции, а это работа уже сделана и результат находится в переменной Screen типа TScreen
Поэтому вызов лишний.

← →
@!!ex © (2007-01-11 22:45) [18]

> Anatoly Podgoretsky © (11.01.07 22:41) [17]

В принципе согласен. И таких примеров много.
Но НО всеже есть.
Данные в Screen обновляются весьма некорректно, в то время как АПишная функция вернет все как положенно.

← →
Anatoly Podgoretsky © (2007-01-11 22:53) [19]

> @!!ex (11.01.2007 22:45:18) [18]

Насчет обновления это другой вопрос, решаемый к тому же, информацию найти в Инет не сложно. Но в вопросе ничего про обновление.

← →
@!!ex © (2007-01-11 22:56) [20]

Ок. Согласен.
Всем удачи и споконой ночи..
Завтра экзамен, блин сдавать...

← →
Юрий Зотов © (2007-01-11 23:13) [21]

> DVM © (11.01.07 12:34) [6]
> Screen.Width/Height глючная функция

> @!!ex © (11.01.07 22:45) [18]
> Данные в Screen обновляются весьма некорректно, в то время как
> АПишная функция вернет все как положенно.

А теперь не заглянуть ли нам в генофонд?

Заглядываем - и что же мы видим? А вот что:
function TScreen.GetHeight: Integer; begin Result := GetSystemMetrics(SM_CYSCREEN); end; function TScreen.GetWidth: Integer; begin Result := GetSystemMetrics(SM_CXSCREEN); end;
Сравниваем с [2].

LOL. LOL. LOL. LOL. LOL.

← →
Eraser © (2007-01-11 23:45) [22]

> [16] @!!ex © (11.01.07 22:27)

> Обоснуйте?

> 1) Сам программер абстрагируется от конкретного языка и
> переход на другой язык не будет для него проблемой

зачем переходить на другой язык программирования? имеет смысл переходить на другую платформу или же писАть кроссплатформенный код, в последнем случае выбор за Java или C.

> 2) Прога абстрагируется от конкретного языка. И любая ее
> часть(или даже вся прога) без проблем переносится на другой
> язык.

см. п.1 + твой код состоит только из вызова API?

> 4) VCL зачастую написан очень хинтово.

не понял, что подразумевается под хинтово, но VCL написан весьма качественно.

теперь мои аргументы.
1. использование методов VCL гораздо удобнее в большенстве случаев, т.к. избавляет вручную вести контроль дескрипторов и т.п., к тому же объектная модель горазо более понятна. к примеру работа с GDI и графикой через методы TBitmap и TCanvas на порядок проще, чем использование API.
2. грамотно написаный VCL проект, особенно прикладной, гораздо проще перевести на Delphi.NET, чем проект с активным использованием прямых вызовов API.

PS никогда не понимал и вряд ли пойму людей, пишущих на "чистом API" на Делфи. MSVC++ для этого гораздо более приспособлен, чего стОит один только PlatformSDK.

← →
Eraser © (2007-01-11 23:46) [23]

> 3) VCL всегда был и остается избыточным там, где это обычно
> не нужно.

пример, если можно?

← →
Gero © (2007-01-11 23:50) [24]

> [22] Eraser © (11.01.07 23:45)
> PS никогда не понимал и вряд ли пойму людей, пишущих на
> «чистом API» на Делфи

А чего тут понимать, язык красивый и человечный.

← →
Eraser © (2007-01-11 23:58) [25]

не спорю :)
зачем писАть на чистом API вот что непонятно, при этом многие вопрошающие, по каким-то не понтным причинам, отказываются использовать даже функции из модуля system ))

← →
Anatoly Podgoretsky © (2007-01-12 01:09) [26]

> Gero (11.01.2007 23:50:24) [24]

Это ассемблер человеческий и красивый, а все остальные извращения над ним.

← →
Германн © (2007-01-12 02:40) [27]

> Anatoly Podgoretsky © (12.01.07 01:09) [26]
>
> > Gero (11.01.2007 23:50:24) [24]
>
> Это ассемблер человеческий и красивый, а все остальные извращения
> над ним.
>

Я как ПШП, полностью присоединяюсь! Всё своё родное пишу только на нём! И ни разу не имел геморроев :) Ошибки да, но кто не ошибается? Тем более, что эти ошибки исправляются, как "два пальца об асфальт"! Но я понимаю, что мо(й)(и) ассэмблер(ы), гораздо проще.

← →
Post_ (2007-01-12 17:51) [28]

8-o
Да нестоило так ветку раскачегаривать...
:o))

> Юрий Зотов © (11.01.07 23:13) [21]

Действительно LOL. :)
Спасибо, что исправили сие недоразумение.
Одна все ранво лучше юзать прямой вызов...
Сэкономим на вызове функции. :))

> зачем переходить на другой язык программирования? имеет
> смысл переходить на другую платформу или же писАть кроссплатформенный
> код, в последнем случае выбор за Java или C.

Хотя бы за тем, что С++ более распространен, да и платят спецам на нем поболе денег.
Лично для меня основная причина была в том, что в том деле которым я занимаюсь нет дельфистов вообще.

> см. п.1 + твой код состоит только из вызова API?

В идеале - да.
Но я как и все здесь присутствующие не идеален и предпочитаю в ряде случаев использовать готовые дельфевые функции.
Однако, если потребуется я смогу без проблем написать свою реализацию скажем TBitMap на дельфе или на сях.

> не понял, что подразумевается под хинтово, но VCL написан
> весьма качественно.

LOL.... Серьезно? Он написан весьма качественно, но не настолько насколько это требуется в ряде случаев.

Хинтово - давольно распространенное выражение, почему то не вызывает удвиления ни в Калининграде, ни в Москве, ни в Самаре, только у вас....
Хинтово - через Ж....

> 1. использование методов VCL гораздо удобнее в большенстве
> случаев, т.к. избавляет вручную вести контроль дескрипторов
> и т.п., к тому же объектная модель горазо более понятна.
> к примеру работа с GDI и графикой через методы TBitmap
> и TCanvas на порядок проще, чем использование API.

Читаем внимательно:

> Все перечисленне - применительно к первой строчке мессаги.

А там написано:

> AFAIK там где можно использовать WinAPI без ощутимой потери
> времени разработки лучше использовать WinAPI.

ИМХО писать свой TBitMap - ощутимая потеря времени.

> PS никогда не понимал и вряд ли пойму людей, пишущих на
> "чистом API" на Делфи. MSVC++ для этого гораздо более приспособлен,
> чего стОит один только PlatformSDK.

Platform SDK - часть MSVC++??? :))
А я то наивно полагал, что это часть MSDN.
Она входит в опставку студии, но ничто не мешает за копейку купить MSDN отдельно. Или пользоваться онлайн версией.
Еще вопрос, чем по вашему более приспособлен MSVC для использования WinAPI? У него заточка какая то особенная?

> Eraser © (11.01.07 23:46) [23]

Насколько процентов вы используете возможность компонентов, кинутых на форму? А код благополучно перекачевывает весь(или почти весь), насколько мне известно.

> Gero © (11.01.07 23:50) [24]

Это дело привычки. Шарписты не понимают, как можно на этом д... чето писать. Я тоже считаю, что дельфи человечнее и понятнее, но преркасно понимаю, что это просто из-за 11 лет проведенных за его использованием.

> Anatoly Podgoretsky © (12.01.07 01:09) [26]

:Handshake:

> [29] @!!ex © (12.01.07 18:16)

> Шарписты не понимают

Ох уж эти шарписты. Шарп, безусловно, проще Delphi, хотя и менее человечен.

> Gero © (12.01.07 18:22) [30]

Х.з.... мне было доастаточно один раз посмотреть на код шарповский, чтобы понять, что я не хочу его изучать. :))

> [29] @!!ex © (12.01.07 18:16)

> Она входит в опставку студии, но ничто не мешает за копейку
> купить MSDN отдельно. Или пользоваться онлайн версией.

Platform SDK можно скачать бесплатно с сайта микрософта. только для Делфи это как мёртвому препарок, заголовки прийдется переписывать вручную. есть конечно API от jedi, которым я активно пользуюсь, но оно 2002 года...
а вот к MSVC++ Platform SDK подходит без исправлений... с чего бы это? ))

> Насколько процентов вы используете возможность компонентов,
> кинутых на форму?

вопрос не в том, на сколько я активно использую компоненты, а в том, на сколько быстро у меня получается спроектировать интерфейс, по сравнению с тем, если бы я это делал на чистом API.
кстати если уж отказываться от VCL, то, в первую очередь, от модуля forms, стальное всё - копейки в несколько десятков КБ.

> Шарписты не понимают, как можно на этом д... чето писать.
> Я тоже считаю, что дельфи человечнее и понятнее, но преркасно
> понимаю, что это просто из-за 11 лет проведенных за его
> использованием.

C# достойная замена Делфи, imho.

> Шарп, безусловно, проще Delphi

спорный вопрос, один механизм сообщений, основанный на делегатах чего стОит..

> [31] @!!ex © (12.01.07 18:44)

код, как код..
на php по-программируйте ))

> Platform SDK можно скачать бесплатно с сайта микрософта.
> только для Делфи это как мёртвому препарок, заголовки прийдется
> переписывать вручную. есть конечно API от jedi, которым
> я активно пользуюсь, но оно 2002 года...
> а вот к MSVC++ Platform SDK подходит без исправлений...
> с чего бы это? ))

Вы предлагаете не использовать Windows.pas? :))
Собственно почему? Он ИМХО не несет недостатков присущих большинству модулей Дельфи. Там тупо объявляются функции.
Да и свой заголовочиный файл прописать - не особо проблема. Только зачем?

> вопрос не в том, на сколько я активно использую компоненты,
> а в том, на сколько быстро у меня получается спроектировать
> интерфейс, по сравнению с тем, если бы я это делал на чистом
> API.
> кстати если уж отказываться от VCL, то, в первую очередь,
> от модуля forms, стальное всё - копейки в несколько десятков
> КБ.

Читайте мой пост где я рекомендовал не использовать VCL еще раз, вдумчиво. Еще раз процетирую:

> AFAIK там где можно использовать WinAPI без ощутимой потери
> времени разработки лучше использовать WinAPI.

От модуля формс уже давно отказался и от аппликейшена тоже.
Этот тот случай когда выбора порсто нет.
Использование SysUtils еще могу себе позволить, а формс - это уже серьезный излишек.

> C# достойная замена Делфи, imho.

Это одна из причин по которой не уважаю С с решеткой.
Дельфи не нужно заменять, а если переходить, то на обычный С.
Эффективней, ИМХО, конечно же.

> код, как код..
> на php по-программируйте ))

Программировал. РНР не позволяет делать такие извраты.

> [33] @!!ex © (12.01.07 20:35)

> Вы предлагаете не использовать Windows.pas? :))
> Собственно почему?

я предлагаю не использовать модуль pas в тех случаях, когда проще и удобнее обойтись VCL.

> Он ИМХО не несет недостатков присущих большинству модулей
> Дельфи.

и какие же недостатки присущи большенству модулей? )

> Да и свой заголовочиный файл прописать - не особо проблема.

да ладна не проблема! эт когда одна-две функции не проблема, а когда пару интерфейсов и несколько десятков функций, к которым в предачу еще столько же структур и всяких enum-ов.. не проблема? когда для VS уже всё написано производителем.

> От модуля формс уже давно отказался и от аппликейшена тоже.

так надо быть последовательным до конца и отказаться от Делфи! чесслово говорю - проблем меньше будет ))
а ты не вирусы с троянами пишешь случаем? :) ума не приложу что за тип приложения должен быть, где 200 КБ играют решающую роль.

> Дельфи не нужно заменять, а если переходить, то на обычный
> С.

назад в будущее что ли? ) с трудом себе представляю прикладное программирование на C. почему не на асме сразу? )

> Программировал. РНР не позволяет делать такие извраты.

дададад ))
там по-моему вообще всё можно )
а вот в C# типизация данных строгая.

> и какие же недостатки присущи большенству модулей? )

Я уже писал. Читайте внимательнее.

> да ладна не проблема! эт когда одна-две функции не проблема,
> а когда пару интерфейсов и несколько десятков функций,
> к которым в предачу еще столько же структур и всяких enum-
> ов.. не проблема? когда для VS уже всё написано производителем.
>

Для Дельфи тоже. В Windows.pas многое написано. Пример в студию того, чего там нету и что нужно бывает.

> так надо быть последовательным до конца и отказаться от
> Делфи! чесслово говорю - проблем меньше будет ))
> а ты не вирусы с троянами пишешь случаем? :) ума не приложу
> что за тип приложения должен быть, где 200 КБ играют решающую
> роль.

Ткните пальцем, плиз, в то место где я говорил, что отказался от формс из-за размера? :))
Мне критична скорость работы. Форма работает медленно АПИшного окна.
Как и все остальные компоненты, впрочем.
Только для интерфеса это обычно не критично.
А чем я занимаюь...
Если бы вы тусили не только в конфе "Прочее", то наверно знали бы, :))

> назад в будущее что ли? ) с трудом себе представляю прикладное
> программирование на C. почему не на асме сразу? )

А это уже придирка к словам. понятно что я имел ввиду С++.
Кстати, Ассемблер - рулез. На нем многое можно сделать, чего нельзя делать в паскале. Юзать SSE например.

> дададад ))
> там по-моему вообще всё можно )
> а вот в C# типизация данных строгая.

Ну тут вам виднее. С С# знаком весьма поверхностно.

> [36] @!!ex © (12.01.07 21:00)

> Я уже писал. Читайте внимательнее.

эт стандартный ответ такой, когда не знаешь что ответить? )

> Пример в студию того, чего там нету и что нужно бывает.

credentialprovider.h

> Мне критична скорость работы. Форма работает медленно АПИшного
> окна.

ну начинается снова ) обсуждали здесь это и не раз. домыслы всё это, а взять и потестировать с секундомером видать религия не позволяет... даже спорить не хочется.

> А это уже придирка к словам. понятно что я имел ввиду С++.

далеко не понятно! это полностью меняет суть вопроса! для программирования под виндовс C++ - умерающий язык. C же активно используется при написании драйверов.

> Юзать SSE например.

почему бы не использовать C для этих целей? гораздо удобнее, чем асм.

> Ну тут вам виднее. С С# знаком весьма поверхностно

тогда зачем делать громкие заявления? )

> эт стандартный ответ такой, когда не знаешь что ответить?
> )

Я на него уже отвечал. Если вы не умеете читать - это сугубо ваши проблемы.

> credentialprovider.h

No comments. Действительно сказать нечего. утерли мне нос. Поздравляю.

> ну начинается снова ) обсуждали здесь это и не раз. домыслы
> всё это, а взять и потестировать с секундомером видать религия
> не позволяет... даже спорить не хочется.

Зачем секундомер? :))
Банальная логика.

Вы в курсе, что при исопльзовании формы зачастую параметры обнуляются и устанавливаются в дефолтные значения просто чтобы не дай бог тупой юзер не забыл сделать этого сам и не вызвал таким образом непредсказуемый результат? В АПИ окне я это спокойно пропускаю, потому что наю где и когда значения должны меняться.

Вы в курсе что переход по указателям требует времени?
А что есть функция события? Правильно указатель. А там этих указателей вагон, поскольку куча классов и родителя не найти.

Вы в курсе, что вызов функции требует времени и выделения памяти?
Вы все еще не видете преимущества вызова API функции напрямую вызову через кучу оберточных интерфейсов?

Вы все еще считаете, что АПИ окна работает не быстрее чем VCL? :))

> далеко не понятно! это полностью меняет суть вопроса! для
> программирования под виндовс C++ - умерающий язык. C же
> активно используется при написании драйверов.

Угую. Скажите это тем 70% контор, которые пишут на С++.
Если для вас логично что я предожил переход на С, вместо С++...
Ну чтож.. у вас проблемы с логикой.....

> почему бы не использовать C для этих целей? гораздо удобнее,
> чем асм.

Хм... Ну и на С также писать ассемблерный код....
SSE3 еще не описан в хедерах Студии...
Хотя может в 8, надо проверить.
А вообще причины по которым использую дельфи - сильно за гранью вопроса.

> тогда зачем делать громкие заявления? )

Какие заявления? О том, что на РНР нельзя делать такой изврат как на С#?
Вы не согласны?

ИМХО беседа беспонтовая, так и до оскорбления друг друга скатимся. Не вижу в этом смысла. Соответственно в продолжении беседы тоже.
Удачи.

так что все-же работает быстреее?)))

> [38] @!!ex © (12.01.07 21:38)

> Зачем секундомер? :))

затем что это позволит увидеть реальную картину, а не домыслы.

> Вы в курсе что переход по указателям требует времени?
> А что есть функция события? Правильно указатель. А там этих
> указателей вагон, поскольку куча классов и родителя не найти.

ну есть лишние переходы по сравнению с API... для современных компьютеров это ничтожная цифра. поверь на глаз будет незаметна задержка в работе от вызова 5 или даже 100 виртуальных методов или переходов по указателю :))

> Вы все еще не видете преимущества вызова API функции напрямую
> вызову через кучу оберточных интерфейсов?

опять же, о какой куче речь? зачастую всё ограничевается вызовом одного метода.

> Угую. Скажите это тем 70% контор, которые пишут на С++.

откуда такая цифра? большинство пишет на VB.
новые же проекты повально начинают на .NET ориентированных языках. хотя тут можно поспорить.

> No comments. Действительно сказать нечего. утерли мне нос.
> Поздравляю.

могу еще таких много в пример привести, с ф-циями, которых нет у windows.pas ))

> Вы все еще считаете, что АПИ окна работает не быстрее чем
> VCL?

окна - они везде одинаковые, не бывает понятия "VCL окно". Но зачастую использование VCL оптимальнее, т.к. потебляет меньше системных ресурсов, к примеру, в приложении с очень развитым туллбаром.

> Хм... Ну и на С также писать ассемблерный код....

зачем?

> SSE3 еще не описан в хедерах Студии...

при чём тут хеадеры? )
есть интелавский C-компилятор, который поддерживает SSE3.

> О том, что на РНР нельзя делать такой изврат как на С#?
> Вы не согласны?

не согласен.

> [39] kaZaNoVa © (12.01.07 21:47)

вот хорошо подметил ) а выяснить это можно только с помощью секундомера.

я еще могу согласиться, что VCL программа стартует дольше, чем на чистом API, но то, что она работает медленно.. секундомер.. только секундомер спасет ОРД :))

API Найти похожие ветки