Operator overloading

← →
Суслик © (2007-04-02 12:29) [80]

> [79] Игорь Шевченко © (02.04.07 12:25)
> oxffff © (02.04.07 12:22) [77]
> Вот есть исходные тексты VCL - все понятно. Хотя код не
> свой.

Понятно, потому что изучал ты его.

Возьми grids.pas. Если тебе там все понятно - ты гений. Честное слово, не шучу. Мне там многое понятно - процентов 70, но я и изучал его в сумме часов 100.

← →
oxffff © (2007-04-02 12:34) [81]

> Вот есть исходные тексты VCL - все понятно. Хотя код не
> свой.

Сколько прошло времени от начало знакомства с VCL до понимания.
Я имею ввиду об устройстве.
Думаю не 1 неделя и не один месяц.

Вот на чем спотыкаются сразу начинающие.
А эти дебри недокументированны.

-MakeObjectInstance
-FreeObjectInstance

← →
oxffff © (2007-04-02 12:40) [82]

function StdWndProc(Window: HWND; Message, WParam: Longint;
LParam: Longint): Longint; stdcall; assembler;

А это сущность обработки сообщений.
И это мы еще не дошли до dynamic методов обработчков конкретных сообщений.

← →
Игорь Шевченко © (2007-04-02 13:36) [83]

oxffff © (02.04.07 12:34) [81]

> Сколько прошло времени от начало знакомства с VCL до понимания.
>
> Я имею ввиду об устройстве.

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

← →
oxffff © (2007-04-02 13:52) [84]

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

Прошли годы. До "реального" осознования работы VCL.

>И потому как код ясный и понятный.

Прошли опять же годы до вылизивания.
Я уверен у них есть места, где нужно произвести рефакторинг.
Но в угоду совместимости, его не сделают.

Вот простой пример

procedure TForm1.Button1Click(Sender: TObject);
var a:TComboBox;
begin
a:=TComboBox.Create(nil);
try
showmessage(inttostr(a.Items.count));
finally
a.free;
end;
end;

Вы что мне скажите?
-Так устороена VCL. Все запросы через через посылку сообщений.

-А я вам скажу. Это логично?

Поэтому приходится довольствоваться тем, что имеем.

А то что ясен код или не ясен.
Отвечу разобраться можно.
Только реально иногда это очень надоедает.

Я честно говоря не

← →
Игорь Шевченко © (2007-04-02 15:00) [85]

oxffff © (02.04.07 13:52) [84]

> Вот простой пример
>
> procedure TForm1.Button1Click(Sender: TObject);
> var a:TComboBox;
> begin
> a:=TComboBox.Create(nil);
> try
> showmessage(inttostr(a.Items.count));
> finally
> a.free;
> end;
> end;

Можно и штаны через голову надевать, только неудобно.

К чему ты этот кусок кода привел?

← →
oxffff © (2007-04-02 15:41) [86]

> Можно и штаны через голову надевать, только неудобно.
>
> К чему ты этот кусок кода привел?

Так вы запустите.

← →
euru © (2007-04-04 10:25) [87]

> Суслик © (02.04.07 10:27) [58]
> про static class method.
Я так понял, что static ввели, чтобы:
1. обеспечить совместимость с .Net (с классами, написанными на других языках);
2. обеспечить обратную совместимость с предыдущими версиями Delphi.

А почему тогда отказались от такого варианта:
1. Выкинуть из обычных классовых методов параметр Self. Это обеспечило бы совместимость с другими языками в .Net.
2. Объявить в свойство Self (ссылка на метакласс), доступное во всех классах, но только в классовых методах. Это обеспечит обратную совместимость с предыдущими версиями.

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

← →
XProger © (2007-04-04 10:52) [88]

Немного уклонюсь от темы, но задам вопрос касательно нововведений.
Покажите для чего и как можно использовать class abstract?

← →
jack128 © (2007-04-04 11:05) [89]

oxffff © (02.04.07 15:41) [86]
Так вы запустите.

