Не могу добится определённости по сабж. Функции типа GetWindowRect, GetClientRect - возращают координаты в RECT и вот пиксели по обеим этим координатам принадлежат объекту или одна пара да а другая нет? Поясню на примере допустим мне нужно вычислить ширину используя координаты возвращённые в RECT, я должен их вычислять как RECT.right - RECT.left + 1 (как в случае если пиксели по обеим координатам принадлежат прямоугольнику) RECT.right - RECT.left (как в случае если пиксель по одной координате принадлежит а по другой - нет) или как RECT.right - RECT.left - 1 (как в случае если обе пары координат указывают на не принадлежащие "граничные" пиксели)
The Svin Хороший вопрос. А разве нельзя его проверить? 1. Выставить окна по координатам. 2. Взять RECT и сравнить.
Второе. Проверка: Наводим Spy на тестовое окно и получаем Код (Text): (315,240)-(709,478) 394x238 PrintScreen и считаем пиксели в Paint - тоже 394x238
Edmond вернее уточню. Взять 2 окна. По соседним координатам. Чтобы было видно - как они перекрылись или не перекрылись. Я думаю идея понятна.
The Svin, ответы на такие вопросы следует искать в книге всех времён и народов "Programming Windows" дедушки Charles Petzold. По ходу дела, для GetClientRect, RECT.top и RECT.left всегда равны 0. Остальное в книге. Если не читал, ОЧЕНЬ рекомендую. Лучше всего издание 1998 года (есть с chm) или 1995 (есть по русски в pdf). В конце концов, можно создать окно 2x2 и побаловаться с ним.
Four-F Ну дык я понял что ты читал и ответ знаешь. Я когда то Петзольда читал и разные издания, найти ответ на это без знания страницы вероятность убить пару часов. То что возвращается 0,0 для GetClientRect вещь как раз которая очень хорошо помнится. Но она на вопрос не отвечает, это больше относится и релейтивности порядковых чисел в координатах относительно чего-нить. Тут вопрос о принадлежности, будь она релейтивность в координатах относительно самой себя как в GetClientRect, будь относительно скриновых координат или парентовских координат, вопрос то в том - принадлежат или не принадлежат координаты возвращённые в RECT, и какие из них да\не принадлежат. Quantum Вот у меня тоже подозрение на второе по наблюдениям, но тогда возникает вопрос - какая из пар координат включённая а какая выключенная? Edmond Ну дык если не жаль времени было б на эмпирику я б и не спрашивал. Потом, после внимательного чтения мутной документации у меня вообще тревожное чувство что это может быть сделано по разному в разных ОС. У меня были уже грустные наблюдения когда пытался сделать "быстро и красиво" различные штучки в Win - то то что алайнилось в одной ОС начинало глючить или "нализая" или "отваливаясь" от предпологаемого места. Причём в правильности "геометрической модели" которая делала это - я уверен, но эта модель основывается как каких-то постулатах - например, принадлежат или нет координаты пикселям входящим в RECT если в одной ОС это сделано так а в другой иначе то модель будет работать только в какой-то одной. Или иначе "быстро, правильно и красиво" с поддержкой всех ОС не сделать. Ну и исправлялось это такими "тяжёлыми и некрасивыми методами" что просто тошно что-то качественно писать для манипуляций с GUI. Просто надеялся что кто-то уже предельно разобрался в вопросе, и в виде коротенькой монографии может это изложить.
том 1, стр.112 мне попалась такая фраза: "Функция FillRect закрашивает прямоугольник (не включая правую и нижнюю координаты) заданной кистью." время поиска 1 минута, может там где-нибудь и ещё есть тоже самое в ремарках к описанию структуры RECT: "When RECT is passed to the FillRect function, the rectangle is filled up to, but not including, the right column and bottom row of pixels. This structure is identical to the RECTL structure."
То есть есть косвенное указание что возможно и то что сообщается в RECT то же имеет ввиду что правая нижняя это + 1 к крайней принадлежащей. В WinNT подтверждается наблюдениями. Да ладно прикалываться Я и так не часто спрашиваю, больше рассказываю
GetWindowRect: Ширина окна = rc.right - rc.left Высота окна = rc.bottom - rc.top GetClientRect: Ширина клиентской области окна = rc.right - rc.left или лучше rc.right Высота клиентской области окна = rc.bottom - rc.top или лучше rc.bottom rc.left, rc.top принадлежит rc.right, rc.bottom не принадлежит
Asterix Вот на английском кстати точнее написано. А то из русского текста можно понять что речь идёт об одном пикселе. Four-F Угу, так вроде и получается. Спасибо.
Я же пояснил следующим предложением :/ В одном случае написано о координате объекта (русском) в другом об объекте(ах). Координата - это типа адреса, а пиксели (строки и столбцы в английском варианте) - сами объекты. Вообще неправильно составленное предложение, включаются или не включаются не координаты а объекты по ним. Это мы такие догадливые что можем довольно точно предположить что закрашиваются пиксели а не координаты. Далее - ну допустим ты догадался что речь о пикселях а не координатах. Но предположим понятия не имеешь что такое прямоугольник в дискретном изображении (по крайней мере круг в дискретном изображении пикселями вовсе не круг в понятиях классической геометрии - он только глазу таким кажется) Как ты поймёшь что за объект "не включён" по указанной координате? Я же написал - можно подумать что речь идёт об одном пикселе а не крайнем правом столбце и нижней строке. Так что русское: совсем не то что английское:
Ничё не понимаю, при чём тут относительно чего координаты? Вопрос то что включается\не включается по этим координатам. Когда говорится о "нижней координате" - имеется ввиду пара координат т.е. координата точки (в дискретном смысле - пикселя) а не включается не точка а целые колонки и ряды. Я повторяю что это мы просто понимаем (догадываемся) а из текста не понятно то что на языке логике бы звучало как не включаются _all pixels(x,y) x=rect.right | y=rect.bottom Это подразумевалось, но сам текст "не включая нижнюю координату" об этом точно не говорит.
Дык уже вопрос решён. Из английского текста приведённого Asterix и исчерпывающих комментариев Four-F. Конечно можно опытным путём определить, но мне кажется вообще ненормальным когда "открытую" информацию описанную просто кривым способом приходится проверять эмпирикой. У меня уже и так скорбное наблюдение - порой освоить программинг полностью до того незнакого микроконтроллера получается быстрее чем понять что как работает та или иная Win API, которая вообще-то деклорируется как созданная чтоб облегчить мне жизнь.
Интересна история этого момента, кстати... Этот один пиксель постоянно вызывает дополнительный инкремент или декремент (а в конце 80-х CPU были не такие быстрые), который совсем не нужен, если принять, что правая и нижняя стороны не входят в рисуемый объект. Так, что все функции возвращающие RECT имеют это ввиду. Или например, надо поставить два контрольных окна в точности рядом, чтобы они в точности вписывались в ширину родительского окна. left второго окна в точности равен right первого окна. Сумма ширины - в точности равна ширине клиентской области родителя. Если попробовать то же самое, но с учётом, что right и bottom находятся на последних пикселях окон - получим море операций +/- 1 с тем же конечным результатом.
AsmGuru62 Это проще (в смысле избегания лишней путаницы и более интуитивно понятно) можно было избежать приняв формат верхние координаты, ширина, высота. Такие которые к примеру используются в MoveWindow. Когда "включённость неравна" (мы с Яном называем это - сумма скобок = 0, квадратная скобка принимается за +0,5 а кругла -0,5 форма скобок как принято обозначает включённость или невключённость) то действительно можно одним вычитанием определить размер, но "неравна" может предпологать либо верхнюю либо нижнюю пару невключённой, т.е. существуют варианты, которые отствуют когда просто указываешь одну пару и ширину с высотой.
