Здравствуйте, zaiats_2k, Вы писали:
_>Рисовать не стоит, всё равно у меня Delphi не стоит... Лучше покажи мне, где в Windows Explorer ты нашёл "constraints и прочие радости"?
Ну как же! Task/Places Pane нельзя сресайзить меньше, чем она есть. Поведение TaskBar вообще довольно сложное — там мало того, что для его бандов известны минимальный и максимальный размеры, еще и ограничивается шаг квантования размера (при необходимости). Воспроизвести такую хрень при помощи алигнментов и сплиттеров нельзя.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, zaiats_2k, Вы писали:
_>>Рисовать не стоит, всё равно у меня Delphi не стоит... Лучше покажи мне, где в Windows Explorer ты нашёл "constraints и прочие радости"?
S>Ну как же! Task/Places Pane нельзя сресайзить меньше, чем она есть.

Зато главное окошко можно сресайзить так что только заголовок окна виден будет.

S>Поведение TaskBar вообще довольно сложное — там мало того, что для его бандов известны минимальный и максимальный размеры, еще и ограничивается шаг квантования размера (при необходимости). Воспроизвести такую хрень при помощи алигнментов и сплиттеров нельзя.

TaskBar вещь очень специфическая, воспроизводить его в приложениях... я не знаю зачем это нужно.

Здравствуйте, zaiats_2k, Вы писали:

_>TaskBar вещь очень специфическая, воспроизводить его в приложениях... я не знаю зачем это нужно.
Мы говорим не о том, что нужно в приложениях, а о том, что модель описания layout в VCL внутренне противоречива. Аргумент "а вот это просто не нужно" надо применять с большой осторожностью. Не хотелось бы придумывать ограничения без необходимости.

L>>Почему ты считаешь Anchors, Alignment ужасными?
S>А ты посмотри на поведение формы с достаточно сложной структурой — сплиттерами, фреймами и прочими вещами — при ресайзе с включенным Redraw Window Contents When Resize. Совместно с MinMAxInfo, OnRequestResize и OnSize это сущий кошмар.
S>Весь смысл в том, что с точки зрения архитектуры упраеление взаимным размещением окон в контейнере при помощи свойств самих окон — бред.

Родной! Так фишка же в том, что ты можешь не использовать эти навороты!
Встретился тебе необычный случай — ну реализуй ты Layout ручками...
Главное — что в простых случаях можно быстро и вполне качественно сделать!

Типичный довод противников Delphi — дескать, в сложных случаях, если делать все по книжке — то получается Г... Ну, блин, а вы чего хотели? Это же сложный случай!

Зато простой можно сделать быстро, легко и красиво.

Мне вот например, иногда не хватает в WinForms дельфийских Constraint'ов.

S>Это низводит Object Pascal с возвышения, на котором сидят строго типизированные языки, и вводит в детский манеж, отведенный для всяких скриптовых товарищей типа VB и JScript.

Неверно.
Скрипты так обходятся со ВСЕМИ переменными. А Delphi — строго тпизирован с нормальными данными. А редкий и особый случай с IDIspatch — ну извините, это следует из самой идеологии позднего связывания, что может не найтись такого метода.

Здравствуйте, Igor Trofimov, Вы писали:
iT>Родной! Так фишка же в том, что ты можешь не использовать эти навороты!
iT>Встретился тебе необычный случай — ну реализуй ты Layout ручками...
Фишка в том, родной, что хочется состряпать библиотеку, коя и простые, и сложные случаи эффективно покроет. А то у нас с одной стороны имеется вроде как бы RAD, а с другой — явные пробуксовки модели, как только выйдешь из фолдера Samples. Я=то хочу не рожать кажный раз в муках этот Layout, выписывая километровые TForm1.Form*Size
iT>Главное — что в простых случаях можно быстро и вполне качественно сделать!
iT>Типичный довод противников Delphi — дескать, в сложных случаях, если делать все по книжке — то получается Г... Ну, блин, а вы чего хотели? Это же сложный случай!
Ты бы меня в противники Delphi так бодро не записывал, родной. Я против бездумного поклонения VCL. Ежели б все было так хорошо, то Borland бы остановился еще версий пять назад. Мне не нравится, что библиотека тащит за собой очень много решений, которые применяются из-за совместимости.
iT>Мне вот например, иногда не хватает в WinForms дельфийских Constraint'ов.
список того, чего не хватает в WinForms, можно продолжать очень долго.

S>Фишка в том, родной, что хочется состряпать библиотеку, коя и простые, и сложные случаи эффективно покроет.

Уже видел такое где-нибудь?

S>Я против бездумного поклонения VCL.

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

S>Мне не нравится, что библиотека тащит за собой очень много решений, которые применяются из-за совместимости.

