Указатель

← →
KSergey © (2004-10-01 11:17) [40]

Короче, ответов надавали кучу. Угомонись, а то добром это не кончится

← →
Turbid © (2004-10-01 12:58) [41]

Удалено модератором
Примечание: Вести себя в обществе научись

← →
Comp © (2004-10-01 13:19) [42]

Точнее, это моё сообщение.

← →
Comp © (2004-10-01 13:33) [43]

Удалено модератором
Примечание: Вести себя в обществе научись

← →
Comp © (2004-10-01 13:39) [44]

KSergey © (01.10.04 11:17) [40]

ПОКАЖИ МНЕ ЭТУ "КУЧУ" ?

Из под тишка что-то делать проще...

(Это я по поводу модераторства.)

← →
Digitman © (2004-10-01 13:45) [45]

> Comp © (01.10.04 13:33) [43]

а вот "говорить" в верхнем регистре - моветон, тем самым ты демонстрируешь крик и сотрясание воздуха, что есть демонстрация явного неуважения к окружающим

> ПОТОМУ ЧТО ВСЕ, КТО УЖЕ ДОЛГО ПРОГРАММИРУЮТ НА АПИ - ПОЧТИ
> ВСЕ ПРОГРАММИРУЮТ С ПОМОЩЬЮ КЛАССОВ

правильно.
и начни перечень этих "всех" с самого Борланда - функциональность оконной подсистемы Windows инкапсулирована им в классе TWinControl, текст этого класса - у тебя перед носом, но ты до сих пор не удосужился взглянуть в него, предпочтя вместо этого флудить о "настоящих" и "ненастоящих" мастерах.

← →
Digitman © (2004-10-01 13:58) [46]

> Comp © (01.10.04 13:39) [44]

если тебе этой "кучи" не достаточно, то "до кучи" диктую Большими Буквами :

- модуль Forms, класс TCustomForm, метод CreateWnd
- модуль Forms, класс TApplication, метод CreateHandle;
- модуль Forms, ф-ция AllocateHWnd

вдумчивое изучение текста упомянутых п/программ дает полное понимание, как делать "правильно"

← →
KSergey © (2004-10-01 14:17) [47]

> [44] Comp © (01.10.04 13:39)
> ПОКАЖИ МНЕ ЭТУ "КУЧУ" ?

Чукча не читатель, чукча писатель...

← →
Суслик © (2004-10-01 14:18) [48]

Хватит оскорблений.
Лучше забить - информация получена, думаю должна быть понята.
Пусть разбирается.

← →
Mystic © (2004-10-01 15:03) [49]

У API больше (НАМНОГО) возможностей.

Почти все возможности API доступны из Delphi.

//<--- ОШИБКА ТУТ - "Требуется переменная"

Небольшой совет. Перед тем, как заниматься реализацией библиотеки подобного уровня, необходимо досконально выучить реализацию классов на Delphi, что бы такие вопросы не возникали принципиально. В противном случае идея обречена на провал. Во вторых, некоторые особенности работы с WinAPI в VCL обернуты на уровне языка (зарезервированное слово message). Т. е. в любом случае при попытке реализовать свою ООП-библиотеку у тебя будет больше ограничений, чем у разработчиков VCL :)

Но мне надо её оставить именно внутри класса, как метод.
А зачем? Ты не замечаешь проблемы и хочешь, чтобы она решилась сама собой. Так не бывает.

← →
[lamer]Barmaglot © (2004-10-01 15:12) [50]

to Mystic © (01.10.04 15:03) [49]

Почти все возможности API доступны из Delphi.

и

некоторые особенности работы с WinAPI в VCL обернуты на уровне языка (зарезервированное слово message). Т. е. в любом случае при попытке реализовать свою ООП-библиотеку у тебя будет больше ограничений, чем у разработчиков VCL

противоречит друг другу...

P.S. Поверь моему опыту на WINAPI возможностей гораздо больше...

← →
Суслик © (2004-10-01 15:29) [51]

> P.S. Поверь моему опыту на WINAPI возможностей гораздо больше...

