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

K_O>Да все-то верно...
K_O>Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством? Допустим такая сложность заставит начинающего программиста разобраться во многих нюансах, но почему я должен снова и снова сталкиваться с этой сложностью, когда мне необходимо в сжатые сроки разработать некоторую программу?
K_O>XXI век на дворе, а я должен тратить время на написание алгоритма сортировки, потому что это повысит мою квалификацию?
K_O>Профессионал обязан иметь в своем распоряжении удобный инструмент, позволяющий быстро и качественно решить поставленную задачу.

Наш выбор — VC++ 7.1! Вся мощь С++ при поддержке WinForms!
Если есть что-то позвляющее решить задачу или быстрее или качественнее — покажите мне это!

РМ>Кроме того дельфи провоцирует знать как можно меньше.

Ну и сказанул. Операционная система,WinApi,С++ тоже провоцирует знать как можно меньше. Они скрывают от тебя комманды процессора, знания железа, например каждую видео и звуковую карты в отдельности .

Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.

> Есть ещё более сложные для восприятия языки. Форт, например.
Все дело в привычки. Сам на нем один раз попробовал и не понравилось. Однако у меня отец от него тащится

> VAS>Это не мало важно, так как в MSDN все описания функций и тогоже ADO приведены в С-шной натации, а большинство примеров написаны на С++.
> VAS>А без умения читать MSDN далеко не уйдёшь.
>
> Умение/неумение читать MSDN — имхо, не зависит от языка программирования.
А зависит от количества языков, которыми владеешь! Шутка. Просто, чтобы читать msdn нужно немного знать английский язык, а по синтаксису языка (даже если его не знаешь) можно догадаться, что там происходит (правда, не всегда).

А, вообще, я с тобой согласен. Delphi — простой способ создания ПО (в принципе любой сложности).

_>Наш выбор — VC++ 7.1! Вся мощь С++ при поддержке WinForms!
_>Если есть что-то позвляющее решить задачу или быстрее или качественнее — покажите мне это!

Да ты и сам догадываешься. На C# писать быстрее.

Здравствуйте, Колобок В бане, Вы писали:

РМ>>Кроме того дельфи провоцирует знать как можно меньше.
КВБ>Ну и сказанул. Операционная система,WinApi,С++ тоже провоцирует знать как можно меньше. Они скрывают от тебя комманды процессора, знания железа, например каждую видео и звуковую карты в отдельности .
Но знание команд процессора, умение программировать на ассемблере помогает лучше программировать на С++. Это очевидно.

КВБ>Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.
Ну насчет гемморойнее — это не правда. Что так пять минут, что эдак. А с приличной библиотекой, так и быстрее, чем на дельфи, и без мышки. Мне лично больше нравится клавиатурой щелкать, чем мышкой дергать, так как в первом случае результат у меня перед глазами, я могу его очевидным образом поправить, переделать и даже отменить совсем, а мышкой подергал, что-то там за кулисами дернулось, а что — не понятно. То есть знатоки конечно знают, но и то не все. Дело вкуса.

Здравствуйте, Рома Мик, Вы писали:

РМ>Здравствуйте, Колобок В бане, Вы писали:

РМ>>>Кроме того дельфи провоцирует знать как можно меньше.
КВБ>>Ну и сказанул. Операционная система,WinApi,С++ тоже провоцирует знать как можно меньше. Они скрывают от тебя комманды процессора, знания железа, например каждую видео и звуковую карты в отдельности .
РМ>Но знание команд процессора, умение программировать на ассемблере помогает лучше программировать на С++. Это очевидно.
Потому что ни С++, ни стандартные библиотеки не предоставляют программисту достаточного минимума функциональности, которой к тому же было бы просто пользоваться. Вот и приходится очень многое писать руками.

КВБ>>Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.
РМ>Ну насчет гемморойнее — это не правда. Что так пять минут, что эдак. А с приличной библиотекой, так и быстрее, чем на дельфи, и без мышки. Мне лично больше нравится клавиатурой щелкать, чем мышкой дергать, так как в первом случае результат у меня перед глазами,
Если я правильно понял, у тебя перед глазами исходный код, а не вид окна. А для программирования GUI второе соврешенно необходимо.
В Delphi мне не надо сидеть пятнадцать минут, ожидая пока соберется проект, лишь для того чтобы увидеть, что вот такой-то контрол надо передвинуть на 3 пикселя влево.

