[M1ndAction]

Приветствую!

Как можно обойти проблему максимальных координат элементов в 32767 пикселей? То есть то, что, к примеру, свойство Top элементов управления не может превышать значение в 32767.
В целом, задача следующая. Необходимо выводить данные в табличном виде, много данных Скажем, может быть свыше 2000 строк в таблице. Все эти данные выводятся в таблице, сделанной на базе TStringGrid. В ячейках есть выпадающие списки, радиокнопки. Вот это все, как раз таки, и перестает работать на высотах свыше 32767. Но это все частности, суть, думаю, везде одинаковая.
Насколько я понимаю, необходимо сместить систему координат (примерно, как это происходит при наличии ScrollBar), то есть, чтобы значения, свыше 32767 воспринимались, как меньшие.
В процессе поиска информации по данному вопросу, мне в связи с этим встречалось упоминание процедуры TranslateTransform. Как ее в этом случае можно (и нужно ли вообще) использовать?
Или будут какие другие варианты решения проблемы?
P.S. Проблема эта распространена, часто встречаются обсуждения, но решения я так и не увидел. Другой взгляд на эту проблему (если мне не удалось толком объяснить) можно посмотреть здесь: http://stackoverflow.com/questions/8...767-size-limit и https://social.msdn.microsoft.com/Fo...ntroltop-32767

[Bargest]

"магическое" число 32767 (в двоичной 0111111111111111) есть максимальное значение целого знакового двубайтового. Если большая высота "не работает", то скорее всего где-то в винде используется целый двубайтовый тип для указания высоты. Это так просто не обойти, мне кажется.
Можно попробовать сделать свой компонент, который будет выводить данные частями по мере прокрутки и перерисовывать прямо на месте, тогда такие огромные высоты не понадобятся.
Хотя может в каких-то компонентах эта логика уже реализована, не знаю.

[M1ndAction]

Сообщение от Bargest

"магическое" число 32767 (в двоичной 0111111111111111) есть максимальное значение целого знакового двубайтового. Если большая высота "не работает", то скорее всего где-то в винде используется целый двубайтовый тип для указания высоты. Это так просто не обойти, мне кажется.
Можно попробовать сделать свой компонент, который будет подргужать данные частями по мере прокрутки и обновлять прямо на месте, тогда такие огромные высоты не понадобятся.

Да, совершенно, верно, число непростое Это завязано на сообщениях, где, как раз, этот самый параметр передается как двухбайтовое число, поэтому, все, что больше, обрезается. Это, похоже, еще идет с Windows 9x. Понятно, что в подавляющем большинстве случаев этого достаточно, но бывают и исключения, как раз, как в моей ситуации.

[Bargest]

Ну я в готовых компонентах не силен, потому подождем ответа от кого-нибудь, кто знает о таких компонентах.
Если не будет ответа, можно сделать как я говорил: сделать grid на 2 строки больше, чем область вывода, по положению ScrollBar'а определять номера строк, которые надо подгрузить из массива, и писать их туда, сдвигая grid на нужный коэффициент вверх/вниз для иллюзии плавной прокрутки. По идеи мерцать при отрисовке не должно, особенно с дабл-буфером, хотя не знаю. Делал нечто подобное, когда писал свой memo с подсветкой синтаксиса, только сдвигал на +/- одну строку не само окно отрисовки, а только координаты начала рисования текста.

[Freeman]

Сообщение от M1ndAction

Это завязано на сообщениях, где, как раз, этот самый параметр передается как двухбайтовое число, поэтому, все, что больше, обрезается. Это, похоже, еще идет с Windows 9x.

Как это? Не может этого быть. Именно с Windows 95 WParam имеет размер LongInt, 16-битный WParam остался в Windows 3.x. Название менять не стали.

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

[Bargest]

На МСДН написано, что

Although the width and height of a window are 32-bit values, the lParam parameter contains only the low-order 16 bits of each.

Потому что они пакуют 2 параметра в один 4-байтовый lparam, видимо.

[lmikle]

Посмотри на DevExpress'овский грид. У них полностью кастомная отрисовка и нативная (своя) вставка контролов в ячейки.

[Freeman]

Сообщение от Bargest

Потому что они пакуют 2 параметра в один 4-байтовый lparam, видимо.

На самом деле при перемещении окна отправляется WM_MOVE, но не суть важно, поскольку там тоже упакованные 16-битные X и Y передаются. Так что да, я был неправ.

[M.A.D.M.A.N.]

WinAPI — зло.

[NumLock]

проблема не в том, что для позиционирования элементов не хватает 16 бит, а в самом подходе. вовсе не обязательно создавать элементы для каждой строки. достаточно только для тех, которые в данный момент видимы на экране. естественно, что их позиция не может превышать размеров экрана.

[M1ndAction]

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