Указатель

← →
Comp © (2004-10-01 01:36) [0]

Всем привет. Ребята, я решил программирование на API свести к объектно-ориентированному, т.е. с помощью классов. И тут столкнулся с одной неприятной проблемой.
В общем,дело так. Я думаю, все знают алгоритм создания окна на API. Решил же этот алгоритм разбить на методы. Вот например:

type TWindowClass = class WndClassName:TWndClass; HandleWindow:HWND; Caption:PAnsiChar; MenuWindow:HMENU; function WindowProcQ(hWnd,Msg,wParam,lParam:Longint):LongInt; stdcall; constructor Create (ClassName:TWndClass;Caption:PAnsiChar;Rect:Trect; StyleWnd:Cardinal;ParentWnd:HWND;MenuWnd:HMENU;MenuName:PAnsiChar; HandleAppl:Cardinal;lpParam:Pointer); end; implementation constructor TWindowClass.Create(ClassName: TWndClass; Caption: PAnsiChar; Rect: Trect; StyleWnd: Cardinal; ParentWnd: HWND; MenuWnd: HMENU; MenuName: PAnsiChar; HandleAppl: Cardinal; lpParam: Pointer); begin RegisterClass(ClassName); HandleWindow:=CreateWindow( ClassName.lpszClassName,Caption,StyleWnd,Rect.Left,Rect.Top,Rect.Right,Rect.Bottom,ParentWnd,MenuWnd,HandleAppl,lpParam) ; end;

и само использование(тоже к примеру):

type TForm1 = Class(TWindowClass) WndClassName: TWndClass; Menu:HMENU; constructor Create; end; var Form1:TForm1; RectBorder:Trect; function TForm1.WindowProcQ(hWnd,Msg,wParam,lParam:Longint):LongInt; stdcall; begin Result:=DefWindowProc(hWnd,Msg,wParam,lParam); case Msg of WM_COMMAND: ... ; WM_DESTROY: ... ; WM_CREATE: ... ; WM_CONTEXTMENU: ... ; end; end; constructor TForm1.Create; begin RectBorder.Left:=10; RectBorder.Top:= 10; RectBorder.Right:= 700; RectBorder.Bottom:= 500; with WndClassName do begin Style:= CS_PARENTDC; hIcon:= LoadIcon(hApplication,"MAINICON"); lpfnWndProc:= @WindowProcQ;//<--- ОШИБКА ТУТ - "Требуется переменная" hInstance:= hApplication; hbrBackground:= COLOR_BTNFACE+1; lpszClassName:= "Window"; hCursor:= LoadCursor(0,IDC_ARROW); lpszMenuName :="LB_FILE_MENU" end; inherited Create(WndClassName,"Заголовок моего окна",RectBorder,WS_TILEDWINDOW or WS_VISIBLE, 0,0,"LB_FILE_MENU",happlication,nil); end; begin Form1:=TForm1.create; ... и так далее, это не важно сейчас. ... end.

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

Может, кто знает, подскажите пожалуйста.

← →
KSergey © (2004-10-01 06:49) [1]

А в VCL посмотерть?
Ну нельзя в качетсве CallBack указать метод класса. Т.к. у любого метода есть неявный аргумент -указатель на экземпляр.
Вот и думай откуда его взять. Методов много. Почитай на королевтсве Hello, World про семь чудес, да и много где эта тема пережевывалась. В любом случае надо делать некую общую обычную (не член класса) ф-цию - а уже в ней все разруливать. Как - придумай сам.
А главное: вот нахрена такое нужно, вот кто мне объяснит? Заняться нечем??

← →
Alekc (2004-10-01 08:49) [2]

Хинт: Посмотри как это в КОЛ реализовано ;o)

← →
Nil_NULL (2004-10-01 09:51) [3]

А если в классе сделать св-во:
.... pWndProc:TpWndProc; ....
А перед этим определяем тип:
TpWndProc=function (<параметры>):<result>
Далее описвываем функцию и присваеваем в pWndProc, и т.д. Так не будет пахать?

← →
KSergey © (2004-10-01 10:02) [4]