РМ>я могу его очевидным образом поправить, переделать и даже отменить совсем, а мышкой подергал, что-то там за кулисами дернулось, а что — не понятно. То есть знатоки конечно знают, но и то не все. Дело вкуса.
А редактирование кода, сгенерированного автоматически еще никто не отменял. Более того, ты можешь сам в исходнике добавить контролы на форму (+ внести изменения в DFM файл) и это отразится в Дизайнере Формы. Просто это оказывается ненужным.

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

РМ>>Но знание команд процессора, умение программировать на ассемблере помогает лучше программировать на С++. Это очевидно.
K_O>Потому что ни С++, ни стандартные библиотеки не предоставляют программисту достаточного минимума функциональности, которой к тому же было бы просто пользоваться. Вот и приходится очень многое писать руками.
И поэтому тоже, но я имел ввиду гораздо другую вещь. А именно понимание того, что происходит внутри, всегда помогает понимать, как пользоваться тем, что снаружи. Я считаю, что программист СОВСЕМ не умеющий писать на ассемблере — не может писать ничего путного, если задача чуть сложнее хелло ворлд.

КВБ>>>Просто Делфи еще более навороченная среда чем голый API. Весь Api завернут в классы. И это есть правильно, т.к. знания констант и методов создания окна на WInAPI становяться ненужными когда есть класс обертка TForm. Создать окно на WinAPI ничем не умнее чем создать окно на Делфи. Но геморойнее.
РМ>>Ну насчет гемморойнее — это не правда. Что так пять минут, что эдак. А с приличной библиотекой, так и быстрее, чем на дельфи, и без мышки. Мне лично больше нравится клавиатурой щелкать, чем мышкой дергать, так как в первом случае результат у меня перед глазами,
K_O>Если я правильно понял, у тебя перед глазами исходный код, а не вид окна.

K_O>А для программирования GUI второе соврешенно необходимо.
Я в этом не уверен. Это зависит от того, как ты подходишь к его созданию. Мне гораздо ближе не городить всяких сложностей, а сделать как можно проще. Плюс хорошая библиотека помогает очевидным способом организовать всякие сплиттеры.

K_O>В Delphi мне не надо сидеть пятнадцать минут, ожидая пока соберется проект, лишь для того чтобы увидеть, что вот такой-то контрол надо передвинуть на 3 пикселя влево.
Слабо представляю себе ситуацию, когда контрол надо двигать на 3 пикселя влево. То есть совсем не представляю.
Мне кажется, что положение контролов должно определяться получавтоматически, т.е. ты указваешь: вот editbox, вот текст статика к нему, статик пусть будет слева ( или сверху, а больше и не бывает разумных положений ).

РМ>>я могу его очевидным образом поправить, переделать и даже отменить совсем, а мышкой подергал, что-то там за кулисами дернулось, а что — не понятно. То есть знатоки конечно знают, но и то не все. Дело вкуса.
K_O>А редактирование кода, сгенерированного автоматически еще никто не отменял.
Автоматически сгенеренный код — это просто роспись разработчиков библиотеки в том, что они не смогли сделать нормальную библиотеку. К MFC это относится в очень большой степени, в дельфи с этим немного лучше. Так вот, моя идея в том, что с нормальной библиотекой, кода для написания обработчика события надо писать так мало, что мастера вызывать будет в сто раз дольше. Нормальная библиотека, это например модифицированная и доработанная SWL.
Другая моя идея в том, что то, что мастером создано, мастером же должно быть возможно и подредактировать и убрать и т.д. В дельфи с этим кстати не так плохо. А в MFC просто ужасно.
Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.

Да, я совсем не хочу наехать на дельфи, дельфистов, MFC, MFC'истов и вообще кого бы то ни было. Но лично я не считаю это действительно удобными инструментами. Это инструменты, которые просты для новичков, направленные не на эффективность разработки, а на скорость освоения. У меня другие предпочтения.

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

M>А?
Полностью поддерживаю