а чего его запускать то? И так понятно, что с вероятностью 50/50 либо ноль выведет, либо "window has not parent" или как там эта ошибка звучит . Тут семи пядей во лбу не нужно, что это понять.

← →
oxffff © (2007-04-04 11:12) [90]

> jack128 © (04.04.07 11:05) [89]
> oxffff © (02.04.07 15:41) [86]
> Так вы запустите.
>
> а чего его запускать то? И так понятно, что с вероятностью
> 50/50 либо ноль выведет, либо "window has not parent" или
> как там эта ошибка звучит . Тут семи пядей во лбу не нужно,
> что это понять.

"window has not parent" - это нормально и логично для подобного запроса?

← →
tesseract © (2007-04-04 11:26) [91]

> Вы что мне скажите?
> -Так устороена VCL. Все запросы через
> через посылку сообщений.

Так устроена Windows!

← →
Игорь Шевченко © (2007-04-04 11:43) [92]

oxffff © (04.04.07 11:12) [90]

> "window has not parent" - это нормально и логично для подобного
> запроса?

Это нормально и логично. Если кто-то создает контролы с nil в качестве владельца, то он должен быть готов к таким сообщениям. Если кто-то ComboBox использует вместо TStringList, по проблемы логики - это сугубо его проблемы.

← →
XProger © (2007-04-04 11:43) [93]

oxffff, tesseract, скажу даже больше, так устроена вся объектная модель Delphi, любой класс в состоянии обрабатывать message директивы наложенные на его методы (TObject.Dispatch)

← →
oxffff © (2007-04-04 11:49) [94]

> Так устроена Windows!

Нет так устроена VCL.
Если делаешь wrapper вокруг ComboBox, то делать нужно нормально.

проблема в подходе VCL, создание-пересоздание окон на лету.

← →
oxffff © (2007-04-04 12:15) [95]

>Если кто-то ComboBox использует вместо TStringList, по проблемы логики - >это сугубо его проблемы.

Проблема была в том (так нужно мне), что при разрушения Tcombobox он должен передать свое состояние другому объекту. Но если к этому моменту произошел вызов DestroyWindowHandle, то сделать это уже невозможно.
Проблема здесь в самом подходе VCL, а именно в создании и разрушении окон on time.
Решение безусловно найдено.
Но собственно если опираетесь на windows combobox, то создайте и не разрушайте его. А Wnd обработчик пусть в зависимости о состояния игнорирует сообщения. Либо динамически меняется на другой например пустой.

> oxffff, tesseract, скажу даже больше, так устроена вся объектная
> модель Delphi, любой класс в состоянии обрабатывать message
> директивы наложенные на его методы (TObject.Dispatch)

Я вам еще больше скажу. Это здесь вообзще непричем.
На dynamic методах никуда не уедешь, если в WndProc не вызвать Dispatch

← →
oxffff © (2007-04-04 12:32) [96]

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

Если поковыраться дальше, то можно заметить

procedure TForm1.Button1Click(Sender: TObject);
var a:TComboBox;
begin
a:=TComboBox.Create(self);
try
a.Parent:=self;
a.Items.Add("A1");
a.Items.Add("A2");
a.Parent:=nil;
a.parent:=self;
showmessage(inttostr(a.Items.count));
finally
a.free;
end;
end;

Что код выдаст 2. А почему?

Смотрим

procedure TCustomComboBox.DestroyWnd;
begin
if FItems.Count > 0 then
begin
FSaveIndex := ItemIndex;
FSaveItems := TStringList.Create;
FSaveItems.Assign(FItems);
end;
inherited DestroyWnd;
end;

Аналогично в procedure TCustomComboBox.CreateWnd;

Был бы еще один способ только вот незадача FSaveItems: TStringList в private секции.

← →
oxffff © (2007-04-04 12:35) [97]

Подход VCL в oxffff © (04.04.07 12:32) [96]
указывает на заплатки VCL, которые не были учтены в при дизайне TControl и в особенности TWincontrol.