Что такое возможность?
Для кого-то возможность языка - это за 3 месяца работы поехать на канары отдыхать на заработанные от написания 300 форм и 400 диалогов + 23999 контролов. Для кого-то exe размером 16 байт (шучу) предел мечтаний - как сделает сразу памятник себе поставит.

Возможноть, возможности рознь. Всему свое место и время.

← →
Игорь Шевченко © (2004-10-01 15:35) [52]

[lamer]Barmaglot © (01.10.04 15:12) [50]

> P.S. Поверь моему опыту на WINAPI возможностей гораздо больше...

Поверь и моему опыту - возможности одинаковы, а трудозатрат при программировании без VCL граздо больше.

← →
[lamer]Barmaglot © (2004-10-01 16:21) [53]

то Игорь Шевченко © (01.10.04 15:35) [52]

Итак Вы в своих программах используете только VCL? На более низкий уровень никогда не опускаетесь? Тогда ответьте на вопрос зачем Вам справка на WinAPI? Platform SDK и т.д.? Или все таки VCL для работы не очень-то хватает?

← →
Суслик © (2004-10-01 16:29) [54]

> Или все таки VCL для работы не очень-то хватает

Зачем подменять понятия?
Сначала говорили про возможности, теперь про недостатки.

Если действовать в том же ключе, то позвольте и мне задать вопрос:
Зачем придумали VCL, или winapi для работы не очень-то хватает?

← →
Игорь Шевченко © (2004-10-01 16:30) [55]

[lamer]Barmaglot © (01.10.04 16:21) [53]

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

← →
KSergey © (2004-10-01 16:32) [56]

> [53] [lamer]Barmaglot © (01.10.04 16:21)

Вы невнимательно читаете.

← →
[lamer]Barmaglot © (2004-10-01 16:37) [57]

Суслик © (01.10.04 16:29) [54]

Если действовать в том же ключе, то позвольте и мне задать вопрос:
Зачем придумали VCL, или winapi для работы не очень-то хватает?
VCL придумали для быстрого создание СТАНДАРТНЫХ приложений, любое отхождение от стандартов подразумевает знание ВинАПИ. То есть возможностей у ВинАПИ действительно больше...

Игорь Шевченко © (01.10.04 16:30) [55]

Учимся внимательно читать - я не утверждал, что в своих программах использовал только VCL
Нет, но вы утверждали, что возможности одинаковые. Поэтому я и спросил, зачем использовать WinAPI если есть VCL?

P.S. Количество компонентов в Дельфи от версии к версии растет, но они все равно не покрывают весь спектр задач... Например Хук в ДЛЛ(часто встречающийся вопрос) на VCL уже реализован?

← →
Игорь Шевченко © (2004-10-01 16:49) [58]

> Нет, но вы утверждали, что возможности одинаковые. Поэтому
> я и спросил, зачем использовать WinAPI если есть VCL?

Я утверждал, что одинаковые возможности при использовании VCL и без ее использования для работы с API-функциями.

← →
Суслик © (2004-10-01 17:24) [59]

Мое имхо, что нужно пользоваться тем, что в данном случае удобней.
ВКЛ поглащает польшую часть потребностей СТАНДАРТНОЙ программы. Почему бы этим не пользоваться?
Да, не круто.
Да, этим же VCL всякие ламеры могут пользоваться и, конечно, не хочется становиться с ними на одной ступеньке.
Но вот в чем незадача, если пойти по "крутому" пути на чистом winapi 2 таких как ты (ты - это не кто-то конкретный, а просто любитель крутизны) не будут стоить одного такого ламерка с книжкой дельфи за 21 день. За день он сможет сделать работы больше, чем ты за неделю. В неделю я вложил еще время тестирования твоей программы на winapi. Ламерка тестировать так не надо - если делать стандартные операции в дельфи, то возможность получить трудновыводимую ошибку меньше, чем на winapi.

Думаю на фразу о ошибках при программировании на winapi многие захотят возразить - типа я не прав, они пишут без ошибок. Конечно, я согласен. А задумайтесь почему вы пишете без ошибок - дело в том, что вы потратили до фига времени на изучение материала. И к тому же обзяательно имеете серьезные наработки в виде классов и пр. Т.е. возможно имеете свой аналог VCL, только существенно более слабый - VCL писал не один человек и не один год.