> Так не будет пахать?

Смотря как сделать.
Вот ведь только незадача: оконная процедура задается на весь класс окна (не путать с ООП классами), создаваемый же экземпляр объекта будет будет разный на все создаваемые окна... А класс окна регистрируется ДО создания окна...

А вообще вариаций, понятно, немеряно.

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

а есть еще такие фукнции

function MakeObjectInstance(Method: TWndMethod): Pointer;
procedure FreeObjectInstance(ObjectInstance: Pointer);
function AllocateHWnd(Method: TWndMethod): HWND;
procedure DeallocateHWnd(Wnd: HWND);

из подуля classes.pas

посмотри как их использует сама vcl

← →
Comp © (2004-10-01 10:18) [6]

KSergey
>А главное: вот нахрена такое нужно, вот кто мне объяснит? Заняться нечем??

Методом ООП программы (ЛЮБЫЕ) писать проще, да и текст потом нагляднее. Вот я и хочу так сделать.

> А класс окна регистрируется ДО создания окна...

Че-то я не пойму. Я собираюсь класс окна (тот, который не ООП), точнее переменную типа этот класс втиснуть в другой класс, например TForm1, а в процессе выполнения программы...

begin

...создать этот класс (TForm1), который и создаст сначала переменную типа класс окна, потом зарегистрирует её.

end.

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

> Методом ООП программы (ЛЮБЫЕ) писать проще, да и текст
> потом нагляднее. Вот я и хочу так сделать.

Borland тоже так считает. Написал VCL для этого.

← →
Comp © (2004-10-01 10:22) [8]

>Суслик ©
Спасибо, домой попаду - перерою весь модуль.

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

← →
Nil_NULL (2004-10-01 10:25) [9]

>>Вот ведь только незадача: оконная процедура задается на весь класс окна (не путать с ООП классами), создаваемый же экземпляр объекта будет будет разный на все создаваемые окна... А класс окна регистрируется ДО создания окна...
Св-во можно пихнуть в класс TWindowClass а процедуру сделать виртуальной/абстрактной и описывать её в TForm(от TWindowClass)

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

Автору.

Ты такое сочетине VCL знаешь?
Нафиг это все?

Имхо такой подход оправдан только в целях изучения. Но в данном случае сложно тебя понять - ты очевидно не изучил модуль controls,forms и пр. Иначе ты точно получил бы ответ не ворпос.

← →
Comp © (2004-10-01 10:29) [11]

Игорь Шевченко , да, только готовым пользоваться не очень приятно...(в смысле до такой степени, что ручками почти ничего не надо писать - взял кнопочку, да тискаешь её с места на место, например). Это не программирование.
У API больше (НАМНОГО) возможностей.