← →
Игорь Шевченко © (2007-04-04 12:42) [98]

oxffff © (04.04.07 12:32) [96]

> a.Parent:=nil;
> a.parent:=self;

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

← →
oxffff © (2007-04-04 12:46) [99]

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

Для демонстрации того, что при разрушении окна, происходит сохранение
списка в FSaveItems. При пересоздании окна его заполнение из FSaveItems.

Все это указывает на вынужденные заплатки.

← →
Игорь Шевченко © (2007-04-04 12:52) [100]

oxffff © (04.04.07 12:46) [99]

Если ты посмотришь, при каких условиях вызывается DestroyWindowHandle, это наведет тебя на путь к истине

← →
oxffff © (2007-04-04 13:56) [101]

> Если ты посмотришь, при каких условиях вызывается DestroyWindowHandle,
> это наведет тебя на путь к истине

Вы говорите загадками.

Вызывается DestroyWindowHandle из деструктора, и из DestroyWnd;
Учтите, что в моем случае еще до вызова деструктора, окно уже разрушено
(Twincontrol.Parent:=nil).

Вы посмотрите, что происходит при Twincontrol.Parent:=nil,
окно гарантированно разрушается.

← →
Игорь Шевченко © (2007-04-04 14:03) [102]

oxffff © (04.04.07 13:56) [101]

Ну правильно. При смене стиля окна с дочернего на недочернее или наоборот, окно необходимо создать заново - так Windows устроена.
Чему ты удивляешься ?

← →
oxffff © (2007-04-04 14:05) [103]

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

При разрушении родителя или при явном вызове destroy.
В деструкторе еще можно обратиться к "окну" поскольку оно еще не разрушено.
Но если вызвать явно parent:=nil, то окно гарантированно разрушится.
Почему это происходит.

Есть редактор в нем есть средства. У каждого средства свои настройки.
В зависимости от выбранного средства появляется свой frame настроек.
Поэтому постоянно у этого фрейма идет вызов

при активации ToolOptionsFrame.parent:=ToolOptionsWindow
при деактивации ToolOptionsFrame.parent:=nil;

По завершении нужно обратиться к средствам и считать настройки.
Но окно разрушено.

Путь к истине.

Вы его видите?

← →
oxffff © (2007-04-04 14:14) [104]

> Чему ты удивляешься ?

Я соственно не удивляюсь.
Просто считаю, что появление ошибки "Сontrol has no parent window" не должно вообще происходить. Ведь по логике причем здесь компонент и отсутствие окна.

В случае с Tcombobox им можно было поступить. Как вариант

При отсутствии окна a.Items работает FSaveItems,
при наличие использует TComboBoxStrings.

← →
Игорь Шевченко © (2007-04-04 14:28) [105]

oxffff © (04.04.07 14:05) [103]

> Но если вызвать явно parent:=nil, то окно гарантированно
> разрушится.
> Почему это происходит.

потому что так устроена Windows

> Путь к истине.
>
> Вы его видите?

Путь к истине лежит в изучении матчасти.

> Просто считаю, что появление ошибки "Сontrol has no parent
> window" не должно вообще происходить. Ведь по логике причем
> здесь компонент и отсутствие окна.

По логике ты создаешь Control класса COMBOBOX. Если твоя логика этот факт игнорирует, то смени логику.

← →
REA (2007-04-04 14:33) [106]

Тут не все так очевидно. В приснопамятной MFC создавая Page Control можно было добраться до свойств Control-ов только текущей открытой страницы ибо windows убивал Handle всего что не видно. В Delphi это маскируется и можно работать с чем угодно не особенно заботясь есть у него Handle или будет попозже.

← →
oxffff © (2007-04-04 14:43) [107]

> потому что так устроена Windows

Фразу "Почему это происходит" относилась к тому что было написано после нее. Это был не вопрос.
Далее я пояснил почему это происходит.

> Путь к истине лежит в изучении матчасти.

Нет. в грамотном проектирование структуры классов и их взаимодействия.