Увы, сама Delphi уже очень много тянет из-за совместимости ;(
СЕЙЧАС бы они VCL написали СОВСЕМ по-другому...

S>список того, чего не хватает в WinForms, можно продолжать очень долго.

Ну давай что-ли Это кстати, действительно интересно — кому чего не хватает в WinForms по сравнению с Delphi. Думаю, всякие TPanel и прочую лабуду верхнего уровня, которые можно написать или найти мы считать не будем. Интересны решения уровнем пониже, то, что встроено в стандартную библиотеку.

Итак?

Согласен. А еще — очень некрасиво выглядит отрисовка (при перемещении каких-либо элементов) в случае, когда одни элементы программно (в виде пользовательцкой реакции на события) привязываются к другим. Дискретность перемещения (и прорисовки) у всех элементов получается различной.

Slicer

Здравствуйте, s.ts, Вы писали:

S>>Хотя наиболее тяжкие преступления разработчиков компилера Delphi даже не были затронуты.

ST>А какие ?

Ну как же! Не знаешь что ли? D6 уделало VC++6 по всем параметрам. Чем не УЖАСНОЕ преступление?

Здравствуйте, dad, Вы писали:

dad>Я лично дельфи не люблю, но от о юзабилити форм оутлука вы зря сказали.. Трудно себе представить более не удобного постового клиента. Я использую зе бат
Надо ж! Как неудачно. THE BAT написан как раз на той самой Delphi.

Здравствуйте, FWP, Вы писали:

FWP>Ну как же! Не знаешь что ли? D6 уделало VC++6 по всем параметрам. Чем не УЖАСНОЕ преступление?
Огласите весь список пожалуйста.

Здравствуйте, s.ts, Вы писали:

ST>перегрузки операторов
Перегрузка операторов есть в фрипаскале , мне он кстати болше нравится чем делфи.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Итак?
Ну, мне интереснее то, чего не хватает в Dephi по сравнению с идеалом Я не так много знаю других библиотек, заточенных как на RAD, так и на расширение.
Я бы в первую очередь переписал концепции Layout. По крайней мере, разделил бы окна на контейнерные окна и примитивные. И оставил бы в примитивных окнах только свойства, отвечающие за их размеры. А взаимное расположение окон вынес бы в контейнерные окна. Тогда сплиттер, как отдельный компонент, просто бы исчез, а вместо него были бы non-client зоны контейнера.

Здравствуйте, sergei74ap, Вы писали:

S>Часто приходится слышать мнение, что разработчики, использующие delphi -
S>ваще не программисты, а так... детишки неразумные.
В основном дело конечно в новичках, которые очень быстро могут слабать на дельфи что-то якобы работающее. Да и не только в новичках, многие люди уже несколько лет на дельфи пишут такуую муть И она работает и продается Только я тут недавно помогал разгребать один такой проект: ну это просто какое-то

Я имел довольно мало дела с дельфи. Но тем не менее успел заметить, что то ли RAD вообще, то ли именно дельфи провоцирует на плохую архитектуру. Без разделения данные/представление, без разбиения на небольшие классы, даже без разбиения на отдельные функции. Куча народу пишет код только в нагенеренных средой функциях.

Кроме того дельфи провоцирует знать как можно меньше. Я знаю человека, который пользуется сокетами из VCL, т.к. считает, что это намного ( очень намного ) проще, чем с нормальными сокетами, а на сами сокеты так и не взглянул.

Дельфи провоцирует делать простое сложным. Например простой график рисовать через TChart ( ну и штука, я тут против воли познакомился недавно ).

S>Ясно, что у нее (как и у каждого ср-ва разработки) есть свои минусы,
S>но и плюсы тоже имеются.
Нормальный программист напишет на дельфи нормально, а не программист напишет как подсказывает среда и у него что-то получится. Это что-то будет кривым и косым, но будет работать. Это плюс или минус? Не знаю. Но точно повод настороженно относиться к программерам на дельфи: а вдруг он и не программер вовсе.

S>И что, об этом лучше никому не говорить?
Ну, работодатели в большинстве своем разумные люди.

Здравствуйте, Igor Trofimov, Вы писали:

Нет уж увольте. к IDispatch это не имеет никакого отношения. Я бы простил, если бы они так обходились с переменными типа IDispatch. Но когда компилируется вот такой код:
var
  A: variant;
begin
  A:= 5;
    A.LateBoundCall(SomeValue).OtherCall;
end;

я считаю это преступлением.

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 09:53:54 GMT:

S> Ну, мне интереснее то, чего не хватает в Dephi по сравнению с идеалом
S> Я не так много знаю других библиотек, заточенных как на RAD, так и на
S> расширение. Я бы в первую очередь переписал концепции Layout. По крайней
S> мере, разделил бы окна на контейнерные окна и примитивные. И оставил бы
S> в примитивных окнах только свойства, отвечающие за их размеры. А
S> взаимное расположение окон вынес бы в контейнерные окна. Тогда сплиттер,
S> как отдельный компонент, просто бы исчез, а вместо него были бы
S> non-client зоны контейнера.


IMHO, за layout отвечать должны отдельные классы, которые вообще не окна. Например так, как это сделано в wxWindows.

Best regards,
Sergey.

Здравствуйте, Sergey, Вы писали:

S>Hello, Sinclair!
S>You wrote on Wed, 22 Oct 2003 09:53:54 GMT:

S>> Ну, мне интереснее то, чего не хватает в Dephi по сравнению с идеалом
S>> Я не так много знаю других библиотек, заточенных как на RAD, так и на
S>> расширение. Я бы в первую очередь переписал концепции Layout. По крайней
S>> мере, разделил бы окна на контейнерные окна и примитивные. И оставил бы
S>> в примитивных окнах только свойства, отвечающие за их размеры. А
S>> взаимное расположение окон вынес бы в контейнерные окна. Тогда сплиттер,
S>> как отдельный компонент, просто бы исчез, а вместо него были бы
S>> non-client зоны контейнера.


S>IMHO, за layout отвечать должны отдельные классы, которые вообще не окна. Например так, как это сделано в wxWindows.

Я только одного не понимаю, кто мешает вам изобрести порох непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема волнует! А мы потом посмотрим что лучше, анкоры или ...

Здравствуйте, Sergey, Вы писали:
S>IMHO, за layout отвечать должны отдельные классы, которые вообще не окна. Например так, как это сделано в wxWindows.
Хм, может быть. Можно немного поподробнее?
Моя проблема в том, что я не понимаю, как это layout может быть оторван от окна.
Вот допустим у нас есть два окна, которые сами уже окон не содержат. Мы хотим расположить их внутри родительского окна, одно слева и одно справа. При этом разделитель между ними должен вести себя как обычный сплиттер. Родительское окно мы можем считать контейнером, который вообще никакой другой функциональности не имеет, кроме как содержать в себе кого-то.
Так вот поведение сплиттера должно реализовываться именно этим контейнерным окном, т.к. только оно и получит сообщения мыши. Это означает, что окно должно быть в курсе того, какой layout используется внутри него.
С другой стороны, объект, который layout, должен как-то взаимодействовать с оконной системой, чтобы реализовывать свое поведение. Как он это будет делать, не являясь окном, мне не совсем понятно.

Hello, Sinclair!
You wrote on Wed, 22 Oct 2003 12:03:43 GMT:

S> Здравствуйте, Sergey, Вы писали:
S>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>> окна. Например так, как это сделано в wxWindows.
S> Хм, может быть. Можно немного поподробнее?
S> Моя проблема в том, что я не понимаю, как это layout может быть оторван
S> от окна. Вот допустим у нас есть два окна, которые сами уже окон не
S> содержат. Мы хотим расположить их внутри родительского окна, одно слева
S> и одно справа. При этом разделитель между ними должен вести себя как
S> обычный сплиттер.

Или не должен вести себя как обычный сплиттер, или вовсе разделителя никакого быть не должно — просто контролы в диалоге при ресайзе должны определенным образом менять свои размеры.

S> Родительское окно мы можем считать контейнером,
S> который вообще никакой другой функциональности не имеет, кроме как
S> содержать в себе кого-то. Так вот поведение сплиттера должно
S> реализовываться именно этим контейнерным окном, т.к. только оно и
S> получит сообщения мыши.

Сплиттер может быть окном и сам получать сообщения мыши, может быть окном и отдавать сообщений родителю, может вообще не быть самостоятельным окном (но выглядеть точно так же) и отрисовываться контейнером. (первый и последний варианты я когда-то делал руками )

S> Это означает, что окно должно быть в курсе того,
S> какой layout используется внутри него.

Конечно. В wxWindows у него мембер такой есть — m_windowSizer. А вот что это за сайзер, оно знать не должно. Что обеспечивает большую гибкость и расширяемость.

S> С другой стороны, объект, который
S> layout, должен как-то взаимодействовать с оконной системой, чтобы
S> реализовывать свое поведение. Как он это будет делать, не являясь окном,
S> мне не совсем понятно.

Посылать сообщения окнам, например. Или напрямую вызывать методы классов, реализующих окна. (что по сути одно и то же). Смысл в том, чтобы это был отдельный объект, который можно менять независимо от окон — тогда реализовать любой нужный пользователю вариант лэйаута можно не ломая существующего кода.

Best regards,
Sergey.

Hello, zaiats_2k!
You wrote on Wed, 22 Oct 2003 11:57:46 GMT:

S>> IMHO, за layout отвечать должны отдельные классы, которые вообще не
S>> окна. Например так, как это сделано в wxWindows.

zk> Я только одного не понимаю, кто мешает вам изобрести порох
zk> непромокаемый!? Ну сядьте и напишите, раз вас так эта проблема волнует!

Написано уже. Но не для Delphi.

zk> А мы потом посмотрим что лучше, анкоры или ...

Валяй, сравнивай.

Best regards,
Sergey.