sender as

[Verx0Laz]

А вот интересно, на сколько именно в данном практическом случае были оправданы эти "танцы в лазерном дыму"? Может, автору данного поста просто надо было прописать одну трёхстрочную процедурку в трёх ОнЧенжях?

[zub]

Флейм есть флейм, насоветовали, теперь разгребаем. То что было нужно автору уже никому не интересно))

Кстати вот простой пример ущербности формы как основы для логики
есть у нас какойнить LoadDataFromInternet, он прописан в onClick на нескольких кнопках и на паре пунктов меню (кстати, как его заюзать дизайнером на нескольких формах?). В какойто момент соединение с инетом пропадает, догично временно задисаблить всё что имеет LoadDataFromInternet в onClick. Что будем делать?

Код: Выделить всё

Procrdure TmyForm.onInternetLost(...);
begin
  ...
  LoadButton1.disable;
  ...
  LoadButton10.disable;
  LoadMenuItem1.disable;
  ...
  LoadMenuItem10.disable;
  ...
end;

?

[stanilar]

Я уже сказал про onResize и прочую подобную пакость, которая бизнес логике ненужна

Нет, не нужна. Ее можно вынести в TMyMyForm.

Если при этом mySuperBusinessUnit ничего не будет знать о TmyForm (т.е. форма и всё что связано с гуем не будет фигурировать в обоих uses`ах mySuperBusinessUnit) можно будет говорить о полном разделении.

Так если TmyForm унаследовать от TMyBiznessObject тоже можно будет сказать о разделении.

Кстати как вы с контролами поступаете? утягиваете в консоль? Но если в консоли они не будут проинициализированы, то и tedit.text запросить нельзя...

Для консоли TMyEdit будет иметь другую реализацию, в которой можно будет и .text запросить.

Не понял, подробнее что и где обломится?

Так, о чем это мы? Ах да... В потрохах вкл неважно, что конкретный экземпляр формы будет создавать, TEdit или TMyEdit, потому что реадер ищет или зарегестрированный класс, или наследник. Именно поэтому "хак" из первых постов возможен. Правдивость этого утверждения предлагаю проверить Вам, как более заинтересованному.

Добавлено спустя 10 минут:

Что будем делать?

Ну и зачем ты код привел? Мне пришлось долго протирать свой хрустальный шар, но из того что мне понятно, следует такой ответ: В TButton надо определить пустой метод disable.

[Verx0Laz]

И тут мы обнаруживаем себя внутри одной очень старой задачи

http://absite.ru/humor.php?pg=32

[zub]

Нет, не нужна. Ее можно вынести в TMyMyForm.

Ага, набегает... а каже тот факт что в дизайнере можно работать только с наследником TForm в качестве формы? будем подменять форму? увы тогда данный способ несработает

Так если TmyForm унаследовать от TMyBiznessObject тоже можно будет сказать о разделении.

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

Для консоли TMyEdit будет иметь другую реализацию, в которой можно будет и .text запросить.

Ох едтить... а говорите всё легко и просто. Так делать совсем нестоит, ибо это уже не дажа копипаста кода, а мокрые сны какието про скрещение ужа с ежом.
Я бы это понял если бы поднялась тема про организацию для LCL бакенда который работает в консоли (да, у меня тоже фантазия есть) но в свете простого разделения гуя от логики...

Так, о чем это мы? Ах да... В потрохах вкл неважно, что конкретный экземпляр формы будет создавать, TEdit или TMyEdit, потому что реадер ищет или зарегестрированный класс, или наследник. Именно поэтому "хак" из первых постов возможен. Правдивость этого утверждения предлагаю проверить Вам, как более заинтересованному.

Я уже проверил о чем отчитался на прошлой странице. обломов нет. работает и даже вроде разобрался почему работает.
В чем должен заключаться облом?

Ну и зачем ты код привел? Мне пришлось долго протирать свой хрустальный шар, но из того что мне понятно, следует такой ответ: В TButton надо определить пустой метод disable.

помогу с протиркой, я совсем незнаю LCL и грешным делом думал что метод .disable у контролов есть, оказалось что есть только свойство .Enabled

Код: Выделить всё

Procrdure TmyForm.onInternetLost(...);
begin
  ...
  LoadButton1.Enabled:=false;
  ...
  LoadButton10.Enabled:=false;
  LoadMenuItem1.Enabled:=false;
  ...
  LoadMenuItem10.Enabled:=false;
  ...
end;

но суть не в этом, суть в том что понадобилось запретить какоето действие. как задисаблить все связанные с ним контролы?
Юзая onЧетоТам никак(( головой вспомнить все связанные контролы и руками набросать процедуру подобную приведенной выше

[stanilar]

Юзая onЧетоТам никак

Ну как-же никак, если в Вашем коде именно такое событие и написано?

[zub]

Это ерунда не метод. Головой вспоминать приходится, а если потом какойнить контрол добавится?

[stanilar]

а если потом какойнить контрол добавится?

Вот именно об этом и речь. Если код предусматривает, что TForm имеет две разных реализации, то у Вас есть гарантия, что в обоих реализациях Вы не забудете о добавлении нового объекта. А вот если из формы дергать методы бизнес объекта, то может получится, что две реализации по разному работают с бизнес объектом.

[zub]

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

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

[stanilar]

Разделением и введением прокладки в виде экшенов все проблемы решаются

Ну тогда Вам тем более ничто не мешает унаследовать TForm от TActionList, а события ОнЧтоТоТам переопределить как события TAction.

Добавление контрола никак не влияет на бизнеслогику, добавление логики влияет на контролы.

Речь не совсем о взаимном влиянии, но ночером мне уже что-то сложно соображать.

[zub]

>>Ну тогда Вам тем более ничто не мешает унаследовать TForm от TActionList, а события ОнЧтоТоТам переопределить как события TAction.
действительно, пора спать

[sign]

Может написать класс-хелпер для TEdit?

Хелперы - ЗЛО. Их наличие говорит о том, что программист не использовал мозг при разработке проекта.

Вот у меня есть helper

Код: Выделить всё

  TIniPropStorageHelper = class helper for TIniPropStorage
  public
    procedure WriteColor(const Ident: string; Value: TColor);
    function  ReadColor(const Ident: string; DefaultValue: TColor): TColor;
    procedure WriteDate(const Ident: string; Value: TDateTime);
    function ReadDate(const Ident: string; DefaultValue: TDateTime): TDateTime;
  end;


Где тут зло?

[Лекс Айрин]

В какойто момент соединение с инетом пропадает, догично временно задисаблить всё что имеет LoadDataFromInternet в onClick. Что будем делать?

а почему не сделать по другому?

Код: Выделить всё

Var
     Online:boolean;

Procedure TmyForm.onInternetLost(...);
begin
...
Online:=false;
....
end;

LoadButton1.onRedraw(...)// могу ошибаться с использованием нужной процедуры...
LoadButton1.enable:=Online;


Имхо, так интереснее.

[stanilar]

Где тут зло?

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

Добавлено спустя 52 минуты 51 секунду:

хелпер вместо обертки

Скажу даже больше, в Вашем коде имеет смысл написать полноценного наследника, а не хелпер. Как вы будете расширять функционал в дальнейшем? Писать хелпер к хелперу?

[Лекс Айрин]

Как вы будете расширять функционал в дальнейшем? Писать хелпер к хелперу?

А он не будет.