> По логике ты создаешь Control класса COMBOBOX. Если твоя
> логика этот факт игнорирует, то смени логику.

Вы считаете что структура классов VCL и схема их взаимодействия оптимальна?

Если я хочу узнать у контрола столько в нем элементов. То сделать он должен это в любое время своей жизни. И не ссылаться на, на то что сделать это он не может.

Поэтому если вылезают ошибки Сontrol has no parent Window.
То это как раз проблемы тех, кто писал его.
Поскольку наличие или отсутствие окна ни как не должна быть связана с функциональностью контрола. И даже wrapper контрола.

Еще раз повторю VCL нужен рефакторинг.

Несмотря на это
http://www.stevetrefethen.com/blog/VCLAndRTLEnhancementsSinceDelphi7D7.aspx

детские болезни VCL перерастают в хронические

← →
Игорь Шевченко © (2007-04-04 14:46) [108]

oxffff © (04.04.07 14:43) [107]

> Если я хочу узнать у контрола столько в нем элементов. То
> сделать он должен это в любое время своей жизни. И не ссылаться
> на, на то что сделать это он не может.

Бред.

> Еще раз повторю VCL нужен рефакторинг.

"You say you want a revolution
Well, you know
We all want to change the world
You tell me that it"s evolution
Well, you know
We all want to change the world
But when you talk about destruction
Don"t you know that you can count me out
Don"t you know it"s gonna be all right
all right, all right"

(c) Beatles

> Бред.

Где?

> > Еще раз повторю VCL нужен рефакторинг.
>
>
> "You say you want a revolution
> Well, you know
> We all want to change the world
> You tell me that it"s evolution
> Well, you know
> We all want to change the world
> But when you talk about destruction
> Don"t you know that you can count me out
> Don"t you know it"s gonna be all right
> all right, all right"
>
> (c) Beatles

Я к счастью на PRODIGY воспитан.

oxffff © (04.04.07 14:53) [109]

> Где?

Очевидно в процитированном высказывании: "Если я хочу узнать у контрола столько в нем элементов. То сделать он должен это в любое время своей жизни. И не ссылаться на, на то что сделать это он не может."

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

> Я к счастью на PRODIGY воспитан.

Так какая разница - язык английский, как в help"е

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

Следуя вашей логики.
Нет окна, нет контрола.

Только вот, что не срастается по вашей логике

Почему тогда Tcontrol.left:=100 при parent=nil не вызывает Сontrol has no parent Window.

И уже я спешу вашу логику назвать бредом.

>
> Так какая разница - язык английский, как в help"е

Текст я понял.

Поймите же вы наконец.
У меня нет вопросов по устройству VCL.

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

> oxffff © (04.04.07 15:04) [113]

> контрол должен сказать сколько в нем строк

> Потому что понятие контрола не основано на понятии окна

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

> Конкретный контрол ничего тебе не должен.

Это то понятно.

То есть ваш лозунг Да здраствует "Сontrol has no parent Window".

> Почему тогда Tcontrol.left:=100 при parent=nil не вызывает
> Сontrol has no parent Window.
>
> И уже я спешу вашу логику назвать бредом.

Здесь я имею ввиду, что согласно логике это тоже должно приводить к исключению при отсутствии окна.
Почему это не происходит понятно (для тех кто цепляется к словам).

oxffff © (04.04.07 14:59) [111]

> Следуя вашей логики.
> Нет окна, нет контрола.
>
> Только вот, что не срастается по вашей логике
>
> Почему тогда Tcontrol.left:=100 при parent=nil не вызывает
> Сontrol has no parent Window.

Не все контролы являются TControl, часть из них является TWinControl. А в их поведении имеется существенная разница.

> Не все контролы являются TControl, часть из них является
> TWinControl. А в их поведении имеется существенная разница.
>

Тогда если судить "по вашему"
Twincontrol.SetBounds должен генерировать исключение при HandleNotAllocated.

Но он это не делает.
Здесь логика одна, а вот здесь другая.

У меня нет вопросов ни к вам, ни к VCL.