К чему я это все? Да к тому, что я тоже проходил через этап виртуального пальцегнутия - вот сейчас изучу winapi и буду круче всех писать без VCL. После определенного потраченного времени и некоторых результатов пришел к выводу, что такой подход не оправдывает себя в требуемой мне области (экономические учетные системы) по соотношению цена/качество. Но я не отрицаю, что есть области, где лучше писать на чистом winapi. Вот только есть такая мысль, что если возникла потребность в чистом winapi, может и дельфи на фиг не нужен - может на других языках писать, на vc++, например, благо и примеры все winapi на этом языке. Зачем дельфи?

← →
Игорь Шевченко © (2004-10-01 17:32) [60]

На "чистом" winapi (без VCL) можно писать либо будучи мазохистом, либо консольные/безоконные программы, благо, нужда в таких тоже встречается. В остальных случаях (особенно, учитывая периодически появляющиеся в одноименном форуме вопросы: "как сделать стринггрид/dbgrid на API), это, IMHO, ближе к мазохизму.
Аргумент про размер exeшника, трудности с трафиком для скачивания, и т.д. неубедителен - если нужная вещь, скачают лишний мегабайт невзирая на трафик, а уже место на винчестере сейчас в избытке.

← →
Mike B. © (2004-10-01 17:40) [61]

Помню, когда только появились Винды, одному моему знакомому очень не нравилось писать на API, он считал что сам мог бы "рисовать окошки" гораздо эффективнее, точнее говоря, "круче". Ничего не добившись он стал везде и всюду пропагандировать преимущества ДОС перед Виндоус, так как под ДОС он мог писать так как ему хотелось. Дурью маялся парень примерно с год, пока не пришлось писать реальные проекты. По-видимому, через подобное проходят многие.

← →
False_Delirium © (2004-10-01 17:44) [62]

[lamer]Barmaglot

VCL - инкапсулирующий интерфейс WinAPI, так же(условно говоря) как и WinApi - инкапсулирующий интерфейс для NativeApi.
VCL призван к универсализации и систематизации работы над WinApi. Код VCL прозрачен, структура легко потдаётся реорганизации. Это готовые блоки одного строения, а не тонна кирпичей и ведро цемента.

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

Сказал очевидные вещи.:)

ИМХО Вся проблема в том, что автор ветки не производил переоценку временизатрат в соотношении выполненных работ и полученых денег.

← →
суслик © (2004-10-01 18:06) [63]

> ИМХО Вся проблема в том, что автор ветки не производил переоценку
> временизатрат в соотношении выполненных работ и полученых
> денег.

он же сказал - это его хобби

а в качестве хобби люди статую свободы из пивных крышек делают.

← →
y-soft © (2004-10-01 18:09) [64]

VCL дает возможность решать быстро и с неплохим качеством 99% задач. Для того она и придумана

Но остается еще 1%, где применение VCL - не самое эффективное решение. Причина очевидна - универсальность VCL достигается большой избыточностью кода и урезанием некоторых, не часто необходимых возможностей WinAPI (Бесплатный сыр - только в мышеловке :) )

На чистом WinAPI писать долго и утомительно, отлаживать еще дольше. К тому же необходима соостветствующая квалификация, которой - Увы!- не все обладают :( Но для небольших задач иногда целесообразно

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

P.S. Не сотвори себе кумира

← →
Суслик © (2004-10-01 18:13) [65]

Предлагаю еще кому-нибудь присоединиться к в общем-то очевидным высказываниям.

есть только ощущение, что автору вопроса наши зрелые и взвешанные высказываения до лампочки.

← →
Игорь Шевченко © (2004-10-01 20:43) [66]

y-soft © (01.10.04 18:09) [64]

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

Золотые слова. Только вот насчет "без существенного замедления" я несколько сомневаюсь :) Если в понятие разработки не входит визуальный дизайн, тогда, разумеется, использование легких оболочек не замедляет, а в ряде случае, даже сокращает время разработки. Но если требуется что-то "рисовать", то даже простое использование редактора ресурсов уже неудобно по сравнению с работой в IDE Delphi. Недаром Rapid Application Development :)

← →
y-soft © (2004-10-01 20:56) [67]