Здравствуйте, Рома Мик, Вы писали:

РМ>Так вот, моя идея в том, что с нормальной библиотекой, кода для написания обработчика события надо писать так мало, что мастера вызывать будет в сто раз дольше. Нормальная библиотека, это например модифицированная и доработанная SWL.
Так и есть.
РМ>Другая моя идея в том, что то, что мастером создано, мастером же должно быть возможно и подредактировать и убрать и т.д. В дельфи с этим кстати не так плохо. А в MFC просто ужасно.
Согласен. Но мы в данный момент не про MFC — это вообще выдающийся пример бездарного разбазаривания денег Билли.
РМ>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
Вот это просто от непривычки к декларативному программированию. Это противоречит твоей же первой идее, т.к. короче, чем OnCreate=FormCreate ничего не бывает. А это ровно тот код, который необходимо и достаточно написать на Delphi для привязки обработчика. Никто не заставляет тебя поднимать форм дизайнер. Пиши прямо в DFM.

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

K_O>Да все-то верно...
K_O>Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством?
Никто не считает сложность достоинством. Но неумолимый факт говорит о том, что в среду разработчиков на С++, MFC, WinAPI существует достаточно жесткий отбор. Благодаря ему туда попадают лишь сильные духом. А отсутствие барьера в Delphi впускает в программирование совершенно случайных людей. Все. Максимальный уровень разработчика никак не зависит от языка программирования. Но минимальный уровень тащит вниз и средний.

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

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

K_O>>Да все-то верно...
K_O>>Я вот только понять никак не могу, почему профессионалы, считают сложность C++, MFC, WinAPI достоинством?
S>Никто не считает сложность достоинством. Но неумолимый факт говорит о том, что в среду разработчиков на С++, MFC, WinAPI существует достаточно жесткий отбор. Благодаря ему туда попадают лишь сильные духом. А отсутствие барьера в Delphi впускает в программирование совершенно случайных людей. Все. Максимальный уровень разработчика никак не зависит от языка программирования. Но минимальный уровень тащит вниз и средний.
Скорее, Delphi расширяет круг лиц, кому стало доступно программирование. И это есть хорошо.
А число профи от этого не уменьшилось.

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

S>Здравствуйте, Рома Мик, Вы писали:

РМ>>Другая моя идея в том, что то, что мастером создано, мастером же должно быть возможно и подредактировать и убрать и т.д. В дельфи с этим кстати не так плохо. А в MFC просто ужасно.
S>Согласен. Но мы в данный момент не про MFC — это вообще выдающийся пример бездарного разбазаривания денег Билли.
Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную, нельзя мастером, мышкой переназначить обработчик на другое событие и т.д. ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть. Чтобы были отдельные обработчики, которые каждый в своем окне, мышкой их туда-сюда тягать. А так приходится массу всего все равно доделывать руками, что портит впечатление. А на самом деле, если уж пошла такая пьянка, то желательно, чтобы раработчик писал руками только логику, а интерфейс навешивал полностью мышкой вообще не видя при этом генерируемых исходников.

РМ>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
S>Вот это просто от непривычки к декларативному программированию. Это противоречит твоей же первой идее, т.к. короче, чем OnCreate=FormCreate ничего не бывает. А это ровно тот код, который необходимо и достаточно написать на Delphi для привязки обработчика. Никто не заставляет тебя поднимать форм дизайнер. Пиши прямо в DFM.
Бывает. В моей библиотечке по мотивам SWL ( я ей пользуюсь, но еще не доделал до конца многое ) я пишу просто:
MRWL_ON( Message, ClassName, WM_CREATE )
{
...
}
Все. Никаких карт сообщений и прочего. При том, что тащу за собой минимум рантайма. И это реализовано cредствами только языка C++.

Если же взяться за дело масштабно, то есть писать всякие мастера и прочее, то можно достичь супер эффективности и удобства.

S>>Согласен. Но мы в данный момент не про MFC — это вообще выдающийся пример бездарного разбазаривания денег Билли.
РМ>Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную,

Угу , а если закрыть проект, то файлы с диска тоже вручную удалять приходиться.
В VC++ тоже если удалить класс то его методы остануться.