А вообще кто нибудь увлекается программированием целиком на API?
Если да, то наверняка эту проблему решили уже давно. Помогите пожалуйста решить её сейчас :((

← →
Суслик © (2004-10-01 10:32) [12]

>
> А вообще кто нибудь увлекается программированием целиком
> на API?
> Если да, то наверняка эту проблему решили уже давно. Помогите
> пожалуйста решить её сейчас :((

Братец, ты читать умеешь?
Я тебе дал ответ.

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

суслик ©, да, внутри них я не лазил - да и зачем было? (как я уже сказал).

А теперь VCL будто не существует - есть тока API, Pascal,C++, и справка всякая.

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

> да, внутри них я не лазил - да и зачем было? (как я уже
> сказал).

Зачем? Хотя бы для того, чтобы не задавать этот вопрос, а найти ответ там.:))

← →
Comp © (2004-10-01 10:36) [15]

> Суслик,
Я тебе дал ответ.

например?

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

> [15] Comp © (01.10.04 10:36)

Ты эттта, того, тупишь что ли?

Моих ответов тут несколько штук. И только в одном есть упоминание неких фукнци. Неужели сложно найти?

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

Comp © (01.10.04 10:29) [11]

> готовым пользоваться не очень
> приятно...(в смысле до такой степени, что ручками почти
> ничего не надо писать - взял кнопочку, да тискаешь её с
> места на место, например). Это не программирование.
> У API больше (НАМНОГО) возможностей.

Велосипед изобретать полезно только с точки зрения самообразования. Не больше.

Я к чему это говорю - если у тебя возникли проблемы, посмотри, как они решены в готовом велосипеде, в данном случае, в VCL.

← →
Nil_NULL (2004-10-01 10:42) [18]

Чесно говоря я не могу понять смысл(т.е. для чего автор это делает) вопроса. Например для написания маленькой программки я беру API. Если много работы с пользовательским интерфейсом то проще не тратить время на API, а покидать элементы на форму/формы

← →
Суслик © (2004-10-01 10:47) [19]

> Nil_NULL (01.10.04 10:42) [18]
> Чесно говоря я не могу понять смысл

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

← →
Comp © (2004-10-01 10:49) [20]

Суслик ©

Я уже сказал, что твои функции (в смысле,которые ты упомянул) я рассмотрю позже.

Во-вторых мнения одного человека всегда мало.

В третьих, ты хороший теоретик, а насчет практики пока себя не проявил (в этой ветке)

← →
Comp © (2004-10-01 10:52) [21]

Суслик ©

Давай не будем устраивать ругань
Но ты здесь не один, и пожалуйста не считай, что твоего ответа достаточно.
Это самопереоценка.

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

> В третьих, ты хороший теоретик, а насчет практики пока себя
> не проявил (в этой ветке)

при чем тут теория?
я тебе дал конкретную функцию: MakeObjectInstance.

lpfnWndProc:= @WindowProcQ;
замени на
lpfnWndProc:= MakeObjectInstance(WindowProcQ);

не забудь соответсвующим образом заменить описание твоей оконной функции.

← →
Nil_NULL (2004-10-01 10:55) [23]

2Суслик
Насчёт самообразованию я придерживаюсь следущего:
- Читать другие коды/программы/компоненты (умение анализировать)
- Читать Статьи/крниги ;)
- Читать примеры Borland"a & VCL
- Элсперементировать... 8)
З.Ы.
ну это в кратце...

← →
Comp © (2004-10-01 10:56) [24]

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

← →
Суслик © (2004-10-01 10:56) [25]

> [21] Comp © (01.10.04 10:52)
> Суслик ©
>
> Давай не будем устраивать ругань
> Но ты здесь не один, и пожалуйста не считай, что твоего
> ответа достаточно.
> Это самопереоценка.

Братец.
Ты сказал
"Помогите пожалуйста решить её сейчас :((".
Я тебе сказал, что решить ее сейчас можно так-то и так-то.
Где ты тут углядел самопереоценку? :)) Может в том, что решил наставить тебя не путь истинный. Пожалуй да - переоценил себя :)))

← →
Суслик © (2004-10-01 10:57) [26]

> Лучше попотеть, но остаться довольным.

и бедным...

← →
Comp © (2004-10-01 10:59) [27]

Люди, всем спасибо, но давайте не будем разговаривать, иначе перекинут туда, где тока трёпом и занимаются.

Суслик © (01.10.04 10:54) [22]

Спасибо, я приду домой рассмотрю.

← →
Nil_NULL (2004-10-01 11:00) [28]

Ну тык я и писал что если необходима маленькая - API.
Ну или вот пример: Одна из форм проекта отображает данные - визуальных компонентов >=20 (Edit"ы, MaskEdit"ы, StringGrid"ы) а теперь представь сколько времени и кода у тебя уйюдет на реализацию хотябы двух методов : заполнение данными и получение данных? (а проект не из одно формы)

← →
Nil_NULL (2004-10-01 11:00) [29]

← →
Comp © (2004-10-01 11:01) [30]

Суслик © , вот ты чел.
Да, можно и бедным. Но потом приятно смотреть и довольствоваться собственной победой над своим же незнанием...

← →
Nil_NULL (2004-10-01 11:01) [31]

Удачи !!!

← →
Суслик © (2004-10-01 11:03) [32]

> [30] Comp © (01.10.04 11:01)
> Суслик © , вот ты чел.
> Да, можно и бедным. Но потом приятно смотреть и довольствоваться
> собственной победой над своим же незнанием...

Ты бы возрат в анкете указал - есть ощущение, что ты в 8 классе.

← →
Comp © (2004-10-01 11:04) [33]

Суслик ©

Братец.
Ты сказал
"Помогите пожалуйста решить её сейчас :((".
Я тебе сказал, что решить ее сейчас можно так-то и так-то.
Где ты тут углядел самопереоценку? :)) Может в том, что решил наставить тебя не путь истинный. Пожалуй да - переоценил себя :)))