>Игорь Шевченко © (01.10.04 20:43) [66]

О визуальном дизайне речи не идет - тут IDE+VCL пожалуй конкурентов нет. Но вот при разработке новых визуальных компонентов для VCL грамотный набор легких классов очень помогает...

Выбор инструментов определяется задачей - ведь об одном говорим :)

← →
Игорь Шевченко © (2004-10-01 21:00) [68]

y-soft © (01.10.04 20:56) [67]

> Выбор инструментов определяется задачей - ведь об одном
> говорим :)

Да, разумеется, я полностью согласен.

to All.
Человек хочет разобраться в написании маленькой и "своей" библиотечки виджетов - "обернуть" своими классами Win API. А вы тут демагогию развели.

Не стыдно глумиться над личными (хобби) интересами?

to Comp.
Посмотрите паттерны проектирования - есть многочисленные примеры реализации визуальных компонентов в виде ООП-обёрток над Native API (можно дойти самостоятельно до уровня вызова простых функций из ООП). В частности, в фундаментальной книжке Гаммы и др. есть небольшой примерчик, сильно отличающийся от принципов, заложенных в VCL, так что VCL - это далеко не шедевр архитектуры и ровняться на неё не стоит, поверьте.

По существу вопроса.
В коде нужна ещё одна сущность - класс-синглетон, который инкапсулирует CallBack-функцию обработки оконных событий в собственном методе (подсказка: функцию или "заглушку" описываете в секции implementation, а вызываете из метода). Его так же можно представить как фабрику визуальных компонентов для всех окон, кнопок и т.д. элементов Одного Окна. В общем, варианты есть, есть интересные и не очень. Но главное, не выносите на божий свет все эти уродские конструкции типа: StyleWnd:Cardinal;ParentWnd:HWND;MenuWnd:HMENU;MenuName:PAnsiChar; HandleAppl:Cardinal;lpParam:Pointer
Их, по-возможности, нужно скрыть, представить в удобоваримом человеческом виде (если действительно нужно сделать акцент), сделать "обёртки", которые будут понятны даже ребёнку. Упрощайте интерфейс, стремясь к "ортогональности функционала", о котором говорит Эндрю Таненбаум, и к Вам потянутся...

iZEN © (01.10.04 22:44) [69]

Я могу повторить еще раз, что изобретением велосипедов лучше заниматься для самообразования. К тому же, многие проблемы можно решить, имея под рукой неплохой уже изобретенный велосипед - VCL.

> так что VCL - это далеко не шедевр архитектуры и ровняться
> на неё не стоит

С этого момента несклько подробнее можно ? Почему не стоит ?

/**Игорь Шевченко © (01.10.04 22:49) [70]
> так что VCL - это далеко не шедевр архитектуры и ровняться
> на неё не стоит
С этого момента несклько подробнее можно ? Почему не стоит ?
*/
С того самого момента, когда были добавлены свойства докирования (и не только) к оконным компонентам в "обход" принципов ООП: просто взяли и добавили методом Copy/Paste. Пришлось переделывать в VCL очень многое. Этому посвящено много дискуссий.

/**Игорь Шевченко © (01.10.04 23:14) [72]
iZEN © (01.10.04 23:06) [71]
> Этому посвящено много дискуссий
Ссылочку, если не трудно ?
*/
Например на RSDN.ru эта тема активно муссировалась в 2001..2002 гг.. Поиск по сайту даст многое.

iZEN © (01.10.04 23:23) [73]

Я так понимаю, что ради установления истины тебя не затруднит произвести тот самый поиск и дать ссылочки ?

http://rsdn.ru/Forum/Message.aspx?mid=79585

http://rsdn.ru/Forum/Message.aspx?mid=662631

http://rsdn.ru/Forum/Message.aspx?mid=662631
Григорий Поваров
Дата: 02.06.04 10:48

XSH>Так вот медленно и постепенно приходит осознание, что в процессе создания Delphi местами были задействованы, как бы так помягче... не очень профессиональные люди. Нет сами концепции и задумки - хороши. Вот только, на сколько мне известно, эти концепции немножко не Борланда ;)