>нельзя мастером, мышкой переназначить обработчик на другое событие и т.д.
Почему нельзя ? Можно. Если это событие совместимо ( объявление обработчиков совпадают ) иначе это теряет смысл.



>> ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть. Чтобы были отдельные обработчики, которые каждый в своем окне, мышкой их туда-сюда тягать.

Ну так ты не листай прокрутку, щелкнул по кнопке — попал в редактор события , отредактировал и выбрал другое событие и т.д. , не трогай прокрутку.


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

А чем это не делфи ? Руками логика пишется а интерфес мышкой царапается.

РМ>>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.

Ну если на то пошло, при использовании сторонних библиотек в C++ тоже придется разбиратся в незнакомой программе — получается ссущий яд.
И это будет сложнее чем понять смысл какого нить Property. Объектное программирование тем и хорошо что наружу выводяться те методы которые необходимы для данного объекта и не видно страшной реализации и как правило принято именовать их понятным образом.Чтобы в названии уже был достаточный хелп. Caption, Length, Width, Heigth, для каждой сущности легко понять что это значит.
По умолчанию считается что этот черный ящик работает корректно. Вот если наблюдаются отклонения от желаемого результата тогда можно и слазать во внутренности. Когда выбираешь телик — не лезешь внуть, просто крутишь ручки , проверяещь "интерфейсы". Как правило лучше не использовать сторонних библиотек, особенно Free написанных васями,
т.к. как правило эти черные ящики очень не надежны. Тоже самое относиться и к C++ библиотекам.


РМ>Если же взяться за дело масштабно, то есть писать всякие мастера и прочее, то можно достичь супер эффективности и удобства.

Угу , и ты удивишся когда у тебя вдруг получится тот же делфи.

Здравствуйте, Рома Мик, Вы писали:

РМ>Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную, нельзя мастером, мышкой переназначить обработчик на другое событие и т.д. ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть.
Идея Delphi не в сокрытии исходных текстов, а в том, что еще до сборки проекта я могу видеть конечный результат.

PM>Чтобы были отдельные обработчики, которые каждый в своем окне, мышкой их туда-сюда тягать. А так приходится массу всего все равно доделывать руками, что портит впечатление. А на самом деле, если уж пошла такая пьянка, то желательно, чтобы раработчик писал руками только логику, а интерфейс навешивал полностью мышкой вообще не видя при этом генерируемых исходников.
Не выйдет. Для создания профессионального пользовательского интерфейса порой приходится прибегать к весьма нетривиальным алгоритмам. А все порой из-за того, чтобы не было какого-то малозаметного подергивания или мерцания.

РМ>>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
А что, было бы лучше, если бы у нас были килобайты setPropertyXXX в исходном коде? Зачем?

S>>Вот это просто от непривычки к декларативному программированию. Это противоречит твоей же первой идее, т.к. короче, чем OnCreate=FormCreate ничего не бывает. А это ровно тот код, который необходимо и достаточно написать на Delphi для привязки обработчика. Никто не заставляет тебя поднимать форм дизайнер. Пиши прямо в DFM.
РМ>Бывает. В моей библиотечке по мотивам SWL ( я ей пользуюсь, но еще не доделал до конца многое ) я пишу просто:
РМ>MRWL_ON( Message, ClassName, WM_CREATE )
РМ>{
РМ> ...
РМ>}
РМ>Все. Никаких карт сообщений и прочего. При том, что тащу за собой минимум рантайма. И это реализовано cредствами только языка C++.
Все это замечательно до тех пор, пока ты пользуешься этой библиотекой один. Потому что ты в ней все знаешь. А для меня, например, абсолютно неясно что означает заклинание MRWL_ON. Что это — макрос, функция, что он(а) делает? Из названия неясно.

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

K_O>Здравствуйте, Рома Мик, Вы писали:

