freepascal.ru

В общем тема не новая, вот решил таки озвучить.
Может кто то знает разумное объяснение почему в Lazarus размер формы равен размеру клиентской части?

Вот сравнение показаний Width\Height с ClientWidth\ClientHeight в Lazarus и Delphi



Это по моему очевидный баг. Но раз он такой очевидный может это фича?

.wOvAN писал(а):В общем тема не новая, вот решил таки озвучить.
Это по моему очевидный баг. Но раз он такой очевидный может это фича?

Это не баг, а жертва кроссплатформенности. Если в Windows ты длину границы вычислить сможешь, то в Linux - нет...

А как на счет {$ifdef linux} ? Зачем издеваться над всеми. Получается за что не возьмись, даже элементарные свойства и методы, приходится брать напильник.

.wOvAN писал(а):А как на счет {$ifdef linux} ? Зачем издеваться над всеми. Получается за что не возьмись, даже элементарные свойства и методы, приходится брать напильник.

Компилятор должен быть универсальным...

Глупость это, компилятор тут при чем? У линукса дай бог 1% десктопов, ради процента коряжить 99% и наружать саму идею заложенную в код, ширина должна быть шириной и клиентская ширина клиентской.

.wOvAN писал(а):Глупость это, компилятор тут при чем? У линукса дай бог 1% десктопов, ради процента коряжить 99% и наружать саму идею заложенную в код, ширина должна быть шириной и клиентская ширина клиентской.

В общем, сделано это не без умысла... Меня, лично, это не напрягает. Если вас напрягает - идите сюда: http://lazarus.freepascal.org/ на форум - там и говорите...
И, кстати, почему именно "должна быть". Если в Делфях так, то это не значит, что у всех так...

BadBoyAlex писал(а):И, кстати, почему именно "должна быть". Если в Делфях так, то это не значит, что у всех так...

Именно потому что свойства эти разные ClientWidth и Width и отвечают за разные величины.

.wOvAN писал(а):

BadBoyAlex писал(а):И, кстати, почему именно "должна быть". Если в Делфях так, то это не значит, что у всех так...

Именно потому что свойства эти разные ClientWidth и Width и отвечают за разные величины.

ну, отвечают они за разное. Ну и что?

BadBoyAlex писал(а):Ну и что?

Ну и ничего.

.wOvAN писал(а):

BadBoyAlex писал(а):Ну и что?

Ну и ничего.

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

Имхо, стоит создать баг-репорт с указанием, что поведение кода отличается от принятого в Delphi.

Nik писал(а):Имхо, стоит создать баг-репорт с указанием, что поведение кода отличается от принятого в Delphi.

Зачем? Они и так уже знают...

BadBoyAlex писал(а):Зачем? Они и так уже знают...

Верно.
http://bugs.freepascal.org/view.php?id=10420
http://bugs.freepascal.org/view.php?id=1794

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

Эта политика обеспечивает работу принципа "Write once, compile anywhere". Благодаря ему можно для N платформ писать одну, а не N разных программ. Цена этого -- N вариантов библиотеки, причём все они должны работать как можно более единообразно.

.wOvAN писал(а):Логично было бы реализовать максимум доступного функционала под каждую ось а там уж объединять то что можно.

Примерно так и делается. Максимум доступного функционала под каждую ось находится в модулях Windows, BaseUnix и т.п., а то, что должно работать везде -- включается в LCL.

Имхо, конструктивным решением проблемы был бы патч, вычисляющий правильные TForm.Width/TForm.Height под Windows, и добавляющий эти свойства в Restrictions для Qt/GTK/Carbon.
В крайнем случае, можно начать с костыля типа функций GetWindowHeight/GetWindowWidth, под виндой вызывающих WinAPI-функцию GetWindowRect (см. MSDN), а под другими платформами возвращающих ClientHeight/ClientWidth. А потом, под настроение, перенести код в LCL.