Нет, то, что ты настырно настаиваешь на том, что твоего ответа хватит.

Извини, я уже сказал, что это как вариант остается.

← →
Игорь Шевченко © (2004-10-01 11:06) [34]

> В третьих, ты хороший теоретик, а насчет практики пока себя
> не проявил (в этой ветке)

А с чего ты решил, что тебе тут кто-то обязан ? :)

Занимаешься изобретением велосипедов, так и наступай на грабли самостоятельно :)

← →
Comp © (2004-10-01 11:08) [35]

Суслик ©

Извини, я не знаю, наскока ты образован.

Во вторых, программированием я занимаюсь только год.

В третьих, это только моё хобби. Ради собственного интереса.

← →
Comp © (2004-10-01 11:09) [36]

Игорь Шевченко ©

А я и не говорил , что мне кто-то ОБЯЗАН.

Я хочу узнать мнение других, а не тока одного человека.

Ты что-то перепутал.

← →
Comp © (2004-10-01 11:11) [37]

Игорь Шевченко ©,

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

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

> [35] Comp © (01.10.04 11:08)
> Извини, я не знаю, наскока ты образован.

Причем здесь мое образование?

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

Зачем тебе примеры? Ты же сам изобретаешь велосипед.
У тебя пример под боком - vcl называется. Изучай. Точку входа я тебе дал.

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

> [37] Comp © (01.10.04 11:11)
> Когда человек делится примером, эффект больше, и вопросов
> меньше.

Ага, и copy/paste проще...

← →
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]

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

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

← →
iZEN © (2004-10-01 22:44) [69]

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

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

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

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

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

iZEN © (01.10.04 22:44) [69]

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

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

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

← →
iZEN © (2004-10-01 23:06) [71]

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

← →
Игорь Шевченко © (2004-10-01 23:14) [72]

iZEN © (01.10.04 23:06) [71]

> Этому посвящено много дискуссий

Ссылочку, если не трудно ?

← →
iZEN © (2004-10-01 23:23) [73]

/**Игорь Шевченко © (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) в будущем (или будут,
> но уже используя другие библиотеки).

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

Игорь Шевченко © (04.10.04 17:39) [80]

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

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

Borland JBuilder тоже позиционирует как Rapid Application Development Tool, тем не менее, в нём поддержана идеология MVC (модель, отображение, контроллёр) при создании GUI.
> VCL слабо подготовлена (именно подготовлена) к дальнейшему
> расширению.

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

Ну, мне например, нужна градиентная заливка контролов и цветовых тем, независимая от системы. Что я буду делать? Изобретать "скины" как свой собственный крутой велосипед?

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

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

Уже не рановато.

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

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

Без переписывания той лапши в перемешку с кодом обработки данных нельзя обновить внешний вид приложения, сделать его похожим на Apple iTunes, например, по внешнему виду. "Лёгким движение руки не получится превратить бруки в шорты" (c) "Бриллиантовая рука".

← →
Algol (2004-10-04 17:50) [82]

[81] iZEN © (04.10.04 17:48)

Согласитесь, что Delphi RAD гораздо более Rapid, чем в JBuilder. Даже несмотря на автоматическую конвертацию из одного Layout в другой.

/**Algol (04.10.04 17:50) [82]
Мне кажется что это не следствие структуры VCL, а все-таки следствие непрофессионализма "кликальщиков".
*/
Одно тянет за собой другое: Delphi позволяет не заботиться о структуре кода - "раз и готово" - вот девиз этой среды. Интеллектуальный барьер снят, среда доступна и ей пользуются большее число "недалёких" людей, чем, например, JBuilder. Как всегда маркетинговые и практические соображения (нетребовательная к железу, легко развёртываемая и простая для изучения, быстрый компилятор EXE/DLL/OCX) тоже сыграли не последнюю роль в продвижении.