РМ>>Я на самом деле не знаю ни одного радостного средства программирования где все было бы супер с этим вопросом. В дельфи, конечно, можно убрать обработчик события из карты сообщений, но сам обработчик придется удалять вручную, нельзя мастером, мышкой переназначить обработчик на другое событие и т.д. ИМХО если уж делать написание программы в ГУИ, т.е. мышкой, то надо скрывать от разработчика саму парадигму исходных текстов. Не совсем, конечно, а только чтобы ему не было нужно туда лезть.
K_O>Идея Delphi не в сокрытии исходных текстов, а в том, что еще до сборки проекта я могу видеть конечный результат.
Конечный результат можно видеть в любом редакторе ресурсов, хотя идея ресурсов мне тоже не нравится. ИМХО можно сделать интерфейс не описыая отдельно внешний вид, отдельно функционал. А сразу вместе.

K_O>А все порой из-за того, чтобы не было какого-то малозаметного подергивания или мерцания.
Мерцание должно устранятся на этапе разработки библиотеки.

А впрочем о чем это мы тут спорим? Что называется, о вкусах. А о них не спорят. Мое мнение очень простое, взялся — доделай до конца, а от дельфи и ВСЕХ остальных виданных мной радостных средств у меня ощущения недодуманности и недоделанности еще на уровне парадигмы. Но это только мое мнение, в силу которого я, кстати, не слишком знаком с радотью радостного программирования. Так что, что спорить?

K_O>А для меня, например, абсолютно неясно что означает заклинание MRWL_ON. Что это — макрос, функция, что он(а) делает? Из названия неясно.
Вначале было MRWL_ON_MESSAGE, потом стало MRWL_ON( Message ... ). Так как бывает еще Command и Notify. Это макрос, определяющий функцию обработчик и регистрирующий ее в карте сообщений. Таким образом, то, что это сообщение обрабатывается классом, упоминается в ОДНОМ месте, а не в двух и больше как предлагают нам другие товарищи. И удалется, пределывается интуитивно понятным образом, не надо судорожно вспоминать, что еще нужно почистить.

Здравствуйте, Колобок, Вы писали:

К>Ну так ты не листай прокрутку, щелкнул по кнопке — попал в редактор события , отредактировал и выбрал другое событие и т.д. , не трогай прокрутку.
Именно от стиль, которого бы хотелось достичь. Но при условии, что не получаются при этом уродцы жуткие. Или если я ненароком неправильно назвал обработчик? Или вообще случайно не туда щелкнул? Все иддилия нарушается.

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

РМ>>>>Но тем не менее, меня лично в дельфи дико раздражает, что огромная часть программы существует не в виде исходных текстов, а ввиде всяких настроечек и настроек всяких проперти. Разбираться в незнакомой программе, использующей незнакомые контролы получается — сущий ад.
К>Ну если на то пошло, при использовании сторонних библиотек в C++ тоже придется разбиратся в незнакомой программе — получается ссущий яд.
Зависит от сложности библиотеки.

К>Объектное программирование тем и хорошо что наружу выводяться те методы которые необходимы для данного объекта и не видно страшной реализации и как правило принято именовать их понятным образом.
Да, конечно. C++ кстати тоже объектно-ориентированный, ты не в курсе?

РМ>>Если же взяться за дело масштабно, то есть писать всякие мастера и прочее, то можно достичь супер эффективности и удобства.
К>Угу , и ты удивишся когда у тебя вдруг получится тот же делфи.
Ну уж нет. Должно хранится гораздо больше всякой информации. Или, например, исходник ГУЯ не должен быть исходником на паскале, c++ и т.д., т.к. это не позволяет грамотно отобразить всю информацию по возможности компактно.
В дельфи мы создаем кнопку. Создаем к ней обработчик того, сего. Они как-то называются, т.е. уже три независимых сущности, объединенных только шаткими установками проперти. А если я переименую один из них то все рассыпется. Уж если писать тяжелый тул, то тогда пусть кнопка в исходнике формы выглядит так:

Form MyForm "MainForm"
{
    Button MyButton "Батон"
    {
        OnClick()
        {
        }
    }
}

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

А вообще, спорить ту не о чем. Мне кажется, что радостным тулам есть куда совершенствоваться, а пока они не удобны и т.д. Но это просто мне так кажется, я точно не знаю, т.к. не пользуюсь ( потому, что мне так кажется ) этим тулзами.

