D
так нечто подобное и сделано. Но главная форма НЕ ЗНАЕТ об этом классе
а вот тут ошибка. Визуал должен знать о классе, а вот сам класс не должен знать о форме от слова "вообще!"
Size: a a a
2020 March 04
AK
главная форма не знает об обработчике т.к. он не должен её касаться. обработчик прикреплён ко вкладке. А главная форма - для обработчки глобальных хоткеев и менеджер вкладок
AS
я не использую сообщения там от слова "совсем" :(
Ну и зря. Есть паттерн проектирования "издатель-подписчик"
Только сообщения не обязательно виндовые могут быть
Только сообщения не обязательно виндовые могут быть
D
Грубо говоря в визуальной части ты определяешь функции и процедуры которые должны обновлять твои списки, посредством Notify прицепляешь к объекту класса эти методы обновления и вызываешь у объекта start. А вот внутри класса реализуй вызов Notify. Смотри как реализованы всякие OnClick у кнопок. Сделай так же. Словно твой класс для работы с файлами это кнопка коих может быть миллион и они друг о друге не знают
AK
Артём, у меня и сделано через события взаимодействия, но не главное окно-обработчик, а только через посредника. Видимо, просто придется ещё одно событие вводить
AS
мда... а вот теперь будет реально головняк... Главная форма строит табконтроль, где на вкладки цепляютя формы, не знающие о главной. Из вкладки запускается сканирование файлов через метод объекта, не знающего об этой, вызывающей форме. И как из главного окна теперь скомандовать прекратить работу - вопрос :)
А почему ФОРМА должна командовать?
D
Вот пример за минуту как избавиться от визуала но при этом сохранить обратную свзяь
D
В методах
procedure MyNotifyOnStart; virtual; abstract;уже описываются разнообразные реакции на события. Сами события вызываются в
procedure MyNotifyOnFinish; virtual; abstract;
procedure MyNotifyOnProcessFile(const AFileName: string; var AContinue: Boolean); virtual; abstract;
StartScannAK
А почему ФОРМА должна командовать?
потому что мне надо послать сигнал, что надо прервать процесс обработки. Но на самом деле, может, получится аккуратно сделать это через вкладку (хоть там по уму надо переписать всё это взаимодействие)
AK
Да я придумаю что-нибудь, как всегда
D
Да я придумаю что-нибудь, как всегда
А вот это зря. Много умных людей придумывают паттерны разработки специально что бы другие программисты ничего не придумывали, а быстро выполняли задачи и закрывали таски :)
AK
в моих задачах не всегда применимы или просто удобны чужие решения. Тем более, я слишком консервативен.
AS
А вот это зря. Много умных людей придумывают паттерны разработки специально что бы другие программисты ничего не придумывали, а быстро выполняли задачи и закрывали таски :)
+++
Только не придумываЮТ, а "придумали", а точнее - обобщили, назвали и собрали вместе
Только не придумываЮТ, а "придумали", а точнее - обобщили, назвали и собрали вместе
AK
мне б сейчас сделать, не так много осталось, а потом можно будет уже рефакторингом заняться, т.к достаточно изолированные друг от друга классы
AS
в моих задачах не всегда применимы или просто удобны чужие решения. Тем более, я слишком консервативен.
Я тя умоляю! Твои/мои/наши собственные решения изобрели уже много много раз
AK
а я и не говорю, что всё, что я делаю, это чисто мои придумки
AK
но в процессе разработки появляются нюансы, что-то добавляется, что-то убывает, не всегда получается придерживаться одной модели
D
но в процессе разработки появляются нюансы, что-то добавляется, что-то убывает, не всегда получается придерживаться одной модели
Странно... У джавы целый фреймворк построенный на MVC и он постоянно меняется но они умудряются придерживаться одной модели, а тут полтора класса с формой не могут? :) Это всё отмазки. Чем раньше получится перестроить мозг на модульную работу и развязкой всего то тем проще будет дальше
AS
но в процессе разработки появляются нюансы, что-то добавляется, что-то убывает, не всегда получается придерживаться одной модели
Ну, когда меняются условия/требования, меняются реализации. Это нормально :)