iZEN © (04.10.04 17:48) [81]

> Borland JBuilder тоже позиционирует как Rapid Application
> Development Tool, тем не менее, в нём поддержана идеология
> MVC (модель, отображение, контроллёр) при создании GUI.

Не имея представления о Borland JBuilder не могу дать никакую оценку. Сам по себе факт реализации MVC не хорош и не плох.

> Уже не рановато.

У меня, как ни странно, другой опыт. И разрастание проекта до N форм не приводит ни к помешательству ни к суперпрограммизму. У знакомых мне пользователей Delphi ситуация аналогичная.

> Ну, мне например, нужна градиентная заливка контролов и
> цветовых тем, независимая от системы. Что я буду делать?
> Изобретать "скины" как свой собственный крутой велосипед?

Свою линию standard и custom controls изобретать, очевидно.

> Без переписывания той лапши в перемешку с кодом обработки
> данных

Для начала такую лапшу не надо писать, не правда ли ?

iZEN © (04.10.04 18:00) [84]

> Интеллектуальный барьер снят, среда доступна и ей пользуются
> большее число "недалёких" людей, чем, например, JBuilder

И чем это плохо ?

> И чем это плохо ?

во-во...
я тоже не пойму.

/**Sandman25 © (04.10.04 17:55) [83]

[81] iZEN © (04.10.04 17:48)

Согласитесь, что Delphi RAD гораздо более Rapid, чем в JBuilder. Даже несмотря на автоматическую конвертацию из одного Layout в другой.
*/
Нет, не соглашусь.
JBuilder, особенно Enterprise-версия позволяет вести совместную работу (разработку и удалённую отладку) с различными серверами приложений не покидая среды. Полу- и Автоматический деплоймент и развёртываение enterprise-приложений очень много зачат для разработчиков.

to Игорь Шевченко © (04.10.04 18:03) [85]
Раз уж Вы профи в Delphi...
Полностью согласен с последними двумя высказываниями - от VCL мало что дождёшься кроме базовой функциональности предков, а вот лапшу трудно не написать, чем обратное.

> вот лапшу трудно не написать, чем обратное.

имхо от vcl лапша или не лапша не зависит.

iZEN © (04.10.04 18:12) [89]

Уважаемый, лапшу написать можно с одинаковой легкостью в какой угодно среде. Было бы желание и руки соответствующие.

> от VCL мало что дождёшься кроме базовой функциональности
> предков

В этом ее великая заслуга, кстати :)

← →
Sergey_Masloff (2004-10-04 18:16) [92]

iZEN © (04.10.04 18:06) [88]
>JBuilder, особенно Enterprise-версия позволяет вести совместную >работу (разработку и удалённую отладку) с различными серверами >приложений не покидая среды.
И что?

>Полу- и Автоматический деплоймент и развёртываение enterprise->приложений очень много зачат для разработчиков.
Это вообще ерунда. Не бывает никакого автоматического развертывания. Enterprise приложения перед развертыванием тестируются и отлаживаются и время на развертывание по сравнению с этим-ничтожно, следовательно и смысла экономить на нем нет.
Как один из разработчиков энтерпрайс приложения которым постоянно пользуется несколько десятков тысяч пользователей разбросаных по всему миру могу ответственно заявить - автоматическое развертывание это АБСОЛЮТНО не та проблема что много значит для разработчиков, что бы не писали в рекламных проспектах.
И вообще в ставшей с недавних пор моей любимицей книге Peopleware - Productive Projects and Teams среды разработки и вообще инструментарий это не то что должно беспокоить разработчиков и IT руководителей ;-)