Здравствуйте, Рома Мик, Вы писали:
РМ>... А если я переименую один из них то все рассыпется. Уж если писать тяжелый тул, то тогда пусть кнопка в исходнике формы выглядит так:
РМ>

РМ>Form MyForm "MainForm"
РМ>{
РМ>    Button MyButton "Батон"
РМ>    {
РМ>        OnClick()
РМ>        {
РМ>        }
РМ>    }
РМ>}
РМ>

РМ>Чтобы все в одном месте и все связи прописны жестко без привязки к именам, чтобы их нельзя было порушить.
на закладке Standart есть такой компонет — TActionList(реализует паттерн Command) , появился кажется еще в Delphi 5.
создаем отдельный датамодуль, кидаем туда этот компонет, добавляем команды ,настраиваем им хинты,caption, пиктограммы
горячие клавиши, раскладываем по категориям. пишем реализацию методов Execute

procedure TDataModule1.ActionSaveFileExecute(Sender: TObject);
begin
 ..
end;

Все в одном месте.

можно создать билиотеку стадартных команд и зарегистрировав в IDE добавлять их в ActionList, есть
около 50 готовых команд (сохранить,скопировать и тд) в различных категориях(Edit,Format,Window,Search,File,List,Dialog и тд).

затем в при создании формы пишем

procedure TForm1.FormCreate(Sender: TObject);
begin
 ButtonSave.Action:=DataModule1.SaveFile;
end;

не хотим в рантайме — делаем в дизайнере,
свойство Action есть практически у всех элеметов управления типа кнопок,толбаров итд.
Чем это отличается от MRWL_ON_MESSAGE, и тд?
Ок, идем дальше. Начиная с Delphi 6 появились фреймы(там же на Standart).
Черезвычайно удобна штука: создаем фрейм, размещаем там элементы управления, связываем их событиями
(например фрейм с dbгридом для редктирования данных,навигаторм и фильтрацией )
затем используем этот фрейм как обычный компонет, без установки его в IDE.
Хотим — вставлям его в другие формы, разделяем между разработчиками,
хотим — работаем как с обычной формой (Frame.ManualFloat())

если грамотно все построить,то ничего не рассыпается

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

D_T>если грамотно все построить,то ничего не рассыпается
Как я уже говорил, я совсем не в курсе последних тенденций в мире дельфи. Имел дело плотно только с дельфи 3. Значит не я один такой умный и все движется к правильному положению вещей. Урра и т.д. и т.п. Убедил, победил, заставил усомнится.
Вот разгружусь чуть-чуть и побегу смотреть на последнюю дельфи. Хотя, конечно, еще не идеал, так как тот не достижим.

Здравствуйте, Рома Мик, Вы писали:

РМ>Бывает. В моей библиотечке по мотивам SWL ( я ей пользуюсь, но еще не доделал до конца многое ) я пишу просто:
РМ>MRWL_ON( Message, ClassName, WM_CREATE )
РМ>{
РМ> ...
РМ>}
РМ>Все. Никаких карт сообщений и прочего. При том, что тащу за собой минимум рантайма. И это реализовано cредствами только языка C++.
В Delphi ты бы написал вот так:
type ClassName = class(BaseClassName)
procedure OnCreate(Message: TMessage); message WM_CREATE;
end;

И все. Никаких карт сообщений и прочего. При том, что для этого даже VCL не требуется — только модуль system. Ну да, в паскале нет синтаксиса определения тела метода в объявлении класса. В остальном все уже сделано.

По поводу примера с кнопкой — все то же самое. Если очень хочется написать код, который гарантирован от повторного использования — пожалуйста, делаем свой класс кнопки, перегружаем WM_CLICK прямо в нем и вставляем в форму.

Здравствуйте, Рома Мик, Вы писали:
РМ>Конечный результат можно видеть в любом редакторе ресурсов, хотя идея ресурсов мне тоже не нравится. ИМХО можно сделать интерфейс не описыая отдельно внешний вид, отдельно функционал. А сразу вместе.
Это неправда. Покажи-ка мне редактор ресурсов, который покажет мне конечный вид формы, использующей 3rd-party контролы? А не те 10 штук, заботливо встроенные на этапе проектирования редактора ресурсов 10 лет назад?