Подскажите, пожалуйста, как определить группу нарисованных прямоугольников (их координаты известны, левый верхний угол и правый нижний) в прямоугольнике?

Как, у Вас, здесь:

До сих пор я мог определять только точку в прямоугольнике. Специальным элементом.

login, "Элементарно, Ватсон!" :из всех известных левых верхних берём МИНИМАЛЬНЫЕ значения верх и МИНИМАЛНЫЕ значения лево -- это и будет левый верхний угол, из правых нижних МАКСИМАЛЬНЫЕ -- правый нижний угол

Леонид, Вашу мысль я понял. Но еще не уверен.

То-есть если последовательно:

1. юзер нарисовал мышкой прямоугольник(рамку) и я знаю ее координаты.
2. в прямоугольнике оказались несколько обьектов.
3. Я перебираю все свои обьекты сравнивая их с левой верхней координатой рамки юзера и отбрасываю все, которые выше и левее.
Потом сравниваю все правые нижние координаты, всех моих обьектов, и отбрасываю все, что ниже и правее, нижнего правого угла рамки юзера.
4. Все, что осталось после этого - это то, что выбрал юзер?
------------ Дoбавленo в 23.01:
После такой операции выберется этот обьект? Нужно, чтобы выбралось всё, что рамка, хоть немного, зацепила.

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

1nd1g0, юзер выберет обьект не задев ниодин из углов, тогда как?
(у меня, как-раз, обьекты - длинные полоски, их часто будут через серединку выбирать)

[offtop]-cut-[/offtop]

Дайте угадаю: полоски выравниваются по вертикали с определённым шагом, примерно равным их высоте, а по горизонтали - с шагом минимальных долей, так же отображаемых определённым фиксированным числом точек. Так вот что Вам мешает округлять все используемые в навигации координаты до ближайших "клеточек"? Делите нацело Y на шаг по вертикали, X - по горизонтали, получите относительный номер линии и доли в этой линии, на которую приходятся координаты (такое "округление" позволит рассматривать "полоски" как одномерные отрезки с выравненными по "клеткам" координатами начала и конца). В случае "полосок" достаточно отбирать те, что совпали по номеру линии (попали между границами рамки по вертикали), потом те, номер конечной иили начальной долей которых попадает в пределы, ограниченные рамкой. В зависимости от способа округления - в большую, в меньшую сторону, отбросом дробной части и т.п., меняется точность выбора рамкой, хотя имеет смысл рамку жёстко привязать к "клеткам" для наглядности (меньше ресурсов) либо подсвечивать "полоски" по мере выбора (больше ресурсов).

1nd1g0, спасибо. Действительно, можно так сделать. И я об этом думал. Но это не так просто, у меня не дискретный игрик, у каждой полоски свой размер в пикселях.

Есть только дискретный X. Если придумаю как определять с какого трека по какой сделан выбор, то получится этот вариант.
------------ Дoбавленo в 09.30:
[offtop]Просто это как-то неожиданно, мне казалось есть какие-то формулы.
Мне кажется мы даже в школе решали, на геометрии, задачки - "определить, пересекаются ли две плоскости, по их координатам". Математически! Не видя этих плоскостей в упор! И я подумал тут тоже мат персер сможет посчитать, без перебора массивов и обьектов. [/offtop]

Это не пересечение плоскостей, это именно попадание координат в определённые рамки, делается именно логикой, которую, конечно, можно превратить в формулу для MathParse (что я чаще всего и делаю, т.к. относительно сложные логические конструкции на HiAsm делать очень, очень не удобно и они получаются громоздкими). Тут Вам светит неминуемый перебор всех отрезков из поля видимости с четырьмя проверками на каждый - не выше ли, не ниже ли, не левее ли, ни правее ли самая нижняя, самая верхняя, самая правая и самая левая координаты полоски соответственно. Так как X у вас дискретный, то там применяем округление, Y у вас тоже, судя по картинке, имеет шаг, кратный шагу по X. Кстати, а как вы область видимости ограничиваете, или отрисовываете всё, не зависимо от того, попадает оно в "кадр" или нет? Просто это, по сути, та же самая задача, что и с выделением рамкой, можно использовать один, универсальный модуль.

- упал под стол, встал, снова упал
нет, там шаг в пикселях. Юзер сможет изменять размер, по Y мышкой.
отрисовываю всё поле, в процессе, прибавляю ко всем координатам всех обьектов смещения(отрицательные и положительные) эти смещения приходят от ползунков, поэтому можно видеть только нужную область, остальное за кадром.

Если в цепи нет логики, отбрасывающей без отрисовки того, что за пределами области видимости а то и всего экрана, то на слабых машинах при огромном поле возможны очень серьёзные тормоза. На вскидку не помню, достаточно ли умный GDI чтобы автоматом отбрасывать то, что не попадает в рамку контекста отображения, надо уточнить...

Есть ещё вариант работы с выравненными с определённым шагом по обеим осям элементами - теневой буфер (массив) клеточек, которые очищаются и заполняются при отрисовке на реальном экране маркерами, точно указывающими какой именно блок паттерна перекрыл эту клетку. Таким образом нужно просканировать участок массива, попавший в рамку и собрать коллекцию указателей на паттерны ("полоски"), которые в него (участок) попали.

ага, вроде понял. В моём случае, мне надо отрисовать невидимые горизонтальные полоски - прямоугольники, на всю длину поля. Тогда я смогу определить дискретность по Y.

Я делал тесты с несколькими сотнями обьектов, тормозов нет, всё "летает", ощущение, как будто он отбрасывает то, что не видно.

login, ваши "полоски" чисто графические (Img_Rectangle в PaintBox, например), или являются объектами оконного менеджера (формами, панелями и т.п.)

[flood]любые обьекты это: Img_Rectangle + Img_Line в PaintBox[/flood]

login, а какая структура данных используется для хранения координат и размеров?