XSH>Каждый раз когда мне приходится поглядывать на код родных компонентов и библиотек, на ум приходят не очень лестные слова о разработчиках этих самых библиотек ;) Причем проблеммы не с тем, что код грязный и непонятный - код вполне сносный - а именно с тем, как все это местами коряво спроектировано. (Чего стоит только наличие свойства Alignment у класса TField %)

Значит так. По-моему мнению, в свое время создание VCL явилось значительной и очень важной работой, объем которой был очень велик. Думаю, что у Borland просто не хватило средств (или желания) на достаточное количество грамотных разработчиков. Поэтому хотя в целом дизайн не плох и есть значительное количество удачных решений, отдельные решения явно смущают. М.б. также не хватает единой идеологии и некоторого фундаментального Framework"a. Но, еще раз повторю, в свое время VCL явилась революцией. Сейчас MS со своим .net идет по этому пути. Хочется надеятся, что там проблем с дизайном будет значительно меньше, средств наверное хватает. Однако качество получающегося я лично пока оценить не могу.

iZEN © (02.10.04 00:52) [75]

Благодарю. Я предпочитаю выслушивать аргументы Тейксейры, Пачеко, Peter Below и иже с ними.

А вести диалог на уровне:

> что в процессе создания Delphi местами были задействованы,
> как бы так помягче... не очень профессиональные люди

Мне как-то ни к чему - ну считает так человек - путь это будут его проблемы.

/**Игорь Шевченко © (04.10.04 11:05) [78]
А вести диалог на уровне:

> что в процессе создания Delphi местами были задействованы,
> как бы так помягче... не очень профессиональные люди

Мне как-то ни к чему - ну считает так человек - путь это будут его проблемы.
*/
Вот как раз из-за такого эт тема была размещена в разделе "Священные войны".

Что могу сказать от себя.
VCL слабо подготовлена (именно подготовлена) к дальнейшему расширению. А это значит, что VCL - библиотека для "разовых" проектов, которые не будут развивать свой "внешний вид" (GUI) в будущем (или будут, но уже используя другие библиотеки).

При переходе из Delphi3 в Delphi4 в VCL просто добавили методом редактирования исходников модные графические штучки (докирование прежде всего), ничего кардинально не меняя в самой идеологии. Если бы изначально VCL имела правильную архитектуру, все эти модные фишки могли бы просто быть надстройкой над ядром VCL без переписывания исходников - как Sun JFC/Swing над AWT (хотя AWT создавалась одним человеком в течение 1.5-2 месяцев без расчёта на расширение, тем не менее всё сложилось более менее удачно).

Что имеем (моё личное мнение).
Следствием недостаточной продуманной идеологии архитектуры VCL имеем массу "кликальщиков", которые смешивают в одном модуле код, отвечающий за обработку данных, с кодом, отвечающим за действия пользователя и отображение данных. Они даже не задумываются о последствиях своих действий, так как просто не представляют и не ждут иного поведения от своего, с позволения сказать, "творчества". Когда проект распухает до 10-30 форм многие сходят с ума (в переносном смысле) или приобретают качества суперпрограммистов на Delphi. ;)

> Следствием недостаточной продуманной идеологии архитектуры
> VCL имеем массу "кликальщиков", которые смешивают в одном
> модуле код, отвечающий за обработку данных, с кодом, отвечающим
> за действия пользователя и отображение данных. Они даже
> не задумываются о последствиях своих действий, так как просто
> не представляют и не ждут иного поведения от своего, с позволения
> сказать, "творчества".

идеология архитектуры VCL здесь ни с какой стороны не при чем.
Delphi позиционируется как RAD, первая буква значит Rapid.

> VCL слабо подготовлена (именно подготовлена) к дальнейшему
> расширению.

А ее надо расширять ? Где именно ?

> Когда проект распухает до 10-30 форм многие сходят с ума
> (в переносном смысле) или приобретают качества суперпрограммистов
> на Delphi. ;)

Странно. Не слишком ли рано говорить за всех ?

> VCL - библиотека для "разовых" проектов, которые не будут
> развивать свой "внешний вид" (GUI) в будущем (или будут,
> но уже используя другие библиотеки).

Что подразумевается под "развитием внешнего вида" ?

Указатель Найти похожие ветки