Так устроено. И менять никто уже ничего не будет.

> при активации ToolOptionsFrame.parent:=ToolOptionsWindow
> при деактивации ToolOptionsFrame.parent:=nil;
>
> По завершении нужно обратиться к средствам и считать настройки.
>
> Но окно разрушено.
>
> Путь к истине.
>
> Вы его видите?

Никогда не храните данные в контролах. Когда-то давно услышал эту простую истину. Вам она тоже подойдет. Специфика виндов такая. А если уж совсем не нравится ВЦЛ - перепишите. Откомпилите системные модули по-новой и вперед пользоваться тем что устраивает.

ЗЫ: Попробуйте, уважаемый оратор, в рантайме сменить выравнивание текста с EditBox-е. Это так, простейший пример.

> Twincontrol.SetBounds должен генерировать исключение при
> HandleNotAllocated.
>
> Но он это не делает.

И правильно делает. Если окно не создано - то никто не мешает задать значение свойства, чтобы оно потом было взято при реальном создании окна. Вот захотели вы в конструкторе задать левую границу - а окно не создано. Что теперь, вешаться на обработчик OnCreate оконного контрола. запоминать что там было назначено, а после отработки возвращать? Вообще, судя по вашим речам - мне кажется что у вас маленький опыт программирования, а вы тут о рефакторинге. У меня самого лет 7, но я еще очень давно понял, насколько это геморройно сделать процесс создания окон оптимальным и своевременным. И часто алгоритм программ приходилось подстраивать, а не тупо требовать "дайте мне окно". И вообще, ВЦЛ устроена так, что программист должен заботиться о том, создано окно или нет, и когда оно пересоздается.

Поэтому тут два выхода - либо пользовать то, что есть, и так, как надо, либо совсем не пользовать.

> SPeller © (04.04.07 17:37) [119]
>
> > при активации ToolOptionsFrame.parent:=ToolOptionsWindow
> > при деактивации ToolOptionsFrame.parent:=nil;
> >
> > По завершении нужно обратиться к средствам и считать настройки.
>
> >
> > Но окно разрушено.
> >
> > Путь к истине.
> >
> > Вы его видите?
>
> Никогда не храните данные в контролах. Когда-то давно услышал
> эту простую истину. Вам она тоже подойдет. Специфика виндов
> такая. А если уж совсем не нравится ВЦЛ - перепишите. Откомпилите
> системные модули по-новой и вперед пользоваться тем что
> устраивает.
>
> ЗЫ: Попробуйте, уважаемый оратор, в рантайме сменить выравнивание
> текста с EditBox-е. Это так, простейший пример.
>
>
> > Twincontrol.SetBounds должен генерировать исключение при
>
> > HandleNotAllocated.
> >
> > Но он это не делает.
>
> И правильно делает. Если окно не создано - то никто не мешает
> задать значение свойства, чтобы оно потом было взято при
> реальном создании окна. Вот захотели вы в конструкторе задать
> левую границу - а окно не создано. Что теперь, вешаться
> на обработчик OnCreate оконного контрола. запоминать что
> там было назначено, а после отработки возвращать? Вообще,
> судя по вашим речам - мне кажется что у вас маленький опыт
> программирования, а вы тут о рефакторинге. У меня самого
> лет 7, но я еще очень давно понял, насколько это геморройно
> сделать процесс создания окон оптимальным и своевременным.
> И часто алгоритм программ приходилось подстраивать, а не
> тупо требовать "дайте мне окно". И вообще, ВЦЛ устроена
> так, что программист должен заботиться о том, создано окно
> или нет, и когда оно пересоздается.
>
> Поэтому тут два выхода - либо пользовать то, что есть, и
> так, как надо, либо совсем не пользовать.

Малыш не встревай во взрослый разговор.

>Что теперь, вешаться на обработчик OnCreate оконного контрола. >запоминать что там было назначено, а после отработки возвращать?

Ты хоть понял что сказал?

Operator overloading Найти похожие ветки