/**Zacho © (04.10.04 18:20) [93]
А, я понял, ты один из тех, кто всерьёз воспринял "Настоящие программисты не используют Паскаль" ?
*/
Лично мне нравится Паскаль своей однозначностью и выразительностью без "выкрутасов". Но, к сожалению, Стандартный Паскаль уже давно не развивается или развивается в других языках (Modula и Oberon). Да и новый стандарт на этот язык (теперь уже ObjectPascal) вводить никто не собирается. Печально, но факт. Хорошая академическая идея по-всякому "извращена" в различных несовместимых между собой (не)коммерческих продуктах: разброд и шатание.

А так называемые "настоящие программисты" под конкретное дело почти всегда выбирают адекватный инструмент, всё время надеясь найти "универсальный молоток". Как ни печально... ;))

to Sergey_Masloff (04.10.04 18:16) [92].
Развёртывание и технология развёртывания - один из важных этапов подготовки приложения к работе, не говоря уж о серверах, в том числе для работы на офисных ПК.

Деплойер - одна из ролей Enterprise-разработчика (кто работает с J2EE/EJB - тот знает). Приложение должно соответствовать аспектам функционирования в той бизнес-среде, для которой оно предназначено. Есть куча промышленных серверов приложений J2EE, в которых особенности работы EJB-моделей описываются дескрипторами развёртывания (XML-описателями бизнес-логики). Эти дескрипторы НЕСОВМЕСТИМЫ между собой. С серверами приложений поставляются т.н. инструменты подготовки и развёртывания EJB-приложений (deploytool"s).

Но в процессе создания и отладки приложения в JBuilder можно забыть о сторонних инструментах развёртывания и работать из среды - цикл редактирование/сборка/развёртывание/отладка резко сокращается, разработчик имеет почти все необходимые инструменты по мониторингу состояния приложения внутри среды.

Далее, подготовка отлаженного приложения сводится к клику мышки, после которого J2EE-приложение остаётся просто перенести на сервер (или передав его деплойеру, который деньги за это получает).

/**Sergey_Masloff (04.10.04 18:16) [92]
И вообще в ставшей с недавних пор моей любимицей книге Peopleware - Productive Projects and Teams среды разработки и вообще инструментарий это не то что должно беспокоить разработчиков и IT руководителей ;-)
*/
В высшей степени головотяпство.
Под разработку всегда должен подбираться адекватный инструментарий и кидать это на самотёк - верх безумия.

Удалено модератором
Примечание: Почитай правила, прежде чем писать

Удалено модератором

>Comp © (04.10.04 20:43) [99]
1. При пользовании общественным internet-ресурсом сначала обычно читают правила.
2. Серьезные вопросы обсуждаются в основном в тематических форумах. Эта конференция - для трепа. Соответственно, что хотели - получили.
3. Про обсуждение действий модератора - см. п.1

Удалено модератором
Примечание: Не надо продолжать.

Mystic © (01.10.04 15:03) [49]
некоторые особенности работы с WinAPI в VCL обернуты на уровне языка (зарезервированное слово message

Это не так. Зарезервир. слово message никакого отнашения в виндовым сообщениям НА УРОВНЕ ЯЗЫКА не имеет. То что у наследников Control виндовые сообщения можно обработать с помощью procedure WmMessage(var Message: TMessage); message WM_MESSAGE; - это особенность реализации TControl.WndProc

procedure TControl.WndProc(var Message: TMessage);
begin
...
Dispatch(Message);
end;

Если я перекрою этот метод и не буду вызывать Dispatch, то упомянутым выше способом вы не сможите обработать win сообщения. Подробнее см хелп по TObject.Dispatch/DefaultHandler и ещи с ними..

Удалено модератором

[88] iZEN © (04.10.04 18:06)

Я пишу клиентскую часть, поэтому для меня гораздо важнее, сколько времени я потрачу на создание пользовательского интерфейса: на все эти панельки, кнопочки и комбобоксы.
Вчера я был буквально шокирован - я не могу в дизайнере проскроллировать ScrollPane. Имеющихся команд контекстного меню Move Last и Move Fast недостаточно, особенно по сравнению с дельфийским кликаньем на полосе прокрутки. Поэтому не стоит говорить, что у Delphi перед JBuilder. Хотя должен признаться, что в целом JBuilder X более удобен, чем Delphi 7.

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